[00:00] <lifeless> use setuptools, and dhpython or whatever it is will DTRT
[00:02] <smoser> lifeless, thanks, thats what i was thinking.
[02:07] <xnox> smoser: "Files listed in debian/pkg.pyinstall file will be installed as public modules for all requested Python versions" man dh_python2, such that you can skip setuptools ;-) if it's pure python.
[02:07] <xnox> but then you will not have an egg / something to put into cheeseshop.
[02:10] <ScottK> setup.py for such things are trivial.
[02:50] <ScottK> robert_ancell: Is it the lightdm core or just the Unity greeter that requires the Canonical CLA for contributions?
[02:51] <robert_ancell> ScottK, both
[02:51] <ScottK> robert_ancell: Unfortunate.  KDE is looking for an upstream KDM replacement and except for that it was the best candidate.  I was hoping they were wrong.
[02:53] <mbiebl> RAOF: looks like the systemd package in ubuntu is missing a call to dh_girepository
[02:53] <mbiebl> or just use the gir dh addon
[02:54] <ScottK> pitti: ^^^ was that you?
[04:40] <vibhav> What does bzr branch debianlp:package pull the source from?
[04:40] <vibhav> s/What does/From where does/
[04:43] <RAOF> From launchpad's import of debian.
[04:43] <RAOF> vibhav: ^^^
[04:44] <vibhav> RAOF: I mean, from which distro series?
[04:44] <RAOF> That's a fine question!
[04:44] <RAOF> My guess would be sid.
[04:45] <RAOF> IIRC you can make it explicit by pulling debian:testing/package or debian:unstable/package.
[04:45] <RAOF> Or some syntax like that.
[04:45] <vibhav> yes, you can do that
[04:45] <vibhav> I wonder which is the default distroseries
[04:45] <vibhav> yes, probably sid
[04:50] <ScottK> It's Sid.
[04:51] <vibhav> ah, thanks
[05:26] <pitti> Good morning
[05:29] <pitti> ScottK, mbiebl: ah right, that's missing from both our package as well as http://people.debian.org/~biebl/systemd-198/debian/rules; I'll create a patch and send it to mbiebl, thanks for pointing out
[07:42] <dholbach> good morning
[08:17] <mardy> oSoMoN: hi! I'm investigating how to intergate Online Accounts with the browser
[08:18] <mardy> oSoMoN: do you provide an extension mechanism?
[08:18] <mlankhorst> g'day
[08:19] <oSoMoN> mardy: no, there’s nothing like that atm
[08:20] <vibhav> The newest version of blackbox fixes some stuff for m68k, should I mark the merge useless then?
[08:22] <mardy> oSoMoN: currently, for Firefox and Chromium, we have an extension which collects all the cookies for the currently visited domain and forwards them to Online Accounts (in order not to have to re-login in there, when creting an account)
[08:22] <mardy> oSoMoN: do you think that we could get a similar functionality with the Touch browser?
[08:25] <oSoMoN> mardy: sounds doable, we’d have to investigate how to collect the cookies from the QML webview, you have quite some experience with that, don’t you?
[08:28] <mardy> oSoMoN: mmm... not sure :-) I know how to collect the javascript cookies, but we need especially the http cookies
[08:28] <mardy> oSoMoN: AFAIK, the problem is not easily solvable, because of the split-process architecture in webkit2
[08:29] <mardy> oSoMoN: I wonder if we can do anything better than reading the cookies directly from the file where WK2 stores them :-/
[08:31] <oSoMoN> mardy: no clue either… sounds like a question for the webkit-qt ML
[08:33] <mardy> oSoMoN: yep, I'll ask there. Thanks anyway!
[08:35] <bkerensa> vibhav: is it just bug fixes or new features too?
[08:38] <vibhav> bkerensa: afaik, ubuntu doesn't have m68k support
[08:38] <vibhav> (strike me if I am wrong!)
[08:39] <bkerensa> vibhav: hmm in that case I defer :P
[08:39] <vibhav> :)
[08:39] <vibhav> Ill mark it as "not needed" then
[09:46] <sladen> cjohnston_: ta x2!
[09:57] <xnox> infinity: are you interested in doing bug 1012081 ?
[10:07] <pitti> xnox: I have fixed bug 1159997 this morning in my git, FYI
[10:07] <pitti> xnox: uploading now, I just fixed the other outstanding bug
[10:12] <xnox> pitti: snap
[10:12] <infinity> xnox: Yeah, I should do it in experimental and raring (the latter assuming someone other than me gives it an FFe)
[10:12] <xnox> pitti: https://launchpad.net/ubuntu/+source/systemd/198-0ubuntu8
[10:13] <pitti> xnox: sorry for the duplicate work; I should have guessed when you asked me 15 mins ago :)
[10:13] <infinity> xnox: Since I'm on VAC right now, care to see if you can get an FFe from someone else on the release team and let me know? :P
[10:13] <pitti> xnox: argh; rebasing my git tree then, and reuploading; poor buildds
[10:14] <xnox> pitti: sorry =)
[10:14] <pitti> xnox: what provides "--with gir"?
[10:14] <xnox> pitti: gobject-interspection package, which is a Build-Dep already.
[10:14] <pitti> ah, nice
[10:15] <xnox> pitti: I tend to do a lot of `dh --list` and dpkg -S /usr/share/perl5/Debian/Debhelper/Sequ*/foo*
[10:23] <tkamppeter> pitti, are you intending to upload the fixed CUPS (AppArmor) to Ubuntu or should I do so?
[10:25] <pitti> tkamppeter: it doesn't seem urgent enough to warrant an upload just for that IMHO
[10:29] <OdyX> tkamppeter: what is the good upstream way to report foomatic-db updates ?
[10:33] <didrocks> hey infinity! we noticed that daily release doesn't have their .pot/mo imported in launchpad, it seems it's just a flag to set to a non virtualized ppa, do you mind giving us some guidance on what to ask for so that pkgbinarymangler is ran on the ubuntu-unity/daily-build?
[10:35] <OdyX> tkamppeter: my use-case is that Brother MFC-9460CDN works fine with postscript driver for MFC-9450CDN Foomatic/postscript.
[10:36] <infinity> didrocks: I don't think the PPA is doing anything wrong here.  I see the translations tarballs in the upload.
[10:36] <infinity> didrocks: It could be that LP discards/ignores translations when doing copies, but that's wildly more complex to unwind than what you're suggesting. :/
[10:36] <didrocks> infinity: hum, seb128 noticed that the .pot were not updated in launchpad? https://bugs.launchpad.net/cupstream2distro/+bug/1158775
[10:37] <infinity> cjwatson_ / wgrant: ^-- Thoughts?
[10:37] <infinity> didrocks: I'm not arguing with you on whether or not they're being imported, I'm saying that they ARE being built and uploaded in the PPA.
[10:37] <infinity> didrocks: PPAs don't import translations, as that would be madness, only the primary archive does.  So, if they're getting lost, it's in the copy.
[10:38] <cjwatson> Are the translations in question just attached custom uploads?
[10:38] <infinity> cjwatson: Yep.
[10:38] <infinity> cjwatson: https://launchpadlibrarian.net/135275530/unity_6.12.0daily13.03.26-0ubuntu1_amd64.changes
[10:38] <infinity> cjwatson: For example.
[10:38] <cjwatson> Oh, wait.  ROSETTA_TRANSLATIONS uploads aren't marked as copyable
[10:39] <cjwatson> cf. lib/lp/soyuz/scripts/custom_uploads_copier.py
[10:39] <infinity> Perhaps to avoid re-importing on pocket copies?
[10:39] <cjwatson> So that's probably why, but I'm not quite sure why that is ...
[10:39] <cjwatson> Perhaps, not sure
[10:39] <infinity> Not that reimporting tends to harm anything.
[10:39] <cjwatson> That doesn't seem really right either though.  Consider even a copy from quantal-updates to raring
[10:39] <infinity> Or, it shouldn't.
[10:40] <cjwatson> It's more likely that it just wasn't considered, since I embraced and extended the existing custom uploads copier to do what we needed
[10:40] <infinity> So that may just be a dormant misfeature that no one cared about until today.
[10:40] <cjwatson> I don't feel that I know enough about Rosetta to fix it safely, though
[10:41] <infinity> Ursinha might.
[10:41] <infinity> I guess the only real question is "will importing the same tarball version twice break?"
[10:41] <infinity> Which would be easily testable in staging or something.
[10:41] <cjwatson> Yeah
[10:42] <infinity> Since we know reimporting the same exact templates is a non-issue, as we do it daily.
[10:42] <cjwatson> It also might involve some code refactoring
[10:42] <cjwatson> I more or less shoehorned almost all the other custom upload types into the same kind of structure
[10:42] <cjwatson> lp.archivepublisher.*.FooUpload
[10:42] <cjwatson> But ROSETTA_TRANSLATIONS is handled in lp.soyuz.model.queue
[10:43] <cjwatson> So that might need to be hoisted out and mangled into a similar form, to avoid pain
[10:43] <infinity> Translations import handling is fundamentally silly anyway, as previously discussed.
[10:43] <infinity> (There seems to be 0 reason that should be happening syncronously in the publisher...)
[10:44] <infinity> Not that that's relevant to today's issue, but if someone's going refactoring. :P
[10:44] <cjwatson> Well, sure, I filed a bug about that a while back :)
[10:44] <cjwatson> bug 1064895
[10:45] <cjwatson> So, sure, if Ursinha wants to have a go then this'd be a good thing to sort out
[10:45] <infinity> cjwatson: I need to go find some bed (and get back to being on VAC), want to chase this up with wgrant/stevenk and see if there seems to be an easy way out?  And yeah, Ursinha's previous rosetta experience may prove handy here.
[10:46] <cjwatson> Shuffling it out to an async job isn't really directly related; it would just be easier with the code in question pulled out of queue acceptance
[10:46] <infinity> didrocks: If there's no quick way out of this, would you guys be against slamming some manual uploads directly at the archive to get your templates imported? :/
[10:46] <didrocks> infinity: well, whatever is unblocking for this release. I can surely do that everytime we have a new string, which will happen for 40 components in the 100scopes projects, but after that, it should be minimal. So sounds good :)
[10:46] <cjwatson> Sure - I'm guessing it might be next .au morning at this point
[10:47] <seb128> infinity, I did that friday, uploading updated templates manually
[10:47] <didrocks> infinity: as long as something is on track to get it working on the long term ;)
[10:47]  * infinity nods.
[10:47] <seb128> infinity, so we are fine for raring
[10:47] <infinity> seb128: Okay, good to know.
[10:48] <didrocks> seb128: well, we'll have all the new strings from 100scopes, so yeah, 40 more uploads to come (and launchpad karma… :p)
[10:48] <didrocks> but I knew I would get bored on the 1st of April :)
[10:48] <seb128> lol
[10:48] <infinity> Still feels like a fairly urgent bug, as "we're good for raring" often translates to "we'll forget about this for another six months and panic again", which would be suboptimal.
[10:48] <seb128> didrocks, the smart scopes have strings reflecting in the ui?
[10:49] <didrocks> seb128: yeah, for filters
[10:49] <seb128> didrocks, well, there are the filters, but most are only a name (e.g "tomboy")
[10:49] <seb128> so they don't really need translation
[10:49] <didrocks> or the no result hint
[10:49] <didrocks> Sorry, there are no Zotero results that match your search.
[10:49] <didrocks> for instance
[10:49] <seb128> k
[10:50] <seb128> so yeah, we will have to upload those templates, easy to script ;-)
[10:50] <didrocks> seb128: you volonteer? :)
[10:50] <seb128> didrocks, can do
[10:50] <didrocks> \o/
[10:50]  * didrocks goes back in a 100 insanelyness ;)
[10:50] <didrocks> thanks seb128, infinity, cjwatson
[10:50] <seb128> thanks
[11:01] <tkamppeter> OdyX, upstream bug tracker for Foomatic is http://bugs.linuxfoundation.org/, product OpenPrinting.
[11:13] <ev> pitti: remind me where the LP retracers live?
[11:14] <pitti> ev: on the i386/amd64 porter box, osageorange
[11:15] <ev> ahh, thanks
[11:15]  * ev updates https://wiki.canonical.com/UbuntuEngineering/QA/ApportRetracerMaintenance
[11:20] <maxb> Canonical was really scraping the bottom of the fruit naming convention for that one, I see :-)
[11:20] <infinity> There were worse.
[11:21] <infinity> Most internal, and some so awful they got vetoed. :P
[11:23] <ev> pitti: did you happen to see my message from yesterday? Can you confirm that once we have packages in -proposed, we can't retrace crashes from the regular release on the LP retracers.
[11:23] <ev> We're trying to deploy retracers on prodstack and ran into this: https://pastebin.canonical.com/87608/
[11:23] <ev> I'm thinking we should treat -proposed as special in that check
[11:23] <ev> or maybe just try the retrace anyway and see what happens :)
[11:32] <pitti> ev: that's right, the sandbox building logic only looks at the current package in apt right now
[11:32] <pitti> ev: it would be better to check the versions in Package and Dependencies and then try to find that particular version
[11:33] <ev> pitti: okay, I'll work on a branch for that today
[11:34] <ev> thanks
[11:41] <ev> pitti: oh also, before I subject the population of Ubuntu users to uploading core files more often, I'd appreciate your feedback on this idea: https://bugs.launchpad.net/daisy/+bug/1159849
[11:42] <ev> whenever you have spare time, that is
[12:30] <pitti> xnox: and once again empty :) https://launchpad.net/ubuntu/+source/systemd/+bugs
[12:30] <pitti> ev: I opened a tab, will look ASAP
[12:34] <ev> thanks
[13:17] <cjwatson> plars: firewalls and cdimage code are all ready for you to have a try at the cdimage current symlink updating thing now (this time for real)
[13:20] <rbasak> Feeling a bit freaked out by floating heads in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703906. When did they start to appear?
[13:21] <cjwatson> rbasak: http://www.donarmstrong.com/posts/libravatar_for_bts/
[13:23] <rbasak> Erm...thanks :)
[13:23] <plars> cjwatson: cjwatson ok, send me the details if you don't mind on what I need to run. I discovered a bit more work that has to happen on this side, mostly due to the fact that we have some legacy stuff happening for precise, and changed the process a bit for raring+
[13:32] <cjwatson> plars: ssh cdimage@nusakan /srv/cdimage.ubuntu.com/bin/mark-current --project=ubuntu --series=raring --publish-type=desktop --architecture=i386 20130326
[13:32] <cjwatson> plars: replace as appropriate
[13:33] <plars> cjwatson: and that will need to run from only that IP I gave you the other day, or it can happen from anywhere in our lab?
[13:33] <cjwatson> plars: full option parser is in https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/tree.py
[13:34] <cjwatson> plars: It's currently locked to only 10.97.0.6 and 10.98.0.1, both in firewalls and in authorized_keys.  If you need to run it from somewhere else then IS need to update both of those
[13:35] <cjwatson> (in fact, 'ssh cdimage@nusakan /srv/cdimage.ubuntu.com/bin/mark-current --help' should work from those IPs, if I got t right)
[13:35] <cjwatson> *it
[13:36] <cjwatson> plars: It'd be great if you could try it out by hand if possible, just to make sure that things are good from my side
[13:39] <cjwatson> plars: Note that I need to maintain a list of which images are having their current symlink maintained this way, so it'd be good if you could drop me a note whenever you turn something on.  I'll probably notice eventually from logs though
[13:40] <plars> cjwatson: I'll do that. the ssh seems to timeout at the moment, let me talk to our lab guy a moment.  we may need to use a different ip
[13:44] <plars> cjwatson: ok, apparently the IPs I had were the VPN IPs, we need a different ip for the firewall. Is there a ticket still open on this, or should I just open a new ticket to get that changed?
[13:45] <xnox> rbasak: bts supports "settings" and you can turn it off, if you find it creepy & disturbing =) imho it should be floating on the right.....
[13:46] <rbasak> xnox: I prefer heads that are attached to bodies. Preferably when both are alive, too :-)
[13:47] <xnox> rbasak: min avatar got "banned" from debian planet. But you can see it on the bts: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606825
[13:47] <cjwatson> plars: the ticket's already had problems with confusion, and is now closed - might be best if you opened a new ticket and I can ack/clarify as needed
[13:47] <cjwatson> plars: make sure to ask for both the firewall and /etc/ssh/user-authorized-keys/cdimage to be changed
[13:48] <plars> cjwatson: ok, I'm finding out that the other IP for the PS system needs changing too, I'll get it sorted out with retoaded and get it fixed. Thanks
[13:49] <cjwatson> Makes sense
[13:49] <cjwatson> cdimage will now explicitly log when current symlink updates are requested for images it didn't know were trigger-controlled, so I can probably just grep for that rather than you having to coordinate carefully with me
[13:50] <cjwatson> You'll notice if it's uncoordinated because it'll just point current to the latest build any time one happens :)
[13:51] <cjwatson> plars: And I see PS Jenkins is being moved to a new host so I guess that'll need to be sorted out too ...
[13:52] <plars> cjwatson: yes, and I'll make sure that one is corrected as well
[13:54] <cjwatson> I've optimistically marked my WI for this done, anyway; I'm fairly sure it's at worst minor debugging now
[13:55]  * cjwatson wonders if he has had enough coffee to tackle rewriting publish-release
[13:56] <xnox> plars: note, that jenkins is moving =) *perfect timing*
[14:03] <GunnarHj> cjwatson: Hi Colin, and thanks for uploading the openssh patch at bug 952185 to Raring. Steve created a Precise task too, but I wouldn't be the right person to prepare it, since I don't know what the test case would look like. Can you ask somebody who is enough ssh proficient to do it?
[14:04] <cjwatson> GunnarHj: that's probably me :)
[14:04] <GunnarHj> cjwatson: Great, then you can ask yourself. :)
[14:05] <GunnarHj> cjwatson: Can you put it on your todo list?
[14:05] <cjwatson> Let me just do it now
[14:06] <GunnarHj> cjwatson: Ok, great.
[14:11] <cjwatson> GunnarHj: I think it can just be the same SRU description as lightdm and gdm, aside from trivial differences in wording - do you have any reason to think otherwise that I might have missed?
[14:12] <cjwatson> GunnarHj: I've adjusted the bug description thus
[14:16] <cjwatson> GunnarHj: and uploaded openssh 1:5.9p1-5ubuntu1.1 to precise-proposed, pending SRU team review
[14:22] <GunnarHj> cjwatson: Sorry, away from kb for a few minutes. No, I have no reason to think that the description wouldn't fit. OTOH I can't confirm that it fits either. ;-) Thanks!
[14:23] <cjwatson> heh, ok
[14:35] <freeflyi1g> hi there, do we need FFe for those native package speific to Ubuntu like default-setting and theme?
[14:37] <GunnarHj> I'm struggling with fonts and font configuration at bug 1153188 without knowing very much about it. It's about how you make the system actually use a desired font when rendering text in a language, in this case Urdu. Anybody out there who is able to give a helping hand?
[14:39] <cjwatson> freeflyi1g: If changes to them are new features, yes
[14:40] <TheLordOfTime> also, crossposting is discouraged.  (was posted here and in -motu)
[14:40] <freeflyi1g> cjwatson: noted, thanks
[14:45] <SpamapS>  4243 clint     20   0  647m  46m  12m R 100.0  1.2  11:09.66 unity-lens-phot
[15:05] <ttx> jamespage: ceilometer MP branch cut
[15:05] <ttx> dunno if you track that one
[15:05] <jamespage> ttx: we do
[15:05] <jamespage> thanks
[15:05] <ttx> jamespage: that's the last one. Cheers!
[15:05] <jamespage> great!
[15:27] <FourDollars> Hi, could someone review my patch of https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414 ?
[15:30] <mitya57> FourDollars: please file a merge proposal against raring (lp:ubuntu/ibus-chewing)
[15:31] <FourDollars> mitya57: There is no need to file a merge proposal against raring. Thoses patches come from raring.
[15:31] <mitya57> FourDollars: then just file a MP :)
[15:31]  * mitya57 can't upload, but can leave a +1
[15:32] <FourDollars> mitya57: To where? lp:ubuntu/quantal/ibus-chewing and lp:ubuntu/precise/ibus-chewing ?
[15:32] <FourDollars> https://code.launchpad.net/ubuntu/+source/ibus-chewing
[15:32] <chilicuil> kenvandine: ping
[15:33] <FourDollars> There is no lp:ubuntu/precise-proposed/ibus-chewing or lp:ubuntu/quantal-proposed/ibus-chewing on https://code.launchpad.net/ubuntu/+source/ibus-chewing .
[15:33] <mitya57> FourDollars: just lp:ubuntu/precise/ibus-chewing or lp:ubuntu/quantal/ibus-chewing
[15:34] <FourDollars> mitya57: OK.
[15:34] <kenvandine> chilicuil, pong
[15:35] <FourDollars> mitya57: https://code.launchpad.net/~fourdollars/ubuntu/precise/ibus-chewing/lp1160414/+merge/155528 and https://code.launchpad.net/~fourdollars/ubuntu/quantal/ibus-chewing/lp1160414/+merge/155527
[15:35] <chilicuil> kenvandine: hey, I'm testing the gwibber package from the friends ppa before it go to raring and the gwibber interface doesn't work, is there any way I can report a bug against those packages?
[15:36] <kenvandine> chilicuil, what are you seeing?
[15:37] <kenvandine> chilicuil, want to join #gwibber and we can debug?
[15:37] <chilicuil> kenvandine: yep
[15:39] <FourDollars> mitya57: Thank you. :)
[15:55] <ev> there's a new version of https://errors.ubuntu.com/ out. Let me know what you think.
[15:56] <seb128> ev, http://ubuntuone.com/0McV8himWSAQ2tToHaXedH
[15:56] <seb128> ev, is that the wanted start page?
[15:56] <bdmurray> I had to do a shift reload
[15:56] <ev> seb128: hit refresh harder :) ctrl-shift-n or what-have-you
[15:56] <mitya57> ev: still only for canonical-ers? :)
[15:57] <ev> mitya57: sadly, yes. Still waiting on legal for an NDA.
[15:57] <ev> slangasek: ^
[15:57] <seb128> ev, ok, works after a firefox restart, weird ... thanks ;-)
[15:57] <ev> seb128: sure thing :)
[15:58] <seb128> ev, the orange box in the top left corner is weird ;-)
[15:58] <ev> seb128: send design complaints to mpt at the usual domain dot com :)
[15:58] <seb128> hehe
[15:59] <ev> unless they're me failing to implement things as designed
[15:59] <seb128> ev, is the design document available somewhere for comparaison?
[15:59] <ev> seb128: https://wiki.ubuntu.com/ErrorTracker#errors.ubuntu.com
[16:00] <seb128> ev, ah, that orange box should be an ubuntu project logo according to the design ;-)
[16:00] <ev> seb128: the reason for that is that we do not yet have an Ubuntu project global navigation
[16:00] <ev> oh yes, and that :)
[16:00] <seb128> bah, it is now
[16:00]  * seb128 kicks firefox
[16:01] <ev> there's work being undertaken by the web and design teams to refresh the navigation structure, and hopefully we'll get an "Ubuntu project" hierarchy out of that
[16:01] <ev> but until then we don't have anything to point at
[16:02] <ev> since our links off to qa.ubuntu.com all became as dead as that site itself
[16:06] <jcastro_> wow, teamviewerd crashing lsb_release seems overly popular.
[16:11] <ev> jcastro_: iknowright
[16:21] <mitya57> ev: if you have some time, can you show me some stacktraces (I asked on #ubuntu-bugs yesterday, but nobody wanted to do that)?
[16:21] <mitya57> http://paste.ubuntu.com/5649740/
[16:25] <ev> mitya57: looking
[16:26] <rbasak> jibel: hey, with lxc-create -t ubuntu-cloud I get "Only i386 and amd64 are supported by the ubuntu cloud template.". Easy enough to bypass, but is there something I'm missing?
[16:30] <xnox> ev: wow, awesome =) how did it know that I like filesystem packages only?! =)))))) awesome.
[16:30] <ev> xnox: you can thank bdmurray for that part :)
[16:30] <xnox> ev: why is precise converging with quantal on error (e.g. increasing?!)
[16:31] <xnox> since december there is strong correlation and tendancy for precise to be a quantal look a like.
[16:32] <didrocks> stgraber: just to confirm re transition freeze/hard freee. The freeze that you propose for beta2 is just proposed -> raring, right?
[16:32] <jibel> rbasak, yes, it is bug 1159818, I had to modify the template to allow armhf
[16:34] <rbasak> jibel: got it - thanks. I noticed that sources.list was wrong afterwards and had to fix it up manually
[16:34] <ev> xnox: indeed. The data checks out as well.
[16:34] <bdmurray> xnox: I wonder if it is the lsb-release bug bumping up precise
[16:34] <bdmurray> or the aptdaemon one line diff bug
[16:36] <jibel> rbasak, you'll also need to specify the url of the tarball, ubuntu-cloudimg-query doesn't find an AMI for arm
[16:38] <bdmurray> I mean bug 1120322
[16:40] <stgraber> didrocks: yes
[16:41] <didrocks> stgraber: so on the 1st of April I would be able to push to proposed the 100scopes, isn't it?
[16:42] <stgraber> didrocks: though I'd like to get the opinion of other release team members before deciding what to do after beta2. ScottK has a good point wrt having control on what happens between the last two images, but I was hoping for other people to express their opinion...
[16:42] <stgraber> didrocks: you'll be able to upload, yes. It won't land on people's machines though as I expect unity to be part of the migration freeze
[16:43] <didrocks> stgraber: ok
[17:21] <jibel> rbasak, I filed bug 1160488 for the second part of the problem with update-initramfs
[17:23] <ogra_> jibel, thats intentional
[17:23] <ogra_> the installer needs to install u-boot-tools
[17:24] <ogra_> (and theoretically your u-boot shouldnt use mkimage at all, we switched to uEnv.txt and preEnv.txt quite a while ago)
[17:24] <rbasak> ogra_: flash-kernel uses mkimage. It's from Debian.
[17:25] <ogra_> rbasak, ?
[17:25] <ogra_> if it does, thats a bug
[17:25] <ogra_> none of our supported arches should use mkimage at all
[17:25] <rbasak> IIRC, it's a major component of flash-kernel. Am I missing something?
[17:25] <ogra_> yes, the switch to plain text configs about a year ago :)
[17:26] <ogra_> for unsupported debian arches flash-kernel-installer should care to install it during installation though
[17:27] <ogra_> (dont ask me if it does, i dont test unsupported arches)
[17:27] <rbasak> ogra_: how does flash-kernel know whether to use mkimage or not? I don't see a flag in all.db
[17:27] <ogra_> if you would have a dep you would install mkimage everywhere ... not every arm board uses u-boot
[17:28] <ogra_> in ubuntu it simply doesnt unless you special cased it
[17:28] <rbasak> I must be missing something. I didn't special case anything, and it does use mkimage
[17:28] <ogra_> it uses /etc/default/flash-kernel and assembles the cmdline from that ... then dumps it into uEnv.txt
[17:29] <ogra_> what arch ?
[17:29] <rbasak> From memory, armadaxp and highbank in precise and quantal, and AIUI this bug is because omap4 is doing it.
[17:29] <rbasak> (in raring)
[17:30] <ogra_> i see -generic
[17:30] <ogra_> which means omap3
[17:30] <ogra_> which we dont even actively support
[17:30] <ogra_> but yeah, that will need adjustment
[17:30] <ogra_> to use uEnv.txt ... i guess it gets confused with the -generic kernel
[17:31] <ogra_> i dont think we have any other arch but omap in generic currently
[17:32] <NishanthMenon> uEnv.txt is now supported in u-boot upstream http://patchwork.ozlabs.org/patch/209925/
[17:32] <NishanthMenon> for omap4
[17:32] <ogra_> sicne a year or so
[17:32] <ogra_> omap4 didnt change in ubuntu ...
[17:32] <ogra_> still uses the quantal kernel
[17:32] <ogra_> and will go on to do so (and vanish in 13.10)
[17:33] <ogra_> but omap4 defaults to uEnv.txt since 12.10 anyway
[17:33] <ogra_> (since the beginning of the 12.10 dev cycle actually)
[17:34] <ogra_> rbasak, anyway, if you have an arch that doesnt support uEnv.txt, please make it use it ... if you cant you need to special case it in f-k-i and make it install mkimage
[17:35] <rbasak> ogra_: has this change been documented anywhere? I wasn't aware that anything in flash-kernel had changed.
[17:35] <rbasak> ogra_: and what in flash-kernel differentiates the two cases? Something in all.db?
[17:35] <ogra_> there was a spec for 12.10 iirc
[17:36] <ogra_> rbasak, nothing differentiates, the expectation is that by noiw all u-boot arches we support use uEnv.txt
[17:36] <ogra_> thats why i say you need to special case or fix your u-boot
[17:37] <rbasak> ogra_: so how is it that omap3 and highbank/armadaxp in 12.10 manage to get flash-kernel to use mkimage?
[17:37] <ogra_> omap3 doesnt
[17:37] <ogra_> it uses uEnv.txt
[17:38] <ogra_> and i never touched either of the other two, check the code in 12.10
[17:38] <rbasak> So why does bug 1160360 happen when a call to mkimage fails?
[17:38] <ogra_> err
[17:38] <ogra_> why would you call mkimage in an LXC container ?
[17:38] <ogra_> you should teach f-k about LXC :)
[17:38] <rbasak> Well exactly. You tell me. You're telling me that flash-kernel does not call mkimage.
[17:39] <rbasak> Yet it does.
[17:39] <ogra_> it does what ?
[17:39] <rbasak> Call mkimage
[17:39] <ogra_> fix that then :)
[17:39] <ogra_> you dont want f-k to even run in LXC
[17:40] <rbasak> Yeah, that's a separate thing. I don't want f-k to even be installed in LXC
[17:40] <ogra_> your container creation tool should put FLASH_KERNEL_SKIP=true into /etc/environment or some such
[17:40] <ogra_> or yeah, dont install it at all if your deps allow
[17:40] <rbasak> But what you're telling me about uEnv.txt conflicts with both my (limited) knowledge of flash-kernel and observed behaviour, and I don't understand why.
[17:41] <ogra_> i would guess it uses a debian default fallback
[17:42] <ogra_> ogra@anubis:~/Devel/packages/flash-kernel-3.0~rc.4ubuntu30$ grep uEnv db/all.db
[17:42] <ogra_> U-Boot-Script-Name: uEnvtxt.omap
[17:42] <ogra_> U-Boot-Script-Name: uEnvtxt.omap
[17:42] <ogra_> use that for whatever arch you want to switch over (and make sure u-boot understands it ... by having a new enough u-boot)
[17:43] <ogra_> i assume what you see with -generic is just a debian fallback since f-k doesnt know about -generic yet
[17:43] <ogra_> and for LXC simply use the global var or avoid having it installed
[17:43] <rbasak> So there's magic in these filenames?
[17:44] <rbasak> Where's this magic documented?
[17:44] <ogra_> there is a case statement in f-k (see the code)
[17:44] <rbasak> I don't see it in the README
[17:44] <ogra_> as i said, there was a spec for 12.10 ... i currently cant find ... and i sent a mail to ubuntu-devel whern it was switched
[17:45] <ogra_> so file a bug about the README :) i didnt add it there
[17:47] <ogra_> the code is pretty obvious though
[17:47] <rbasak> Indeed. Now that I know it's there.
[17:47] <ogra_> sorry for the missing docs ...
[17:48] <rbasak> I see an email to ubuntu-devel on May 30 but no mention of this change.
[17:49] <rbasak> And I don't recall a spec or a session

