[03:16] <humphreybc> godbyk: I see that German is almost ready to be released :D
[03:18] <godbyk> humphreybc: yep
[03:18] <humphreybc> what other languages are close?
[03:18] <godbyk> no clue.
[03:18] <godbyk> haven't heard from any other editors yet.
[03:19] <humphreybc> https://translations.launchpad.net/ubuntu-manual/lucid-e1/+translations
[03:19] <humphreybc> german is way down the page
[03:19] <humphreybc> same with greek
[03:20] <godbyk> yeah, I don't know what's up with the translation stuff these days.
[03:20] <humphreybc> lol
[03:20] <godbyk> launchpad's translation stuff frightens and confuses me.
[03:20] <godbyk> I've given up trying to figure it out.
[03:21] <humphreybc> lol
[03:33] <godbyk> humphreybc: so.. still up for a 29 July release of the second edition?
[03:33] <godbyk> I haven't been paying any attention to what's been happening with it.
[03:33] <godbyk> I know some bugs have been fixed.
[03:34] <godbyk> but beyond that, I don't know how many bugs remain or anything.
[03:38] <humphreybc> definitely
[03:38] <humphreybc> we should be okay
[03:39] <humphreybc> wait
[03:39] <humphreybc> that's 2 days away
[03:39] <godbyk> yep
[03:39] <humphreybc> when's the next point release for lucid?
[03:39] <godbyk> I don't know.
[03:40] <humphreybc> https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/031016.html
[03:40] <humphreybc> "Due to not having a full-time release manager" << They should have hired me.
[03:40] <humphreybc> so we can release on the 29th or on the 12th august, whatever suits us
[03:41] <godbyk> heh.. great.
[03:41] <godbyk> lol. have you heard back from them?
[03:41] <humphreybc> no
[03:41] <humphreybc> the position has been taken down, presumed it was filled
[03:41] <godbyk> interesting.
[03:41] <humphreybc> i guess I suck at managing :P
[03:42] <godbyk> well, then.. do we want to release on the 29th or the 12th?
[03:42] <nisshh> humphreybc: they probably got your application and went "oh, no! not humphreybc!"
[03:42] <humphreybc> honestly, you know more about the project at the moment than me
[03:42] <humphreybc> i've been rather absent as of late
[03:42] <godbyk> What kind of changes go into the point release of ubuntu?
[03:42] <humphreybc> just bug fixes
[03:42] <godbyk> anything we should wait on to ensure our edition matches their point release?
[03:42] <humphreybc> nah
[03:42] <humphreybc> it's behind the scenes stuff
[03:42] <nisshh> godbyk: all the UI tweaks?
[03:43] <humphreybc> did you look at that list?
[03:43] <humphreybc> nisshh: no UI tweaks
[03:43] <humphreybc> https://launchpad.net/ubuntu/+milestone/ubuntu-10.04.1
[03:43] <nisshh> humphreybc: what about all the sound menu stuff?
[03:43] <humphreybc> nisshh: no that's for maverick
[03:43] <nisshh> oh THAT ubuntu release :)
[03:43] <humphreybc> a point release is just a bug fix
[03:43] <nisshh> thought you meant maverick
[03:43] <nisshh> hehe
[03:43] <humphreybc> nope
[03:45] <humphreybc> I put android 2.2 on my magic yesterday
[03:45] <nisshh> nice?
[03:45] <humphreybc> it's great
[03:45] <nisshh> stable?
[03:45] <humphreybc> my phone is actually now a joy to use
[03:45] <humphreybc> yeah it's stable, cyanogen mod 6 rc2
[03:45] <godbyk> They fixed most the bugs/complaints I had.
[03:45] <nisshh> cool
[03:45] <humphreybc> you know, it's FAST and you don't get frustrated when things don't appear for 20 seconds
[03:46] <godbyk> I'm just using the stock froyo.
[03:46] <humphreybc> and the keyboard is responsive now
[03:46]  * nisshh cant even afford a new comp, so no new android for him...
[03:46] <humphreybc> you've got a nexus one right kevin?
[03:46] <godbyk> yeah
[03:46] <humphreybc> yeah
[03:46] <humphreybc> i bet yours is really fast
[03:46] <humphreybc> the magic is underpowered
[03:46] <nisshh> did you see the guys who put ubuntu on the N1?
[03:46] <godbyk> it seems pretty fast.
[03:46] <humphreybc> have you got the fancy new gallery?
[03:46] <godbyk> it could always be faster, though. :)
[03:46]  * godbyk is impatient.
[03:46] <nisshh> heh
[03:47] <humphreybc> I still don't think android is as fast as iphones
[03:47] <humphreybc> but i've never dried any of the new uber fast phones like the Droid X
[03:47] <humphreybc> tried*
[03:47] <humphreybc> the best feature for me when going from 1.6 - 2.1 was the addition of the new "universal contact" thing
[03:47] <nisshh> humphreybc: i think we should be grateful that there IS an alternative to the iphone :)
[03:48] <humphreybc> and the fact that facebook and twitter syncs with your contacts and downloads profile pictures from facebook, so when you scroll through contacts they all have pictures. It's so good.
[03:48] <humphreybc> the market still needs a lot of work though, too many shithouse apps
[03:48] <nisshh> yea
[03:48] <godbyk> yeah, I wish I could sort the apps by rating or something.
[03:48] <humphreybc> godbyk: do you know if Google has any kind of control / screening for apps so people don't create malicious ones?
[03:49] <humphreybc> I can't imagine it's totally free for all
[03:49] <godbyk> they did add an 'update all' button, though.  that killed one of my peeves.
[03:49] <humphreybc> update all is good
[03:49] <humphreybc> godbyk: do you SMS?
[03:49] <godbyk> humphreybc: they pulled one app from the store and uninstalled it from people's phones because of that.
[03:49] <humphreybc> so they don't have any prevention
[03:49] <godbyk> someone created a pseudo-malicious app as a test of security.
[03:49] <godbyk> it didn't do any damage or anything, but google pulled it.
[03:50] <godbyk> humphreybc: I didn't used to, but I do occasionally now.
[03:50] <humphreybc> http://www.downloadsquad.com/2010/06/28/understanding-the-android-market-security-system/
[03:50] <humphreybc> godbyk: when you send and SMS to someone, in the thread, it shows their picture, and it's meant to show your picture beside "Me"
[03:50] <humphreybc> but all I get is a gray box - do you get one as well?
[03:50] <humphreybc> I can't change it or anything, and it's bugging me to no end
[03:50] <godbyk> humphreybc: http://android-developers.blogspot.com/2010/06/exercising-our-remote-application.html
[03:51] <godbyk> I get a grey android icon if there's no profile pic for them.
[03:51] <humphreybc> lame
[03:51] <humphreybc> i just get a gray box
[03:51] <godbyk> but the contacts I talk to regularly have profile pics (either from facebook, google accounts, or one that I've set manually)
[03:51] <humphreybc> no i mean for ME
[03:51] <humphreybc> not for them
[03:51] <humphreybc> for the text messages I send
[03:52] <humphreybc> there is no picture for me
[03:52] <humphreybc> I thought it would have pulled it from my google profile or my facebook profile
[03:52] <godbyk> oh!
[03:52] <godbyk> I dunno.. lemme look.
[03:54] <godbyk> in the Messaging app, there's a pic by my name.
[03:55] <humphreybc> lame
[03:55] <humphreybc> maybe it'll update eventually
[03:55] <nisshh> godbyk: ah, that reminds me
[03:55] <godbyk> in the Talk app, it's just a grey icon for me, though.
[03:55] <godbyk> nisshh: what's that?
[03:56] <nisshh> godbyk: iv taken over the Ubuntu Developers Manual from Rick, but i dont really know enough tex/latex stuff
[03:56] <nisshh> godbyk: you know, all that formatting stuff
[03:56] <nisshh> all iv figured out so far is how to include chapters
[03:57] <nisshh> godbyk: could you point me at some good docs or something?
[03:59] <godbyk> nisshh: sure. there was just a link I saw about that earlier. let me find it.
[03:59] <humphreybc> Y'know what's annoying?
[03:59] <nisshh> godbyk: cool, thanks
[03:59] <nisshh> humphreybc: no, whats annoying?
[03:59] <humphreybc> This down time we have in between releases where it's too early to write new stuff
[04:00] <nisshh> yea
[04:00] <humphreybc> I'm running maverick at the moment and there isn't much we can write about, and we certainly can't take screenshots yet
[04:00] <godbyk> nisshh: here it is: http://tex.stackexchange.com/questions/11/what-is-the-best-book-to-start-learning-latex
[04:00] <nisshh> iv been out of sync with whats happening though, so i havent noticed
[04:00] <nisshh> godbyk: awesome, thanks
[04:01] <godbyk> I've been busy with other work, so I haven't been spending too much time with the manual project lately.
[04:01] <godbyk> Seems like everyone else has been busy elsewhere, too.
[04:01] <godbyk> I'm glad we're getting these translations out, though.
[04:01] <godbyk> It'll definitely get easier (and more streamlined) as we go on.
[04:01] <nisshh> godbyk: what the hell? im getting some kind of error
[04:02] <godbyk> nisshh: ah, crap. that site's still in private beta.
[04:02] <nisshh> yea
[04:02] <godbyk> one of the links they provide is this: http://www.ctan.org/tex-archive/info/beginlatex/beginlatex-3.6.pdf which appears to be pretty decent.
[04:02] <godbyk> let me paste some other links, too.
[04:02] <nisshh> ok
[04:02] <godbyk> http://en.wikibooks.org/wiki/LaTeX
[04:02] <humphreybc> godbyk: I know, the translations are great. I'm looking forward to announcing the german one on planet ubuntu
[04:03] <godbyk> http://www.artofproblemsolving.com/Wiki/index.php/LaTeX:About
[04:03] <godbyk> http://math.bard.edu/bloch/basicLaTeX.pdf
[04:03] <nisshh> godbyk: and these wikibooks and pdfs teach you all the formatting and everything?
[04:04] <godbyk> nisshh: well, they'll teach you the formatting commands for latex, and tell you about some of the packages that are available.
[04:04] <nisshh> godbyk: right, cool
[04:04] <godbyk> if you want a book that covers everything, I'd recommend The LaTeX Companion by Mittelbach and Goossens.
[04:04] <nisshh> ok
[04:04] <godbyk> It's a huge tome that covers a ton of packages and everything.
[04:04] <nisshh> yea
[04:04] <nisshh> i probably dont need to know everything]\
[04:04] <godbyk> nisshh: Are you wanting to have your own book design?
[04:05] <nisshh> just more than i currently do
[04:05] <godbyk> in that case, the earlier links will probably suffice.
[04:05] <nisshh> well, currently the dev manual looks almost exactly like our manual
[04:05] <nisshh> because Rick took the initial code from e1
[04:05] <godbyk> ok
[04:06] <nisshh> so i thought we dont really want them to look the same
[04:06] <nisshh> plus i need to learn how to do all the title page stuff
[04:07] <godbyk> right.
[04:07] <nisshh> and learn all the commands
[04:07] <godbyk> What I usually recommend with regard to book design is to write the content first.  And then we'll design the book around that content.
[04:07] <nisshh> geez, thats alot of stuff
[04:07] <nisshh> yea, thats the plan
[04:07] <godbyk> The content will tell us what kind of formatting and styles we'll need.
[04:07] <godbyk> I'm happy to help out with the book design side of things, too.
[04:08] <nisshh> i am already seeing trends with the content
[04:08] <nisshh> and we only have 3 or 4 chapters drafted in there
[04:08] <nisshh> that would be great if you could help out
[04:08] <nisshh> but probably not necessary until later
[04:09] <nisshh> godbyk: was it vish who did the title page for the manual?
[04:10] <godbyk> I think vish made the icons, but I think the final design was thorwil's.
[04:10] <nisshh> right
[04:10] <godbyk> I could be wrong, though, it was a while back. :)
[04:10] <nisshh> yea, hehe
[04:13] <godbyk> Do you have a repository for the content so far?
[04:14] <humphreybc> be back in a sec, rebooting into windowz
[04:14] <nisshh> godbyk: yep, just let me grab you a link
[04:14] <godbyk> 'kay
[04:15] <nisshh> godbyk: https://code.edge.launchpad.net/~ubuntu-developer-manual/ubuntu-developer-manual/trunk
[04:18] <godbyk> got it.
[04:19] <nisshh> godbyk: im not sure when Rick grabbed the stuff from e1 or if he grabbed it from e2
[04:19] <nisshh> but i suspect its from at least 4-6 weeks ago
[04:19] <godbyk> yeah, I helped him find all the files he needed.
[04:19] <godbyk> I don't recall which branch I had him snag.
[04:19] <nisshh> yea
[04:20] <godbyk> I need to merge some stuff from e1 to e2 anyway.
[04:20] <godbyk> (mostly translation-related tweaks)
[04:20] <nisshh> yep
[04:20] <nisshh> is it worth getting stuff from e2 and putting it with what i already have?
[04:20] <godbyk> probably not yet.
[04:21] <nisshh> fair enough
[04:21] <godbyk> there are also likely a few ubuntu-manual-specific things in the document class that should be moved elsewhere, too.
[04:21] <godbyk> but we can deal with all that when we do the book design.
[04:21] <nisshh> godbyk: what i have so far has pretty much everything i need i think
[04:21] <godbyk> okay
[04:21] <nisshh> yea
[04:22] <godbyk> anything that's notably different from the ubuntu manual?
[04:22] <nisshh> i dont think so
[04:22] <nisshh> apart from the content
[04:22] <godbyk> anything in particular you want to do differently design-wise?
[04:22] <godbyk> (if not then our work's mostly done. ;-))
[04:23] <nisshh> well, i just thought it would be shitty to have both manuals look almost identical
[04:23] <godbyk> It depends on a few factors, I guess:
[04:24] <godbyk> 1. If you want the book to appear like part of a series/collection of related books (of which the Ubuntu Manual is a part), then you'll want the designs to be shared.
[04:24] <godbyk> 2. If the design meets the needs of the content, then why fret about whether it's similar to another book's design?
[04:25] <godbyk> 3. If you want to make a point that this book isn't associated with / related to the Ubuntu manual, then you may want a different design.
[04:25] <godbyk> 4. If your book's content doesn't require the same design elements, then you'll want a diff. design.
[04:25] <godbyk> 5.  I read a lot. :)
[04:27] <godbyk> at some point, we (being the Ubuntu Manual Project) will need to talk about the book design for the Maverick edition.  Do we want to keep the same design?  Just make a few tweaks?  Overhaul the design?
[04:27] <nisshh> yea
[04:28] <nisshh> now that you have mentioned it i suppose both manuals are sort of under the same banner arent they?
[04:28] <nisshh> so the designed should be similar, if not the same
[04:29] <nisshh> with maybe the exception of the title page
[04:29] <godbyk> The current design is, of course, not perfect, either.  There are definitely some things I want to tweak. :)
[04:29] <nisshh> such as?
[04:29] <godbyk> Is there a deadline for the release of your manual?
[04:30] <nisshh> we were hoping for a maverick final release, but i dont think we will get there
[04:30] <nisshh> so id say, no, there is no deadline
[04:31] <godbyk> I need to tweak the typeface size and line spacing a bit.  I want to find a better way to code the underlying margin note stuff (but that may be outside the scope of a simple design tweak).
[04:31] <nisshh> yep
[04:31] <godbyk> It'd be nice if the new Ubuntu font could be incorporated -- we'll see how that goes.
[04:31] <nisshh> yea, that would be nice actually
[04:32] <godbyk> And then there's the brand new Ubuntu/Canonical branding stuff. We may want to incorporate some elements from that.
[04:32] <nisshh> yea
[04:32] <nisshh> are all the screenshots the same size in the manual?
[04:33] <godbyk> they're the same resolution and scale.
[04:33] <nisshh> ah
[04:33] <godbyk> but from one language to the next, the scale may differ.
[04:34] <nisshh> i was just going to say, you could save file size of the pdf if each screenshot was relative to whats in it
[04:34] <nisshh> for example:
[04:35] <nisshh> a sound menu screenshot does not need to be 800px wide in the pdf
[04:35] <godbyk> oh, right.  yeah, the screenshots are cropped to show only what's relevant.  there are very few full-screen images.
[04:35] <nisshh> if that was cropped right down, a decent chunk of bytes could be chopped out of the pdf
[04:36] <nisshh> ah ok
[04:37] <nisshh> godbyk: as it stands, the dev manual will be much smaller than the other manual, due to less screenshots and shorter and fewer chapters
[04:37] <nisshh> there will probably be less than 25 screenshots in it
[04:38] <godbyk> Gotcha.
[04:38] <godbyk> What's being covered in the dev manual?
[04:38] <nisshh> the manual is about creating your own small app while working through each chapter
[04:39] <nisshh> so you end up with a nice little identica reader app at the end
[04:39] <godbyk> A tutorial for writing a new app with Ubuntu? Neat!
[04:39] <nisshh> yea
[04:39] <godbyk> If I may make a suggestion: any code examples you provide in the manual should be the best practice or best way of accomplishing that.
[04:40] <nisshh> some of the stuff covered is: quickly, quickly-widgets, glade, desktopcouch, U1, etc
[04:40] <godbyk> Because that code will be copied and pasted from that point forward.
[04:40] <nisshh> your exactly right
[04:40] <godbyk> So if your code is the 'easy but insecure' way of doing something, that'll be the code that finds its way into applications.  And then the applications will be insecure.
[04:40] <nisshh> but you also have to remember that we are trying to keep it as simple as possible
[04:40] <godbyk> Yeah, that's always the problem.
[04:41] <nisshh> i guess we will have to find a balance in between simple and good code
[04:41] <godbyk> But far too often, I see programming manuals/tutorials that give a couple lines of code and then make an off-hand remark about 'this is really a bad way to do this, but we don't want to confuse you with scary details on how to do it the proper way'.
[04:41] <godbyk> and that code ends up getting copied verbatim.
[04:41] <nisshh> yea
[04:42] <nisshh> but we have already solved part of that problem: quickly
[04:42] <nisshh> generates known good code by default
[04:42] <godbyk> quickly sounds intriguing.  I haven't had time to look at it yet, though.
[04:42] <nisshh> its pretty cool
[04:42] <nisshh> but not for people who can code like mad :)
[04:43] <nisshh> if you know your stuff, your better off not using it
[04:43] <godbyk> is it fairly limiting?
[04:43] <godbyk> what's the downside?
[04:43] <nisshh> well, yes and no
[04:44] <nisshh> one sec
[04:44] <nisshh> right
[04:44] <nisshh> quickly generates templates
[04:44] <nisshh> which you dont HAVE to use
[04:44] <humphreybc> godbyk: http://www.google.com/support/forum/p/android/thread?tid=3a41f790937732e1&hl=en
[04:45] <nisshh> humphreybc: that was one LONG reboot
[04:45] <nisshh> :)
[04:45] <humphreybc> oh no i just didn't open pidgin for a while
[04:45] <nisshh> right.....
[04:46] <godbyk> humphreybc: aha.  my number is Unknown.
[04:46] <godbyk> so I have to find a way to edit the number on the sim card?
[04:48] <humphreybc> apparently
[04:49] <humphreybc> i've read through all the replies, none seem to work
[04:49] <godbyk> I don't have another phone handy that can read sim cards.
[04:49] <godbyk> well, my old german handy might.. but I doubt it has a charge anymore.
[04:49] <humphreybc> me neither
[04:50] <vish> nisshh: yup , what godbyk said , i did the alpha one with wolter's lynx
[04:50] <godbyk> If the iPhone can edit the SIM card, why can't my N1?
[04:50] <godbyk> hey, vish!
[04:50] <humphreybc> it's stupid isn't it
[04:50] <vish> godbyk: heya :)
[04:50] <humphreybc> you'd think the android could
[04:50] <humphreybc> sup vish
[04:50] <nisshh> vish: right, but did you do the final e1 version?
[04:50] <nisshh> or was that thorwil?
[04:50] <godbyk> humphreybc: yeah, you would.
[04:51] <godbyk> vish: how's it going? haven't chatted with you in forever, it seems.
[04:51] <vish> nisshh: final was thorwil with me doing a few icons
[04:51] <nisshh> vish: right
[04:51] <vish> godbyk: gah , busy .. :(
[04:52] <humphreybc> has to continue designing a t shirt
[04:52] <humphreybc> oops, forgot the me thing
[04:52] <godbyk> vish: I hear ya. Same here.  I think everyone's been busy the past few months.
[04:54] <vish> humphreybc: t shirt?  for OMG?
[04:54] <humphreybc> vish: nope, for uni :P
[04:54] <humphreybc> but i have a truckload of OMG! work to do
[04:54] <vish> humphreybc: hehe that site is gaining a life of its own!
[04:55] <humphreybc> not just omg ubuntu
[04:55] <vish> humphreybc: omg suse is also by do0d ? wow! i just thought it was someone else doing the same stuff... I guess he ran out of OMG news in Ubuntu ;p
[04:55] <humphreybc> i'm working on a new site
[04:55] <humphreybc> we own a number of sites :)
[04:55] <humphreybc> omg suse is written by someone else though
[04:56] <nisshh> what site are you working on humphreybc?
[04:56] <humphreybc> nisshh: ubuntu gamer
[04:56] <humphreybc> and a new site that we're launching later in the year that I can't tell you about :)
[04:57]  * nisshh lets out an excited squeak!
[04:58] <nisshh> humphreybc: im a member of the au loco and we just recently started our own gaming clan :)
[04:58] <humphreybc> groovy
[04:58] <nisshh> :)
[05:38] <nisshh> wow
[05:38] <nisshh> i just saw a giant netsplit happen in 6 channels at once
[05:39] <godbyk> Yeah, I was feeling pretty lonely here.
[05:40] <nisshh> meh
[05:43] <humphreybc> heh
[05:44] <humphreybc> I was here godbyk
[05:44] <godbyk> It said you had abandoned me, too, humphreybc.
[05:44] <humphreybc> aw
[05:46] <nisshh> lol
[05:46] <nisshh> group hug?
[05:48]  * godbyk opens his arms
[05:48] <godbyk> what, nobody?
[05:49]  * humphreybc hugs back
[05:49] <godbyk> yay!
[05:50] <nisshh> wait for me!
[05:50] <nisshh> not my fault im lagging!
[05:52] <godbyk> aw, and here I thought you'd shunned me, nisshh! :)
[05:53] <nisshh> never!
[06:06] <godbyk> hey, nisshh: is there a nice wiki page for a C programmer who wants to get started with helping Ubuntu (as a C developer)?
[06:06] <godbyk> something that lists ways they can help.  (write patches for bugs, join an existing project team, start a new project, etc.)
[06:07] <godbyk> I guess this might work: https://wiki.ubuntu.com/UbuntuDevelopment
[06:10] <nisshh> godbyk: dude, you do know im a python programmer, not a C programmer right?
[06:10] <godbyk> yeah.
[06:10] <godbyk> I just figured you might know what getting-started-as-a-developer guides were out there.
[06:10] <nisshh> but i am learning C
[06:10] <nisshh> ah, right
[06:11] <godbyk> I just got an email from someone who's a C programmer (embedded systems, mostly) who wanted to get started helping out Ubuntu. (He's been using it for 2-3 years.)
[06:11] <nisshh> godbyk: well, there arent really ubuntu-dev guides out there
[06:11] <nisshh> right
[06:11] <godbyk> I know.  Get busy! :)
[06:11] <nisshh> hehe
[06:11] <nisshh> just tell him to find an app written in C or something
[06:12] <nisshh> or a part of ubuntu written in C
[06:12] <nisshh> and tell him to hack on it or fix bugs
[06:12] <godbyk> I pointed him to that link and suggested he could start by submitting patches to bugs or find a project he's interested in and contact the dev team and offer to help.
[06:12] <nisshh> yea
[06:13] <nisshh> compiz 0.9 is written in C
[06:13] <godbyk> I thought they were rewriting it in C++.
[06:13] <nisshh> but alot of projects use python now
[06:13] <nisshh> it was C i thought
[06:14] <godbyk> I think it was originally C and is/was being rewritten in C++.
[06:14] <godbyk> From compiz.org: "The latest release of Compiz is 0.8.6. A C++ rewrite has been announced on 24th December 2009 and is about (June 2010) to be released as a beta version. This is a major rework of the whole project, aimed at easing future development."
[06:15] <nisshh> ah right
[06:15] <nisshh> always get mized up with C and C++
[06:15] <godbyk> Apparently C programmers do, too.  :-P
[06:15] <nisshh> lol
[06:16] <godbyk> (I have to refactor so much C++ code written by C programmers.  "C++ is just C with classes, right?"  Gah!)
[06:16] <nisshh> hehe
[06:16]  * nisshh uses python for exacly that reason
[06:16] <nisshh> exactly*
[06:17] <godbyk> I'm writing a little python script right now to parse some CSV files, mash the data together, and spit out some line graphs and some stats.
[06:18] <godbyk> But I rarely write python code, so it's quite messy at the moment and needs to be rewritten from scratch.
[06:18] <godbyk> (also, since I don't get to use python much, I don't know most of the pythonic ways of doing things, so it's probably grossly inefficient)
[06:21] <nisshh> yea
[09:05] <godbyk> Hey, thorwil. If you get some time today, could you whip up one of your famous wraparound covers? :)
[09:06] <thorwil> godbyk: i'm about to get to it
[09:06] <godbyk> It's past my bedtime.  G'night!
[09:06] <godbyk> thorwil: Awesome. Thanks!
[09:06] <thorwil> nite!
[09:06] <godbyk> After that, I think we'll be ready for the release of the German translation -- unless you're aware of any last minute bugs we need to fix.
[09:07] <godbyk> Gute Nacht!
[13:18] <pkramerruiz> Hi everyone!
[13:18] <pkramerruiz> Can anyone tell me if the developers of "software-sources" have an channel-sources?
[13:18] <pkramerruiz> Cause I want to run the process for selecting the best Mirror server, every time before making an update to some program, for obtain more speed downloading
[13:19] <dutchie> pkramerruiz: i don't think there is a channel just for the software sources app
[13:19] <dutchie> pkramerruiz: to be honest, once you've picked a mirror, it's not really worth checking all of the speeds every time
[17:57] <godbyk> Hey, thorwil. Thanks for the cover!
[17:58] <thorwil> hi godbyk. np
[17:58] <godbyk> thorwil: did you notice anything else that we need to do before releasing the german edition?  or shall I assume all is well and that I can proceed?
[18:02] <thorwil> godbyk: didn't look beyond the cover, don't intend to change that now ;)
[18:17] <godbyk> thorwil: fair enough. :)


[00:29] <mup> PR snapd#2054 closed: client,daemon,cmd/snap: improve create-user APIs <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2054>
[03:42] <mwhudson> is it possible to get snapd to forget about an assertion?
[06:54] <zyga> hey
[06:54] <zyga> mwhudson: I think only with a new assertion
[06:54] <zyga> mwhudson: (or with rm -f)
[07:25] <mup> PR snapd#2056 opened: interfaces: add Plug/Slot/Connection reference helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2056>
[07:40] <mwhudson> morning
[08:03] <mup> PR snapd#2056 closed: interfaces: add Plug/Slot/Connection reference helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2056>
[08:16] <mup> PR snapd#2057 opened: docs: remove references to removed buying features <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2057>
[08:17] <mup> PR snapd#2058 opened: interfaces: add ofono interface <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2058>
[08:21] <hikiko> hello :)
[08:21] <hikiko> I need some help with an error message during dist-upgrade on X
[08:21] <hikiko> http://pastebin.com/HUcC3wWg
[08:22] <hikiko> the initial problem I was trying to solve was this:
[08:25] <hikiko> I have 2 graphics cards intel and nvidia, but I work on the intel, the nvidia is there for testing features and during the last dist-upgrades the nvidia drivers and several other packages were automatically installed and messed up my xorg configuration so I couldn't use any of the cards. everytime I remove the nvidia drivers and the other packages they are reinstalled as a dependency of libcuda1-361 and every time I try to remove
[08:25] <hikiko> it I receive that error message...
[08:25] <hikiko> any ideas? :)
[08:32] <mup> PR snapd#2059 opened: interfaces: add repo.ResolveConnect that handles name resolution <Created by zyga> <https://github.com/snapcore/snapd/pull/2059>
[08:34] <didrocks> hikiko: no package I can see contain this file, I guess it's snapd creating it dynamically for system mount point. It's a question for mvo or zyga ^
[08:39] <hikiko> thanks didrocks :)
[09:28] <mup> PR snapd#2060 opened: many: change Connect to take ConnRef instead of strings <Created by zyga> <https://github.com/snapcore/snapd/pull/2060>
[09:52] <mup> PR snapd#2061 opened: interfaces: add dummy implementation of ResolveConnect <Created by zyga> <https://github.com/snapcore/snapd/pull/2061>
[09:55] <didrocks> zyga: hey! It seems that if a service fails to start at installation time, the snap is removed
[09:55] <didrocks> zyga: that makes it hard for debugging, any tip about it?
[09:55] <didrocks> davidcalle: FYI (on the doc)
[10:30] <zyga> didrocks: hey
[10:30] <zyga> hikiko: looking
[10:31] <zyga> hikiko: that's something that was only available in -proposed
[10:32] <zyga> hikiko: this is something that has to be fixed in the nvidia packaging but I believe it was removed already
[10:32] <zyga> hikiko: can you check if you can downgrade to the non-proposed package and see if the problem goes away
[10:32] <zyga> didrocks: I wasn't aware of it
[10:32] <zyga> didrocks: I don't know what is the plan about this, sorry
[10:33] <hikiko> zyga, how can I downgrade it?
[10:39] <zyga> hikiko: I think you can try to install it with "apt install package=version"
[10:40] <zyga> hikiko: alternatively edit the dpkg maintainer script on your disk not to touch that mount unit
[10:40] <zyga> hikiko: but really, I don't fully know what is required; you probably want to ask alberto milone or mvo (try alberto first please)
[10:40] <hikiko> zyga, and where can I find the version to which I have to downgrade?
[10:40] <zyga> hikiko: try apt-cache policy package
[10:41] <zyga> this will show you available versions
[10:41] <hikiko> thanks zyga :) I'll try
[10:41] <zyga> (the package in question is the one that fails because of the maintianer script)
[10:41] <zyga> *maintainer
[10:51] <mup> PR snapd#2062 opened: interfaces/policy: introduce InstallCandidate and its checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/2062>
[11:46] <mup> PR snapd#2063 opened: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <https://github.com/snapcore/snapd/pull/2063>
[11:47] <zyga> jdstrand: hey, you may want to review this one ^6
[12:04] <didrocks> zyga: hikiko|ln: btw, easier for downgrading, you can do apt install package/<distropocket> (like package/yakkety for instance)
[12:05] <hikiko|ln> didrocks, if I try to do that the proposed are selected
[12:06] <didrocks> no
[12:06] <didrocks> if you don't set yakkety-proposed, and only yakkety, it will select yakkety
[12:06] <didrocks> (with -f to force a downgrade ofc)
[12:07] <hikiko|ln> # apt install libcuda1-361/xenial -f
[12:07] <hikiko|ln> Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu<IP_ADDRESS> [69,6 MB]
[12:08] <didrocks> this is the nvidia package
[12:08] <didrocks> not libcuda1-361
[12:08] <hikiko|ln> yup it's a dependency
[12:08] <didrocks> so ofc, the other packages follow the general scheme
[12:08] <hikiko|ln> oh ok :)
[12:08] <didrocks> so, you need to list it
[12:08] <didrocks> # apt install libcuda1-361/xenial nvidia-367/xenial -f
[12:08] <didrocks> and so on… :)
[12:09] <hikiko|ln> I need to remove the dependencies and libcuda didrocks
[12:09] <hikiko|ln> should I first downgrade then remove?
[12:09] <didrocks> I would say yeah, first downgrade everything to remove -proposed components
[12:09] <didrocks> and then remove
[12:09] <didrocks> (get in a consistent state first)
[12:10] <hikiko|ln> ~# apt install libcuda1-361/xenial  nvidia-367/xenial nvidia-opencl-icd-367/xenial nvidia-prime/xenial nvidia-settings/xenial -f
[12:10] <hikiko|ln> Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu<IP_ADDRESS> [69,6 MB]
[12:11] <hikiko|ln> it seems to ignore my setting
[12:11] <didrocks> hum… that's weird
[12:11] <didrocks> what if you only do apt install nvidia-367/xenial -f only?
[12:12] <hikiko|ln> https://paste.ubuntu.com/23269943/ didrocks
[12:16] <didrocks> hikiko|ln: I think you have another package that forces you to get that version
[12:17] <hikiko|ln> I've purged nvidia* didrocks
[12:17] <hikiko|ln> can I see which package it is somehow?
[12:17] <didrocks> and here we go
[12:17] <didrocks> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-367
[12:17] <didrocks> -367 is only available in -proposed
[12:17] <didrocks> that's why he didn't follow your guidance to prefer the /xenial one :p
[12:17] <hikiko|ln> and I didn't have it installed
[12:18] <hikiko|ln> so what should I do?
[12:18] <didrocks> I'm pretty sur eyou have something like libcuda1-367 or anything depending on it
[12:18] <didrocks> well, you did purge it, right?
[12:18] <hikiko|ln> the initial problem is to remove libcuda1-361
[12:18] <hikiko|ln> yup
[12:18] <didrocks> apt-cache rdepends nvidia-367
[12:18] <didrocks> anything there? ^
[12:18] <hikiko|ln> Reverse Depends:
[12:18] <hikiko|ln>   libcuda1-367
[12:18] <hikiko|ln>   nvidia-opencl-icd-367
[12:18] <hikiko|ln>   nvidia-367-dev
[12:18] <hikiko|ln>   nvidia-361
[12:18] <didrocks> yeah, so you need to remove any of those installed
[12:19] <didrocks> just purge them
[12:21] <hikiko|ln> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
[12:21] <hikiko|ln> they seem purged
[12:21] <didrocks> good :)
[12:21] <hikiko|ln> maybe rdepends libcuda1-361?
[12:21] <didrocks> you was able to delete it as well?
[12:21] <didrocks> now, try to remove it
[12:21] <didrocks> as it's what you wanted IIRC
[12:22] <hikiko|ln> same
[12:22] <hikiko|ln> E: Sub-process /usr/bin/dpkg returned an error code (1)
[12:23] <didrocks> maybe zyga telling to downgrade nvidia on the proposed didn't indicate the right package
[12:23] <didrocks> (I didn't follow closely)
[12:23] <didrocks> ensure you don't have snapd from proposed from what I understand
[12:24] <hikiko|ln> mmm how?
[12:24] <didrocks> apt-cache policy snapd
[12:24] <didrocks> do you have the proposed version installed?
[12:24] <hikiko|ln> yes
[12:24] <didrocks> so, same
[12:24] <didrocks> revert to the one on xenial
[12:25] <hikiko|ln> same :/
[12:25] <hikiko|ln> if I purge snapd
[12:26] <hikiko|ln> remove the package and reinstall it?
[12:27] <hikiko> still :p just tried that
[12:31] <lool> ogra_: Hey, around?
[12:31] <lool> ogra_: were you the one implementing the dragonboard boot support?  :-)
[12:33] <ara> zyga, ping
[12:40] <mup> PR snapd#2064 opened: Adding new AutopilotIntrospectionInterface <Created by heber013> <https://github.com/snapcore/snapd/pull/2064>
[13:02] <zyga> ara: hey
[13:02] <zyga> ara: how can I help you
[13:02] <ara> zyga, hey! I was wondering how the snap-confine SRU to xenial was going
[13:02] <ara> zyga, any news?
[13:03] <ara> zyga, (what's the bug report to track it?)
[13:18] <zyga> ara: the status is that we landed one SRU last week but we need to go through all the bugs and verify those
[13:18] <zyga> ara: I won't have time for this today as we're freezing now and I need to finish features first
[13:19] <ara> zyga, where is the bug that tracks the SRU?
[13:19] <zyga> ara: if you can help by asking anyone to go through all the SRU bugs on launchpad for snap-confine, we can do this faster
[13:19] <zyga> ara: there's no one bug, each bug has SRU data now
[13:19] <ara> zyga, perfect, I will check on the report page
[13:19] <zyga> ara: look at milestones .40, .41 an.42
[13:19] <zyga> ara: .42 has two bugs that don't have SRU data but I can add that quickly; this was a tiny release
[13:20] <zyga> ara: if you can get me someone to work on validation I will save a lot of time
[13:20] <ara> zyga, are you sure that the SRU landed in -proposed? I don't see it in the http://people.canonical.com/~ubuntu-archive/pending-sru.html
[13:20] <zyga> ara: no, ah, sorry, too many facts lately, .41 was in -proposed but we removed it and someone should upload .42 now
[13:21] <zyga> ara: (there's .42.1 but it doens't have to be released now)
[13:21] <ara> zyga, can you organize uploading it, please? I can help verifying it
[13:22] <zyga> ara: yes, I can
[13:22] <zyga> ara: thank you :)
[13:22] <ara> zyga, thanks you!
[13:22] <ara> zyga, *thank
[13:33] <zyga> joc: ok, branch comig up, just a simple unit test to tie it together
[13:33] <zyga> joc: I will need you to add this udev rule manually to your device and see if it does the right thing
[13:34] <zyga> joc: (no need to build/alter snapd)
[13:40] <ogra_> lool, http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files ... there is a README ... gadget code is at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/dragonboard/
[13:41]  * ogra_ goes back to uniting :)
[13:41] <joc> zyga: ack
[13:45] <zyga> joc: ok, pull request is up, mup will share the link in a sec
[13:45] <mup> PR snapd#2065 opened: interfaces/builtin: use udev to export GPIOs to userspace <Created by zyga> <https://github.com/snapcore/snapd/pull/2065>
[13:46] <zyga> joc: look at tests, get the rule there and stick it into /lib/udev/rules.d/foo.rules
[13:47] <zyga> joc: look at journal and run:
[13:47] <zyga> joc: udevadm control --reload-rules
[13:47] <zyga> joc: udevadm trigger
[13:47] <zyga> joc: the first one should not be required but it's safe to run anyway
[13:47] <zyga> joc: if I got this right it will export one GPIO to userspace
[13:47] <zyga> joc: if not, well, iterate :)
[13:48] <joc> zyga: got it, i'll just tidy up some testing i've been doing of netplan then get right on it
[13:50] <oparoz> Hello, is there a solution in the works to upgrade from one Snap to another?
[13:50] <zyga> joc: thanks, ping me when you got something
[13:50] <zyga> oparoz: ?
[13:50] <zyga> oparoz: can you explain what you mean by this
[13:50] <oparoz> zyga myappv1 to myappv2
[13:51] <zyga> oparoz: and what are myappv1 and myappv2?
[13:51] <zyga> oparoz: snap names, snap versions, something else?
[13:51] <oparoz> zyga, we can't force people to upgrade to v2, so we need a new snap, but then how do people migrate for v1 to v2?
[13:51] <zyga> oparoz: why do you need a new snap?
[13:51] <zyga> oparoz: and what do you mean by "we cannot force people to upgrade"
[13:52] <oparoz> zyga, let's say I offer 3 years support for v1 and every time I release a new version
[13:52] <zyga> oparoz: ah I see what you mean now
[13:52] <oparoz> I mean every year, I release a new version
[13:53] <zyga> oparoz: right now you'd have to indeed offer a second snap if you want to have a different snap that can be concurrently updated (or not)
[13:53] <oparoz> zyga, so some users will want to stay on v1 for a long time and we can't just push v2 to the current dsnap
[13:53] <zyga> oparoz: using the content interface you could offer data migration
[13:53] <zyga> oparoz: I actually added support for this just now: https://github.com/snapcore/snapd/pull/2063
[13:53] <mup> PR snapd#2063: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <https://github.com/snapcore/snapd/pull/2063>
[13:53] <oparoz> zyga, ah interesting, I'll look into that
[13:54] <oparoz> Thanks
[13:54] <Mirv> stupid questions again, if I extend make plugin, with eg. command.extend("INCLUDEPATH ..., why do I get "make I N C L U D E P A T H + = " / h " type of output? ...
[13:54] <cjwatson> Because you probably meant command.append
[13:54] <cjwatson> command.extend takes a sequence
[13:55] <zyga> yep
[13:55] <cjwatson> So either command.append("...") or command.extend(["...", "...", ...])
[13:55] <Mirv> ah, thank you, I'm happy someone endures me :)
[14:16] <niemeyer> jdstrand: ping
[14:16] <jdstrand> niemeyer: hey
[14:17] <niemeyer> jdstrand: Heya
[14:17] <niemeyer> jdstrand: Today it's a bit of a critical day for us.. we want to get all the PRs to the freeze in place by the EOD
[14:17] <niemeyer> jdstrand: How're things looking on your end?
[14:18] <niemeyer> jdstrand: Would you be able to prioritize work that is freeze-related today?
[14:18] <jdstrand> niemeyer: those PRs pedronis mentioned already are prioritized. is there anything beyond that?
[14:19] <pedronis> jdstrand: I should get a couple more
[14:19] <pedronis> but nothing atm
[14:19] <niemeyer> jdstrand: These are the top ones
[14:20] <niemeyer> e.g. #2053 might be a good starting point
[14:20] <niemeyer> snapd#2053
[14:20] <mup> PR snapd#2053: interfaces/policy: implement snap-id/publisher-id checks <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2053>
[14:21] <jdstrand> niemeyer: that is next on the list
[14:21] <niemeyer> jdstrand: Thanks!
[14:22] <mup> PR snapd#2061 closed: interfaces: add dummy implementation of ResolveConnect <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2061>
[14:31] <zyga> joc: any updates
[14:35] <joc> zyga: done with netplan switching over now
[14:35] <mup> PR snapcraft#846 closed: Release changelog for 2.19 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/846>
[14:35] <zyga> joc: thanks!
[15:04] <elopio> kyrofa: can you help me understand when to use SNAP_USER_DATA and when to use SNAP_USER_COMMON?
[15:04] <kyrofa> Hey elopio! I'd be happy to
[15:05] <kyrofa> What kind of app are we talking, here?
[15:05] <kyrofa> Or just generic?
[15:06] <elopio> kyrofa: I have two. syncthing, which is peer to peer file synchronization. And the mysql database of nylas sync-engine, which is an imap thing.
[15:08] <kyrofa> elopio, so obviously since snaps are often made up of many components, you often find yourself with a few different datasets that need to be saved
[15:08] <kyrofa> elopio, for each one, think about what should happen to it when an upgrade occurs
[15:08] <kyrofa> You want to make sure the stuff you save won't get in the way of upgrades or rollbacks
[15:09] <kyrofa> For example: does my dataset need to be mutated in some way for a few version?
[15:09] <kyrofa> Or is it just raw data that isn't really modified?
[15:10] <kyrofa> If new versions need to modify it, it's possible that the modifications aren't backward-compatible. Such datasets should probably go into SNAP_USER_DATA instead of COMMON, since each version has its own copy of that data
[15:10] <kyrofa> And rollbacks will work, even if you mutate the data in newer versions
[15:11] <elopio> it's hard, because I think the distinction is not designed in the tools. For example, syncthing has a home folder, where it stores the files to sync, and metadata.
[15:11] <kyrofa> elopio, another aspect to consider is how much space is taken by the dataset. Is it massive? Does it make sense to copy it for every upgrade?
[15:11] <elopio> I think the files to sync should be in common, the metadata in user_data, but I can't split them.
[15:12] <kyrofa> elopio, indeed
[15:12] <kyrofa> elopio, is it like the owncloud client? Where you add directories to a gui client?
[15:13] <elopio> kyrofa: yes.
[15:13] <kyrofa> elopio, or does it have only one directory?
[15:13] <elopio> you have one default directory, which probably should be in SNAP_USER_COMMON/Sync, and then you can add additional
[15:14] <kyrofa> And it saves metadata specific to that folder within each folder being synced?
[15:14] <kyrofa> It doesn't have any sort of central database?
[15:15] <elopio> kyrofa: it has a central config xml, and some certificates.
[15:16] <kyrofa> elopio, where does that central config go?
[15:16] <elopio> kyrofa: you start the server with synchting --home=$DIR.
[15:16] <elopio> the config ends in that dir.
[15:17] <kyrofa> elopio, could that not be SNAP_USER_DATA, then?
[15:19] <elopio> yes, but then the default SYNC dir would also end up in ~/snap/syncthing/rev/.
[15:19] <elopio> kyrofa: maybe you can comment here: https://github.com/syncthing/syncthing/pull/3636#discussion_r81488374
[15:19] <mup> PR syncthing/syncthing#3636: Add the packaging metadata to build the syncthing snap <Created by elopio> <https://github.com/syncthing/syncthing/pull/3636>
[15:19] <elopio> I'm sure you can explain it better than me.
[15:21] <kyrofa> elopio, hmm... yeah, you probably don't want files accumulating there
[15:21] <kyrofa> elopio, it's too bad they're so tightly coupled!
[15:22] <elopio> kyrofa: the guy is really nice, I thing. So if we explain the thing, probably he can add a separate flag for default sync dir.
[15:23] <kyrofa> elopio, this looks like an old diff. What is SNAP_USER_DIR?
[15:23] <elopio> but as I understand, the answer to his question is: the config should be in SNAP_USER_DATA, just like it's currently doing.
[15:23] <elopio> kyrofa: a mistake. I just removed it.
[15:23] <kyrofa> Ah, now there's no flags
[15:23] <elopio> if you don't pass -home, it will use $HOME.
[15:24] <kyrofa> Okay, I'll make a comment here
[15:24] <elopio> thank you.
[15:26] <kyrofa> Argh, firefox! I had a comment all written out...
[15:27] <kyrofa> Oh it saved it. Nice
[15:30] <sergiusens> elopio hint, snapcraft/xenial-proposed ;-)
[15:31] <elopio> sergiusens: \o/
[15:31] <elopio> ah, I don't have the tests prepared this time.
[15:34] <mup> PR snapd#2063 closed: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2063>
[15:47] <Croepha> hi, in core 16, can you disable nplan and use the older /etc/network/interfaces.d/... files?
[15:51] <kyrofa> Croepha, probably a question for ogra_
[15:55] <mup> PR snapd#2057 closed: docs: remove references to removed buying features <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2057>
[15:55] <Croepha> on core is /etc/passwd supposed to be writeable ?
[15:58] <Croepha> kyrofa, thanks, but I think i figured out the nplan thing, it seems that if you just delete the nplan config, it will use the old config
[15:59] <Croepha> now im having a dfferent issue, on reboot, I cant login or change passwd, debug console works though, so I got a root terminal of sorts
[16:06] <mup> PR snapd#2041 closed: daemon: add `snap create-user --force-managed` support <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2041>
[16:18] <joc> zyga: it doesnt look like the command is being run
[16:19] <joc> zyga: it may be because there isnt an "add" event
[16:19] <joc> i don't see one if i use udevadm monitor
[16:25] <mup> PR snapd#2047 closed: snap: auto mount block devices and import assertions <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2047>
[16:25] <Croepha> ok, so after digging, it looks like core now uses pam_extrausers, so setting root passwd isn't going to be possible under this plan, and adding a user is adduser --extrausers ...
[16:34] <mup> PR snapd#2060 closed: many: change Connect to take ConnRef instead of strings <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2060>
[16:51] <modprobe__> What plug should I use to get access to /dev/{,u}random?
[17:08] <mup> PR snapcraft#824 closed: Add `snapcraft create-key` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/824>
[17:18] <elopio> ogra_: are you around? There's a new snapcraft release in proposed.
[17:23] <sergiusens> marcoceppi or here if rocket is not possible :-)
[17:24] <zyga> pitti: hey
[17:25] <zyga> pitti: I'm trying to write an udev rule that will export a gpio by writing to /sys/class/gpio/export
[17:25] <zyga> pitti: the constraint is that after that I call "udevadm trigger"
[17:25] <zyga> pitti: is there anything sensible I can put into my rule to tie it into an event?
[17:26] <zyga> pitti: it should work both immediatly after "udevadm trigger" returns and on boot
[17:26] <zyga> joc: ^^
[17:26] <kyrofa> jdstrand, it doesn't look lik /dev/random (and similar) are contained in the default profiles. Are they not safe for access?
[17:26] <zyga> kyrofa: you can easily consume all entropy
[17:26] <kyrofa> jdstrand, though getrandom is available
[17:26] <zyga> kyrofa: and DOS other programs
[17:27] <kyrofa> zyga, ah, sure. Do we have an interface for such things, then?
[17:27] <jdstrand> kyrofa: they are safe and available in all profiles via the base abstraction
[17:27] <kyrofa> jdstrand, ah ha, okay
[17:27] <zyga> kyrofa: ah, jdstrand knows better :)
[17:27] <jdstrand> kyrofa: you may want to look at 'apparmor_parser -p /path/to/profile' to see all the policy with the abstractions
[17:27]  * kyrofa needs to read the base abstraction
[17:27] <zyga> jdstrand: so I _can_ write a heatdeathoftheuniverse snap?
[17:27] <kyrofa> Or that! Thanks jdstrand :)
[17:33] <mup> PR snapd#2053 closed: interfaces/policy: implement snap-id/publisher-id checks <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2053>
[17:34] <mup> PR snapd#2051 closed: many: setup snapd macaroon for local users <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2051>
[17:39] <joc> zyga: yep that is the question i was trying to ask, bad English on my part!
[17:39] <joc> zyga: i just tried by removeing the ACTION= altogether
[17:40] <joc> (can't spell now either)
[17:40] <joc> zyga: it made sure the gpio was always exported, but you couldnt unexport as the rule was always matched
[17:43] <zyga> jdstrand: hey, can you please upload .42 from yakkety to xenial, ara's team will do the valiation and work on SRU
[17:44] <zyga> jdstrand: the lack of "undo" is fine for now
[17:44] <jdstrand> ok
[17:45] <zyga> jdstrand: thanks
[17:47] <mup> PR snapd#2066 opened: many: abbreviated forms of disconnect <Created by zyga> <Conflict> <https://github.com/snapcore/snapd/pull/2066>
[17:54] <mup> PR snapd#2067 opened: cmd/snap: trivial auto-import and download tweaks <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2067>
[18:07] <elopio> kyrofa: sorry, you told me to test. I have this for you:
[18:07] <elopio> https://bugs.launchpad.net/snapcraft/+bug/1629955
[18:07] <elopio> https://bugs.launchpad.net/snapcraft/+bug/1629957
[18:07] <mup> Bug #1629955: rosdistro is not documented in the catkin plugin help <Snapcraft:Triaged> <https://launchpad.net/bugs/1629955>
[18:07] <mup> Bug #1629957: When I try to build a snap with the wrong catkin rosdistro, there is no good error <Snapcraft:Triaged> <https://launchpad.net/bugs/1629957>
[18:08] <kyrofa> elopio, ah, very good!
[18:08] <kyrofa> elopio, this is why I ask you to test ;)
[18:08] <kyrofa> Man, rosdistro has been around forever, I didn't even check the docs assuming they were good :P
[18:08] <kyrofa> elopio, blocking, you think? Or no?
[18:09] <elopio> sometimes I get depressed. No piece of software ever works for me on the first try. /o\
[18:09] <kyrofa> (I don't think these are new bugs)
[18:09] <elopio> kyrofa: no, medium and low. To fix when you have some time.
[18:09] <kyrofa> elopio, well good find, thank you!
[18:10] <kyrofa> elopio, you're QA. Finding bugs should make your day!
[18:10] <elopio> that's ok when I try to break it on purpose. Not so nice when I'm just trying to use things.
[18:12] <mup> PR snapd#1970 closed: interface/builtin: add ptrace support to system-trace <Created by niedbalski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1970>
[18:14] <mup> PR snapd#1945 closed: debian, tests: add trusty tests <Reviewed> <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1945>
[18:29] <modprobe__> jdstrand, kyrofa: Does that mean /dev/urandom is available by default? It appears not to be working, though I don't know of an easy way to pop a shell in the sandbox to find out for sure.
[18:31] <modprobe__> As to consuming all available entropy, random has that issue, but not urandom, and I understand that urandom is regarded as every bit as good of a CSPRNG as random (better, since it should always work)
[18:35] <mup> PR snapd#2055 closed: interfaces/policy,overlord: check connection requests against the declarations in ifacestate <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2055>
[18:35] <mup> PR snapd#2062 closed: interfaces/policy: introduce InstallCandidate and its checks <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2062>
[18:39] <kyrofa> modprobe__, indeed, it should work
[18:42] <mup> PR snapd#2044 closed: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044>
[18:45] <modprobe__> kyrofa: Hmm... Well my program indicates pretty clearly that it doesn't. Botan throws an exception saying "System_RNG failed to open RNG device" and looking at its source, the only way that exception gets thrown is if opening /dev/urandom fails.
[18:47] <kyrofa> modprobe__, I'm not claiming you aren't running into issues, I'm just saying confinement shouldn't be causing it :) . Do you see apparmor denials in syslog (or from snappy-debug)?
[18:54] <modprobe__> kyrofa: Ahh yes, I see this in dmesg: audit: type=1400 audit(1475513126.687:37): apparmor="DENIED" operation="open" profile="snap.stakeweightedvoting.app" name="/dev/urandom" pid=6341 comm="VotingApp" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0
[18:54] <kyrofa> modprobe__, it's trying to _write_ to it?
[18:54] <kyrofa> Indeed, the profile is only r
[18:55] <modprobe__> https://botan.randombit.net/doxygen/system__rng_8cpp_source.html (line 77) apparently, it is...
[18:55] <kyrofa> modprobe__, I can't imagine why... ?
[18:56] <modprobe__> Looks like a bug in botan.
[18:56] <kyrofa> Agreed
[19:05] <modprobe__> I'm reporting it to them. In the meantime, can you think of any workaround I can use until they release a fix?
[19:06] <kyrofa> modprobe__, would it be an easy patch?
[19:06] <modprobe__> Yeah, I could just use a custom build of botan...
[19:06] <kyrofa> modprobe__, yeah, that's what I'd recommend
[19:06] <modprobe__> Should literally just be changing that one line.
[19:06] <kyrofa> modprobe__, as a plus, you can propose it back upstream ;)
[19:09] <modprobe__> Yeah, I just made an issue on their github repo and I'll follow it up with a pull request soon, assuming it passes the smoke test. :)
[19:12] <elopio> cprov: I don't quite understand the sign-build --local. It always replies that "A signed build assertion for this snap already exists."
[19:14] <elopio> ah, I think that a previous command left the -build file. But it was empty.
[19:14] <elopio> I'll try to reproduce that.
[19:16] <sergiusens> elopio you only sign once per build
[19:19] <elopio> sergiusens: cprov: https://bugs.launchpad.net/snapcraft/+bug/1629984
[19:19] <mup> Bug #1629984: trying to sign-build without keys leaves a -build file, empty <Snapcraft:Triaged> <https://launchpad.net/bugs/1629984>
[19:21] <modprobe__> kyrofa: Apparently writing to random or urandom is a way to add entropy to the kernel pool. Maybe the AppArmor profile should be updated?
[19:21] <kyrofa> modprobe__, hmm interesting, jdstrand is the guy to consider that. Not sure what the ramifications would be
[19:22] <jdstrand> we'd need a new interface for that
[19:23] <jdstrand> I think. please file a bug
[19:24] <kyrofa> modprobe__, regardless, the fact that the thing dies if it can't add entropy still seems like a bug
[19:25] <mup> PR snapd#2059 closed: interfaces: add repo.ResolveConnect that handles name resolution <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2059>
[19:25] <modprobe__> kyrofa: Very true.
[19:25] <elopio> cprov: now without a body, I get: "no assertion found in request body". Tried on staging and production with a test user.
[19:26] <elopio> is that because my user is not allowed, or something?
[19:28] <modprobe__> jdstrand: Is that a bug on snapd?
[19:31] <kyrofa> modprobe__, indeed
[19:33] <modprobe__> Alright, I'll file that soon
[19:48] <cprov> elopio: thanks for filing the bug, the stray/empty -build should not be there.
[19:49] <elopio> np
[19:49] <elopio> ralsina: I'm getting this:
[19:49] <elopio> $ snapcraft validate u1test20161003 ubuntu-core=1
[19:49] <elopio> Getting details for u1test20161003
[19:49] <elopio> Snap 'u1test20161003' was not found in the 'stable' channel.
[19:49] <elopio> But I've just released the snap to stable on staging. Am I doing something wrong herE?
[19:51] <elopio> sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1629472/comments/3
[19:51] <mup> Bug #1629472: [SRU] New stable micro release 2.19 <verification-needed> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1629472>
[19:51] <elopio> I'm going for lunch. I'm just missing the happy paths of gated and validate.
[19:52] <marcoceppi> sergiusens: o/
[19:53] <marcoceppi> sergiusens: I'm technically not working today, so I haven't been around my computer as much
[19:53] <cprov> elopio: ralsina is off today, can you run `snapcraft gated u1test20161003` ?
[19:54] <elopio> cprov: $ snapcraft gated u1test20161003
[19:54] <elopio> Name    Approved
[19:54] <elopio> prints nothing. I reported a bug about that, too.
[19:54] <elopio> https://bugs.launchpad.net/snapcraft/+bug/1629991
[19:54] <mup> Bug #1629991: snapcraft gated prints no message when there are no gated snaps <Snapcraft:New> <https://launchpad.net/bugs/1629991>
[19:59] <cprov> elopio: I can see your rev. 1 in stable, curl -s -H 'X-Ubuntu-Series: 16' https://search.apps.staging.ubuntu.com/api/v1/snaps/details/u1test20161003?channel=stable | jq-cprov.jq '.revision'
[20:00] <elopio> cprov: yes. But the message says it's not found.
[20:00] <cprov> elopio: can you try `snapcraft validate u1test20161003 ubuntu-core=1` again, so we can confirm it was hitting bad-caching in staging CPI
[20:00] <elopio> cprov: done. Same error.
[20:02] <cprov> elopio: okay, it will need some code changes as well, I've mentioned multiple time in the review that gating snap-id would be better resolved via the SCA account-info, somehow it slip and the code in trunk is using CPI. I will get into this asap
[20:02] <cprov> elopio: is it blocking snapcraft release ?
[20:03] <elopio> cprov: thanks. And I don't know if it should block it. It's ugly to release a command that doesn't work, but sergiusens can just not mention it in the release notes.
[20:03] <elopio> sergiusens: your call.
[20:04] <mup> PR snapd#2046 closed: cmd, disconnect: abbreviated forms of disconnect <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2046>
[20:06] <modprobe__> kyrofa, jdstrand: Bug report filed at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1629996
[20:06] <mup> Bug #1629996: Cannot open /dev/random and /dev/urandom for write <snapd (Ubuntu):New> <https://launchpad.net/bugs/1629996>
[20:06] <sergiusens> cprov yeah, big branches can cause that ;-)
[20:06] <mup> PR snapd#1874 closed: snap: support assertion references in `snap prepare-image` <Reviewed> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1874>
[20:06] <cprov> sergiusens: good point
[20:07] <mup> PR snapd#1767 closed: overlord, daemon: add collect attribute hooks <Reviewed> <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1767>
[20:09] <mup> PR snapd#1613 closed: interfaces/builtin: add dbus-app interface <Blocked> <Reviewed> <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1613>
[20:10] <mup> PR snapd#2067 closed: cmd/snap: trivial auto-import and download tweaks <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2067>
[20:11] <lool> ogra_: thanks, description of the boot files is pretty slick
[20:11] <jgdx> what's the status on Ubuntu Core on RP3? Google returns a AskUbuntu link which is not super up to date
[20:11] <jgdx> ogra_, you know? ^
[20:12] <lool> ogra_: I was actually pinging because of the upcoming dragonboard 600 that you might have seen announced recently
[20:12] <lool> jgdx: pi ?
[20:12] <lool> jgdx: there's a beta image for rpi3 like for the other supported platforms: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
[20:14] <jgdx> lool, cool, thank you
[20:16] <mup> PR snapd#2068 opened: many: preparations for switching most of autoconnect to use the declarations <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/2068>
[20:17] <lool> ogra_: the 600 doesn't have an u-boot port, so we can't follow the same path
[20:17] <lool> ogra_: and there's worth, there might be boards requiring UFS too; at which point we will need a much more complete u-boot
[20:17] <lool> *worse
[20:20] <elopio> cprov: sergiusens: also branches without staging integration tests ;)
[20:22] <cprov> elopio: yeah, it will definitely serve a lesson.
[20:53] <mup> PR snapd#2069 opened: overlord/auth: update CheckMacaroon to verify local snapd macaroons <Created by matiasb> <https://github.com/snapcore/snapd/pull/2069>
[20:56] <sergiusens> elopio cprov from the point of view of the project, it is already released, so not much we can do as soon as it lands on master
[20:57] <sergiusens> elopio I propose to you to do this testing now for history and status ;-)
[20:58] <jgdx> pi3 using that beta image gives me four berries, but nothing more
[21:18] <cprov> elopio: you have to set a new env var for staging UBUNTU_STORE_SEARCH_ROOT_URL='https://search.apps.staging.ubuntu.com/' to make validation work :-/
[21:19] <cprov> elopio: that's why you gating snap was not found.
[21:27] <mup> PR snapd#2069 closed: overlord/auth: update CheckMacaroon to verify local snapd macaroons <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2069>
[21:36] <mwhudson> niemeyer: hey, am i right to think that console-conf should not run if the device is managed?
[21:37] <mwhudson> niemeyer: there is a potential hole where if you use a autoload.assert file to add a user that only has ssh keys and no password and the default network config doesn't work for whatever reason you'll be stuck
[21:38] <mwhudson> the alternative is that console-conf still runs but only presents the network config screen, not the "please enter email" screen
[21:47] <mup> PR snapd#2070 opened: all: move from ubuntu-core to core by default, but still support ubuntu-core as core <Created by chipaca> <https://github.com/snapcore/snapd/pull/2070>
[21:50] <mup> PR snapcraft#847 opened: Implementing channel-closing <Created by cprov> <https://github.com/snapcore/snapcraft/pull/847>
[21:56] <kgunn> kyrofa: you about?
[21:56] <kyrofa> kgunn, I am, what's up?
[21:56] <kgunn> kyrofa: curious, what is the philosophy behind something becoming an official snapcraft part ?
[21:57] <kgunn> https://wiki.ubuntu.com/snapcraft/parts
[21:57] <kgunn> i had someone ask about qtmir and mirclient libs becoming "snapcraft parts"
[21:57] <kgunn> but unsure it makes sense
[21:57] <kgunn> as these are something that are currently in the archive and can easily be listed as a part
[21:58] <kgunn> in the yaml
[21:58] <kgunn> under a nil plugin
[21:58] <kyrofa> kgunn, anything that seems generally useful. If building qtmir for snappy takes a lot of weird config flags, for example, you could make it a part so other people could just say "build qtmir" instead of "ack, how do I build qtmir"
[21:58] <kgunn> kyrofa: hmm, yeah i don't think there's anything special there...
[21:59] <kgunn> definitely not weird
[21:59] <kyrofa> Yeah, if they can just use the archive packages then it's less useful. Still potentially useful from the point of view that it's less typing, but it's of limited usefulness, certainly
[21:59] <kyrofa> kgunn, nothing wrong with adding it, but don't feel obligated
[22:00] <kyrofa> kgunn, now, if you find yourself constantly asking "how do I get mir in a snap," then you could save yourself some time
[22:00] <kyrofa> Not asking, answering
[22:01] <sergiusens> cprov elopio fwiw, it is in the instructions and I was succesful gating and validating a bunch of snaps (even private ones iirc)
[22:01] <Pharaoh_Atem> zyga: this could be quite interesting for fedora's snappy stuff<EMAIL_ADDRESS>[22:02] <kgunn> kyrofa: so it can be used as a template aswell ?
[22:02] <kgunn> i mean the mir-client snap is a template of sorts...but the qtmir and libmirclient are just pkg listings under parts
[22:03] <kgunn> the only thing of interest is the helper file
[22:03] <kgunn> that sets environ flags
[22:04] <kgunn> like  http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/client-start
[22:09] <mwhudson> wheee funtimes https://github.com/snapcore/snapd/pull/2044#issuecomment-251241964
[22:09] <mup> PR snapd#2044: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044>
[22:43] <mup> Bug #1630036 opened: auto import of assertions fails for devices present at boot <Snappy:New> <https://launchpad.net/bugs/1630036>
[23:11] <jdstrand> zyga: fyi, filed bug #1630040
[23:11] <mup> Bug #1630040: [SRU] update to 1.0.42 <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress by zyga> <snap-confine (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1630040>
[23:12] <jdstrand> zyga: will upload in a bit