[17:51] <ogra_> rbasak, if you need mkimage, make sure it is in Optional-Packages in your db entry (that hanst changes since we got the new f-k from debian)
[17:51] <ogra_> or in "Required-Packages"
[17:51] <rbasak> I have no idea where I need mkimage or not.
[17:52] <ogra_> Machine: Highbank
[17:52] <ogra_> Kernel-Flavors: highbank
[17:52] <ogra_> Required-Packages: u-boot-tools
[17:52] <ogra_> Kernel-Flavors: armadaxp ...
[17:52] <ogra_> Required-Packages: u-boot-tools
[17:53] <ogra_> both arches you seem to care about have it
[17:53] <rbasak> This issue is about the cloud image, eg. as used for lxc
[17:54] <ogra_> right avoid f-k altogether there
[17:54] <rbasak> Where I don't need flash-kernel at all. I'll look into the dependencies and see if we can ship without it.
[17:54] <ogra_> if you cant, use the /etc/environment setting
[17:54] <ogra_> thats what we added it for
[17:59] <cjwatson> ogra_,rbasak: I think I saw an unresolved Debian RC bug about f-k Required-Packages not working properly
[18:00] <ogra_> cjwatson, well, looking at flash-kernel-installer i wouldnt see how
[18:00] <cjwatson> Nor did the bug report, but still
[18:00] <ogra_> it just blindly installs them with apt-install
[18:00] <cjwatson> Debian #693839
[18:00] <cjwatson> feel free to investigate that; dinnertime here :)
[18:01] <cjwatson> it sounds kinda related
[18:01] <ogra_> argh
[18:01] <ogra_> thats definitely a totally wrong fix
[18:02] <ogra_> its like adding a hard dep on lilo on all kernel packages
[18:02] <ogra_> because one could use it
[18:03] <ogra_> ah, phew, Martin Michlmayr seems to have stopped it
[18:11] <ogra_> argh
[18:11] <ogra_> so now someone tell me why my disk on precise just got filled with several 100G
[18:12] <seb128> ogra_, trying to do an offline copy of the internet? ;-)
[18:12] <ogra_> seb128, not funny, it ate like 150G over 20min ... and i only have FF, xchat, evo and three terminals open
[18:13] <ogra_> i still see write operations in the multiload indicator going on, but cant make out where they come from
[18:13] <seb128> ogra_, try to run baobab or similar to see where the space went?
[18:13] <seb128> ogra_, ls -l ~/.xsession-errors?
[18:13] <ogra_> iotop shows nothing
[18:13] <ogra_> GEEZ !
[18:13] <ogra_> 34G
[18:14] <seb128> that's not 150G
[18:14] <seb128> but that's a start
[18:14] <ogra_> (indicator-weather:3113): LIBDBUSMENU-GLIB-CRITICAL **: dbusmenu_menuitem_build_variant: assertion `DBUSMENU_IS_MENUITEM(mi)' failed
[18:14] <ogra_> (indicator-weather:3113): LIBDBUSMENU-GLIB-CRITICAL **: dbusmenu_menuitem_build_variant: assertion `DBUSMENU_IS_MENUITEM(mi)' failed
[18:14] <ogra_> GRR
[18:14] <ogra_> that silly thing
[18:14] <seb128> indicator-weather is quite buggy, and unfortunatly quite popular as well :-(
[18:14] <ogra_> might be that there are somne steam games that have been updated in the bg without me noticing
[18:15] <ogra_> that might be the other 100G, i only really noticed it within the last 20min
[18:15] <ogra_> since i rebooted ... after doing a dist-upgrade today
[18:15] <seb128> ogra_, run baobab and see what directories are taking space
[18:17] <ogra_> running ... though i fear it wont get alkong with my levels of symlinks
[18:17]  * ogra_ has a 3TB disk mount symlinked inside his home
[18:18] <ogra_> seb128, that xsession-errors is only a few hours old ... people on precise will all fall over if they use the weather indicator
[18:19] <ogra_> we should do an emergency revert of whatever changed
[18:19] <seb128> ogra_, we had a few reports about it going crazy
[18:19] <ogra_> else we will have funny easter bugmails
[18:19] <seb128> ogra_, I don't think it's a new issue
[18:19] <seb128> you just got unlucky that you hit that race/bug today
[18:19] <ogra_> getting a 36G log within a few hours after reboot ?
[18:20] <seb128> ogra_, well, it hit an error loop and is flooding your log at the capacity of your machine
[18:20] <ogra_> right, i got a diskspace warning popup
[18:20] <seb128> ogra_, but as said, it's not a new issue afaik, it's just not frequent, you just happened to hit it
[18:20] <ogra_> never had that since i installed this machine
[18:21] <ogra_> ok
[18:21] <seb128> it's like winning the lottery
[18:21] <ogra_> i thought it came with todays upgrade
[18:21] <seb128> without the money :p
[18:21] <ogra_> \o/
[18:21] <ogra_> :(
[18:23] <ogra_> oh, wow, i have a ~/.cache/tracker/ directory that has a few G ... from 2011
[18:25] <slangasek> cool, nice to know that xsession-errors handling is LFS-clean
[18:25] <slangasek> no truncated error logs for you!
[18:25] <ogra_> haha
[18:26] <ogra_> bah, smells like the evolution default folder changed
[18:27] <ogra_> i have one 2G big ~/.evolution and a ~/.local/evolution that has 18G
[18:29] <ogra_> heh, and baobab realyl doesnt get along with my symlink to my 3TB disk in ~
[18:29] <ogra_> it counts the filled up space to the size of my home
[18:30] <ogra_> but doesnt count the free space of the disk :)
[18:31] <ogra_> oh, fun ... and removing ~/.xsession-errors doesnt seem to have any effect in df
[18:31] <slangasek> yes, because it's still open for writing
[18:31] <ogra_> even after two syncs
[18:31] <ogra_> sigh ...
[18:31] <slangasek> rm'ing a file doesn't free any space on the fs while there are still fds open to it
[18:31]  * ogra_ logs out
[18:31] <ogra_> yeah
[18:36] <ogra_> that didnt go so well
[18:36] <ogra_> my desktop machine is completely dead now
[18:36] <ogra_> logging out didnt get me lightdm back ...  disk LED is constantly active, console switching doesnt work
[18:37] <ogra_> (active as in wildly flickering, not solid)
[18:38] <ogra_> given that this is a plain 12.04 with not much extra  software and i explicitly didnt tinker with it to retain the best stability i must say i'm pretty disappointed
[18:38] <ogra_> (worked rock solid until todays upgrade)
[18:39] <seb128> ogra_, what's the issue for login after you freed space?
[18:39] <ogra_> well, no lightdm
[18:39] <seb128> sudo restart lightdm?
[18:39] <ogra_> i switched to tty1 and restarted it ...
[18:39] <ogra_> didnt come up, cant switch consoles anymore
[18:39] <seb128> ogra_, and you did 'tinker' it by installing indicator-weather...
[18:40] <seb128> ogra_, sudo stop lightdm
[18:40] <seb128> sudo lightdm
[18:40] <ogra_> seb128, didnt tinker "much"
[18:40] <seb128> is there any error?
[18:40] <seb128> or check in /var/log/lightdm
[18:40] <ogra_> i did what my mom or my sister would have done with such a machine ... i dont even use apt on it but resort to UI
[18:40]  * ogra_ checks if ssh still works 
[18:41] <seb128> right, the ENOSPACE handling is suboptimal :-(
[18:41] <seb128> and the fact that error logs can file up the disk is a known issue
[18:41] <ogra_> sudo lightdm returns immediately
[18:41] <ogra_> though indeed i'm in via ssh
[18:41] <seb128> is there a running instance?
[18:41] <ogra_> there is no way tpo get to console
[18:42] <seb128> rm .xsession-errors* and reboot maybe?
[18:42] <ogra_> 8217 tty7     Ss+    0:00 /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitc
[18:42] <ogra_> i removed the log before loggin out
[18:42] <seb128> df is showing space?
[18:42] <ogra_> but yeah, i'll trigger a reboot via ssh
[18:42] <ogra_> df shoows 40G free
[18:42] <seb128> k, reboot I guess...
[18:43] <ogra_> running already
[18:45] <ogra_> ok, it is back
[18:45] <ogra_> but this is seriously an experience i wouldnt want a normal enduser to have
[18:46] <ogra_> without ssh i wouldnt have been able to recover cleanly (apart from the reset button indeed)
[18:47] <seb128> yeah :(
[18:49] <seb128> we use to have ubuntu booting/logging in fine on full disk
[18:49] <seb128> but I don't think we did check that was still working over cycles
[18:49] <seb128> so I'm not sure it still does
[18:49] <ogra_> well, i'm not sure why lightdm didnt come up again
[18:49] <seb128> me neither
[18:49] <seb128> but you had an Xorg running according to ps
[18:50] <ogra_> i did a df first before restarting it
[18:50] <seb128> and vt changes were not working
[18:50] <seb128> seems like your kernel was in a weird state
[18:50] <ogra_> hmm, might be
[18:50] <ogra_> i dont run the quantal stack ... just the plain 12.04 kernel
[18:50] <ogra_> but havent had probs with that before
[18:50] <seb128> could be a side effect of the full disk...
[18:51] <ogra_> yep
[18:53] <ogra_> well, at least xsession-errors doesnt grow anymore
[18:53] <seb128> not likely you will run into the indicator-weather bug anytime soon
[18:54] <ogra_> well, it crashed for the first half of precise since release ....
[18:54] <ogra_> now it doesnt crash anymore but eats my disk at times
[18:55]  * ogra_ will just write his own weather indicator some day ... i cant do worse i guess :P
[18:57] <ogra_> slangasek, sooo ... there is that other precise bug i recently ran into ... (though i guess it shows on later releases too) ... and i wonder if we have a plan for it
[18:58] <ogra_> slangasek, dpkg --add-architecture armhf ... breaks apt
[18:58] <slangasek> breaks it how?
[18:58] <ogra_> well, the logic is flawed, it tries to get security updates from security.u.c
[18:58] <ogra_> and i'm still unsure what to file it agains
[18:58] <ogra_> t
[18:58] <slangasek> ogra_: WFM here... you just need to mess with /etc/apt/sources.list* to tell it which architectures are available on which source
[18:59] <ogra_> i did a dpkg action, but that breaks apt
[18:59] <slangasek> e.g.: deb [arch=amd64,i386] http://mirrors.cat.pdx.edu/ubuntu/ raring main restricted
[18:59] <slangasek> deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ raring main restricted
[18:59] <ogra_> slangasek, heh, indeed, i could tinker with it ...
[18:59] <ogra_> and i know how to do that ...
[18:59] <ogra_> but the occasional user doesnt
[18:59] <slangasek> the occasional user won't be installing armhf binaries on x86
[18:59] <ogra_> i think we should fix that somehow
[18:59] <slangasek> this is a developer feature
[19:00] <slangasek> well, we can fix it for later releases by getting armhf moved onto the main mirrors :)
[19:00] <ogra_> heh, yeah ... only trying that since like 4 years now
[19:01] <ogra_> i think we should omit security in case of ports arches on a low level
[19:02] <ogra_> if we know we are "foreign"
[19:02] <ogra_> devs can still add a sources.list entry but at least it wouldnt be broken by default
[19:03] <slangasek> no, we're not going to hard-code rules about architecture:mirror mappings into apt
[19:03] <ogra_> (i agree its a dev feature, i just think "broken by default" isnt the right thing)
[19:03] <slangasek> apt giving you warnings about package files not being downloadable isn't really "broken"
[19:03] <ogra_> i dont care about apt
[19:04] <ogra_> update-manager and sw-center completely stop working
[19:04] <ogra_> andi get a warning indicator icon
[19:05] <slangasek> ah, yes
[19:05] <slangasek> so that might be something that needs to be fixed in update-manager/update-notifier
[19:06] <ogra_> right
[19:07] <ogra_> (we could indeed just move armhf to the main archive ... that might be a good reason finally ... all former reasons infinity, davidm or i tried to bring up weren compelling enough apparently :) )
[19:07] <ogra_> *weren't
[19:07] <slangasek> I don't think this reason is more compelling than others
[19:07] <slangasek> I thought we already had agreement that armhf should be moved to the main mirrors
[19:08] <ogra_> dont trash my hope :)
[19:08] <ogra_> when did that happen ?
[19:08] <slangasek> "Months ago"
[19:08] <slangasek> I think it just hasn't been a priority to make the move happen
[19:08] <ogra_> veerytime i asked in the past there was this "no we dont want to make mirror admins grumpy" thing
[19:09] <ogra_> *everytime
[19:09] <slangasek> elmo: can you refresh my memory as to whether there are any remaining blockers for moving armhf onto archive.u.c?
[19:09] <doko> seb128, are any more gnome/gtk updates expected this week?
[19:11] <elmo> slangasek: say what now?
[19:13] <slangasek> elmo: well, last time robbiew was asking about it (because of cloud archive-y reasons), he seemed to think it was blocked by concerns from the archive admins... I redirected him to "IS" and never heard anything more :)
[19:14] <robbiew> whoa
[19:14] <robbiew> slangasek: pgraner took it ;)
[19:14] <slangasek> hah what
[19:15] <robbiew> slangasek: talk to pgraner...it was sitting with him
[19:15] <ogra_> LOl
[19:15] <ogra_> seems i triggered something ... sorry :)
[19:15] <slangasek> robbiew: seriously?  how did "Do we have enough space on mirrors to move armhf to archive.u.c" become pgraner's problem? :)
[19:18] <slangasek> pgraner: can we move armhf to the main mirrors? :)
[19:18] <elmo> slangasek: the answer is the same answer it's been for the last N years.  moving armhf to archive.u.c will bloat archive.u.c; this will a) cost Canonical more money (from expanding the expensive HW used to run archive.u.c), b) cost mirrors more money, c) cause an unknown but I suspect non-trivial number of mirrors to stop mirroring Ubuntu, d) cost Canonical more money in bandwidth bills because of (c)
[19:19] <elmo> slangasek: every time it's come up previously, we've run the usage numbers of arm* and it's never remotely been justifiable
[19:20] <infinity> slangasek: Yeah, I don't remember anyone agreeing "months ago" that it should be moved.  We agreed to move the images, and the server team agreed to fix their broken scripts that assumed all arches live on the same mirror.  That's the last time I remember it coming up.
[19:21] <infinity> It's rather unfortunate that the hackish way one does multiarch in sources.list made this a much uglier and more noticeable issue than it ever was before, but I'm not sure "weird apt config files" should force anyone's hand here. :/
[19:26] <slangasek> infinity: it was "agreed" in the sense that there was nothing on the UE side that should block such a change
[19:26] <slangasek> elmo: ok, I didn't understand that it still had an impact on the costs for archive.u.c
[19:26] <infinity> Kay.  This must have come up again after the MaaS context?
[19:27] <infinity> Cause I sure do hope "we'll move it to archive.u.c soon" wasn't used as an excuse to not fix the MaaS mirror assumption bugs.
[19:27] <slangasek> infinity: I think it was in the maas context
[19:27] <slangasek> my understanding was that the maas bugs were being fixed regardless
[19:27] <infinity> (Which will just bite them ALL OVER AGAIN with arm64 or x32, or...)
[19:28] <infinity> And, in fact, the cross-building/multi-arch developer story gets to go from "being crap on armhf" to "being crap on arm64" soo too, so the latest darling misfeature people hope to fix won't be fixed by moving armhf. ;)
[19:28] <infinity> s/soo/soon/
[19:46] <seb128> doko, gtk: no, gnome: some bug fixing, nothing that should impact builds if that's the question
[19:46] <doko> ok, thanks
[19:47] <seb128> yw ;-)
[19:47] <doko> xnox, ScottK; iiuc you need at least a partial kde rebuild for the next test rebuild?
[20:33] <doko> infinity, do you plan to update eglibc to the branch before the freeze?
[20:34] <infinity> doko: Yeah, I'll do a pull and see if there's anything interesting.
[21:20] <Reezz> Hey guys, any ideas on why I would get a SIGSEGV in the cogl lib? http://pastebin.com/7nJBUG4v
[21:21] <seb128> Reezz, try asking on #gnome-hackers on irc.gnome.org rather
[21:22] <Reezz> k, i'll give that a go :)
[21:39] <Reezz> seb128: kind of a dead channel :/
[21:40] <seb128> Reezz, welcome to IRC
[21:40] <seb128> it's an async communication channel, people come and go
[21:41] <seb128> you are after european hours and might in u.s midday break time
[21:41] <Reezz> Well, really now? Thanks for the update
[21:41] <Reezz> Urgh, douchebags
[22:28] <ScottK> doko: Because?