[11:34] <davmor2> hey guys wifi networking is dead on saucy install I get "Failed to add/activate connection:   (32) Not authorized to control networking."
[11:35] <davmor2> checking the live session now to see if it has the same issue
[11:35] <cjwatson> sounds like something to ask the desktop guys about
[11:35] <cjwatson> unless they say the installer is setting something up wrongly - but even then chances are that would be an upgrade problem
[11:36] <davmor2> cjwatson: so it is working in the live desktop session just not in the installer session
[11:37] <cjwatson> ok, that probably is a ubiquity problem ...
[11:49] <davmor2> bug #1189875
[11:49] <ubot2`> Launchpad bug 1189875 in ubiquity (Ubuntu) "Ubiquity has issues connecting to wifi" [Undecided,New] https://launchpad.net/bugs/1189875
[11:51] <Laney> that might be linked to the lack of logind session registration
[11:51] <Laney> assuming that is still absent
[11:51] <Laney> sounds like a polkit denial anyway
[11:59] <davmor2> Laney: bug has just had the same thing added to it :)
[11:59] <Laney> MAGIC
[12:12] <xnox> davmor2: but ubiquity should offer a page with wifi connectivity and I'd hope that will still work.
[12:45] <davmor2> xnox: Nope that locks up the installer on the wifi page
[12:45] <davmor2> xnox: the installer worked from live desktop
[12:49] <davmor2> xnox: on the wifi page in the installer itself I select the ssid add the passphase click on continue and that is where it stops.
[19:26] <mccartney> what do i need to do to get windows 7 installed on my laptop toshiba c875d? windows 7 cd wont load now it only loads ubuntu from hd.first boot is cd, and i cant format in ntfs useing gparted cause its locked grrr