[01:53] <BenC> infinity: upload processing
[02:02] <infinity> BenC: adare and ross on manual, then.
[02:03] <infinity> (and accepting)
[02:03] <infinity> BenC: Needs a matching -meta too...
[02:05] <infinity> BenC: Ahh, there it is.
[03:45] <ScottK> jbicha: Please don't mark bugs fix released when the fix is in a PPA.  Fix released for an Ubuntu bug is for when the package is in Ubuntu.
[03:45] <ScottK> (re 1163062)
[03:47] <jbicha> ScottK: ok, should I mark it invalid? it only affects packages in the ppa
[03:47] <ScottK> jbicha: Yes.
[03:47] <ScottK> I wouldn't bother changing this one.
[03:51] <ScottK> jbicha: For Kubuntu PPAs we created a /kubuntu-ppa project and direct people to file bugs against PPA packages there.
[03:51] <ScottK> It wasn't clear in the case of that bug it only affected the PPA.
[04:16] <vibhav> good morning
[06:33] <doko> infinity, could you leave a comment on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701422
[06:36] <dholbach> good morning
[06:40] <infinity> doko: I'm not sure I have an opinion there.  I'm certainly not going to deviate from upstream, but vorlon's welcome to file a bug at sourceware.org
[06:41] <doko> slangasek, ^^^
[06:50] <infinity> slangasek: Looking at commit 7e66ee5142deda977163d0a858c3d2883cae3f07 and comparing manpages, I'm inclined to agree that including setfsuid and setfsgid in the list of set*id WUR changes there was probably a mistake.
[06:51] <infinity> slangasek: If you ask nicely, maybe I'll throw a patch upstream to revert that part of the commit and see if I get any arguments.
[06:52] <bkerensa> <(o.o) >
[06:52] <slangasek> infinity: "ask nicely" is code for "buy you a beer", right?
[06:53] <infinity> slangasek: Could be.
[06:54] <infinity> Bah, I was going to look and see if reality matched the manpage, but it's a straight syscall, there's no way for glibc to know that anyway.
[07:09] <doko> $ file !$
[07:09] <doko> file /usr/include/linux/stddef.h
[07:09] <doko> /usr/include/linux/stddef.h: very short file (no magic)
[07:10] <doko> infinity, apw,: empty file. do you know why?
[07:10] <dholbach> @pilot in
[07:12] <infinity> doko: Maybe the one define it used to have isn't necessary anymore?
[07:13] <doko> infinity, there is *no* define
[07:14] <doko> well, at least I would expect a comment
[07:14] <infinity> Hrm.  The kernel source has "#include <linux/compiler.h>" in that file.
[07:15] <infinity> Weird.
[07:16] <dholbach> Riddell, do you know if somebody is looking into bug 1131636?
[07:17] <dholbach> I'm asking because there's a workaround in bug 1155327 (which is in the sponsoring queue) and I'm not 100% sure what the best solution for now might be
[07:19] <doko> jamespage, could you have a look at the tomcat7 build failure?
[07:20] <doko> hmm, could retry with the updated openjdk too
[07:20] <infinity> doko: So, I'd guess the reason it's empty is because the one in the kernel is a single line including linux/compiler.h, which also doesn't exist in the userspace headers.
[07:21] <infinity> doko: But Andy may have better ideas about WTF oddity is going on there.  The UAPI mangling stuff could still have some bugs.
[07:52] <dholbach> hey mvo!
[07:52] <dholbach> mvo, I have an apt question :-D
[07:52] <mvo> hey dholbach
[07:52] <mvo> dholbach: sure, fire!
[07:53] <dholbach> mvo, it seems apt/dpkg is stuck over here unpacking a kernel package for some time now - how do I debug it?
[07:53] <mvo> dholbach: what does ps afx show?
[07:53] <mvo> dholbach: hm, its unpacking you say? then its a dpkg bug ;)
[07:54] <dholbach> mvo, http://paste.ubuntu.com/5669752/
[07:54] <ogra_> dholbach, hmm, i saw plenty of reports about that on G+ the last days
[07:54] <rbasak> infinity: ping
[07:54] <mvo> dholbach: and no terminal prompt/gtk debconf prompt anywhere?
[07:55] <dholbach> mvo, no
[07:55] <ogra_> seems to have started around wed. or thu. last week
[07:55] <mvo> dholbach: can you do a strace -p 19619 ?
[07:56] <dholbach> mvo,
[07:56] <dholbach> Process 19619 attached - interrupt to quit
[07:56] <dholbach> read(3,
[07:56] <mvo> dholbach: yeah, I suspected this, so it looks like aptdaemon did not give you a terminal/gtk debconf prompt :/
[07:57] <dholbach> mvo, so it's an aptdaemon problem?
[07:57] <doko> mvo: https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4410918
[07:58] <doko> can you reproduce this? hangs in the testsuite on i386
[08:04] <doko> didrocks, don't see pitti or seb128 here. could you organize a bug fixing party for the gtk/gir/gnome ftbfs in main (and maybe in universe)?
[08:05] <doko> didrocks, don't see pitti or seb128 here. could you organize a bug fixing party for the gtk/gir/gnome ftbfs in main (and maybe in universe)?
[08:05] <doko> seb128, ^^^
[08:05] <didrocks> doko: see, better to invoke the right people :)
[08:05] <seb128> doko, hey, just back from 4 days w.e, will have to figure out what's the workload for the next week(s) first, but I can see try to squash a few
[08:05] <seb128> doko, do you have a list?
[08:06] <doko> seb128, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
[08:06] <seb128> thanks
[08:06] <doko> I think you know the package names better than I do
[08:07]  * ogra_ wonders what esound still does in main
[08:07] <dholbach> mvo, shall I kill the process and file a bug on aptdaemon about it?
[08:08] <mvo> dholbach: yes please
[08:09] <dholbach> thanks mvo
[08:09] <mvo> doko: probably the same bug that dholbach just experienced
[08:13] <dholbach> mvo, bug 1163163
[08:13] <dholbach> doko, ^
[08:16] <dholbach> Mirv, for https://code.launchpad.net/~timo-jyrinki/ubuntu/raring/ubuntu-touch-meta/fix_lp1163125/+merge/156464 would you mind adding a changelog entry?
[08:16] <dholbach> Mirv, apart from that I'm happy to sponsor it
[08:17] <Mirv> dholbach: there is one already?
[08:17] <Mirv> oh, changelog, not commit message
[08:17] <dholbach> hum
[08:17] <Mirv> ok, just a second
[08:17] <dholbach> perfect
[08:18] <Mirv> dholbach: pushed changelog change
[08:18] <dholbach> on it
[08:19] <Mirv> hmm, version bump probably still as native package?
[08:19] <Mirv> pushed that as well..
[08:20] <dholbach> thanks
[08:21] <dholbach> Mirv, uploaded
[08:22] <Mirv> thanks!
[08:26] <cjwatson> dholbach: https://code.launchpad.net/~timo-jyrinki/ubuntu/raring/ubuntu-touch-meta/fix_lp1163125/+merge/156464 - still time to abort that upload?
[08:28] <Mirv> ah, one more layer of autogeneration
[08:31] <dholbach> cjwatson, oops sorry - I'm happy to upload a newer version of it with a fix in the seeds file
[08:32] <cjwatson> dholbach: perhaps you could just sync up the seed branch I pointed to
[08:32] <cjwatson> that should be enough now, but we shouldn't make this kind of manual change in future
[08:33] <dholbach> yes, agreed - I haven't touched seed related bits in a very long time and I wasn't sure where this change needed to be made
[08:34] <dholbach> cjwatson, it's still in the unapproved queue of raring - so it could be rejected there if you like, but I can also just go and update the seeds
[08:34] <cjwatson> might as well just do the latter now
[08:34] <dholbach> ok
[08:34] <Mirv> proposed https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.raring.fixlp1163125/+merge/156487 as well
[08:34] <cjwatson> I just want to avoid the two data sources getting out of sync, so that when somebody later comes along and tries to do things the right way they don't get confused at it randomly reverting changes
[08:35] <cjwatson> yep, that's correct, I'll merge it, thanks
[08:35] <dholbach> thanks Mirv, cjwatson
[08:38] <ogra_> cjwatson, hmm, could we set up meta MPs in a way that ubuntu-release, ubuntu-core-dev or ubuntu-cdimage gets the notifications  ?
[08:39]  * ogra_ would have liked to be notified for that one ... seems the only automatic subscriber for it is ubuntu-branches ... which is rather pointless
[08:40] <xnox> ogra_: just subscribe relavant team(s) to the lp:ubuntu/meta-foo branches.
[08:40] <ogra_> xnox, i know i can do that ... but before i blindly subscribe a team i rather get some feedback ;)
[08:42]  * ogra_ subscribed himself now 
[08:42] <ogra_> though i dont think that gives me MP notifications ... and i dont want to be the only reviewer
[08:47] <cjwatson> ogra_: I'm not quite sure how it works TBH - those branches are magic in various ways
[08:49] <ogra_> heh
[09:05] <wgrant> ogra_: You'll get MP notifications if you configure your subscription to give you them.
[09:05] <wgrant> By default it doesn't, I don't think, but it asks you.
[09:07] <ogra_> wgrant, thx, i'll make sure thats set
[09:29] <doko> Laney, could you take of goocanvas for the next cycle? I see you are involved in the Debian issue
[09:36] <seb128> doko, he's off this week
[09:45] <doko> Riddell, ScottK: could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4442123 ? it looks like a wrongly set bin dir
[09:53] <Riddell> hmm, maybe some clashing with qt 5
[09:58] <ev> cjwatson: for what it's worth, bdmurray went ahead and implemented the mapping from bugs to crash signatures on https://errors.ubuntu.com: https://rt.admin.canonical.com/Ticket/Display.html?id=60462
[09:58] <ev> if memory serves, I believe you asked for this a while back
[09:59] <ev> trying to get it landed today
[09:59] <cjwatson> is that a bidirectional mapping?  I think I was looking for crash signatures to bugs
[09:59] <cjwatson> (the particular case I wanted it has been handled, but I'm sure I'll need that again at some point)
[10:00] <ev> err yes, the bidirectional stuff
[10:01] <ev> I think :)
[10:01]  * ev digs
[10:04] <ev> cjwatson: ah, we don't have that precisely, but its just because the API doesn't expose it. It's an easy fix that I'll make today.
[10:04] <cjwatson> OK, cool, thanks
[10:26] <doko> xnox woke up, db uploads starting ...
[10:27] <xnox> doko: you are funny. I notice a lot of gir ftbfs as well that can be fixed similar to https://launchpadlibrarian.net/135708494/ubiquity_2.14.0_2.14.1.diff.gz
[10:27] <xnox> doko: also what's up with all the underlinking? something changed in the linker/gcc?
[10:30] <doko> xnox, yep, did ping seb128 about the gtk/gir stuff
[10:30] <seb128> doko, xnox: seems like you guys are on desktop stuffs so I will wait before doing some so we don't conflict
[10:31] <doko> the underlinking was a bug, recently fixed in binutils
[10:31] <doko> seb128, no we stay away =)
[10:31] <seb128> doko, ok ;-)
[10:34] <rbasak> What does the "Set" column mean in the FTBFS reports????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
[10:34] <rbasak> Aargh. Sorry, stuck key.
[10:39] <rbasak> doko: can I help with some of these FTBFSes? What's already being worked on?
[10:40]  * rbasak is on +1 maintenance this month, but infinity is presumably asleep right now
[10:40] <doko> rbasak, see the recent uploads, I'll stop myself for today with this stuff. xnox did do the db packages
[10:41] <rbasak> doko: where to look? https://launchpad.net/ubuntu/raring/+queue?queue_state=3 or somewhere else?
[10:42] <doko> rbasak, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
[10:42] <rbasak> doko: I mean for recent uploads
[10:42] <doko> ahh
[10:43] <doko> https://lists.ubuntu.com/archives/raring-changes/2013-April/thread.html
[10:43] <rbasak> OK - thanks!
[10:43]  * rbasak looks at sqlite3
[10:45] <wgrant> rbasak: The Set column indicates whether the source is in any packageset.
[10:45] <rbasak> wgrant: ones that are directly listed, or anything seeded?
[10:46] <rbasak> Oh
[10:46] <rbasak> Upload set.
[10:46] <rbasak> Gotcha
[10:47] <doko> rbasak, sqlite3 is done =)
[10:47] <wgrant> Packagesets tend to be based on the transitive closures of the seeds, right.
[10:48] <rbasak> doko: so it is. I'll look more carefully, thanks.
[11:04] <GunnarHj> cjwatson: Hi Colin, can you please take a look at bug 1163142? seb128 think you may be the right person to spot the problem.
[11:05] <seb128> cjwatson, I ran into a similar issue the other day, it seemed like dpkg/debconf being stucked on a read (from strace)
[11:05] <cjwatson> GunnarHj: is it reproducible locally?
[11:06] <cjwatson> seb128: in the same language-selector stack?
[11:06] <GunnarHj> cjwatson: I could easily reproduce it.
[11:06] <seb128> cjwatson, no, normal upgrade using update-manager for me
[11:06] <seb128> cjwatson, we have/had issues with the new unity-dash "spamming" gvfsd-http and hiting ulimit on open fds
[11:06] <cjwatson> seb128: yeah, if it was a different stack that's sort of like "I ran into a compiler error yesterday too" :-)
[11:06] <seb128> so I wonder if that could break debconf
[11:07] <cjwatson> much more likely that something is mishandling fds
[11:07] <cjwatson> in the layers above debconf
[11:07] <cjwatson> it's easy enough to do if e.g. you forget to mark the right things close-on-exec
[11:07] <cjwatson> GunnarHj: can you give me step-by-step instructions?
[11:08] <GunnarHj> cjwatson: Just try to install any language using language-selector. That's it.
[11:11] <seb128> cjwatson, right, I just wanted to point the dash eating all the available fds issue as a data point in case it's useful, but seems like that one could be a different bug
[11:12] <dholbach> @pilot out
[11:31] <cjwatson> GunnarHj: Got it.  I'll see what I can do
[11:31] <GunnarHj> cjwatson: Great, thanks!
[11:39] <didrocks> cjwatson: is it normal that natty is still on http://archive.ubuntu.com/ubuntu/dists/?
[11:41] <cjwatson> I think so, yes.  There's generally a delay on removing that due to various stragglers
[11:41] <didrocks> ah ok, thanks :)
[12:03] <melodie> hello
[12:05] <melodie> I am seeking help with casper and post install scripts for a little project, and I am not sure what the problem is to get to the goal. I would like the post-install script to put 2 launchers on the desktop : after install, whatever language it will be.
[12:06] <melodie> I have got it in the Live remix, thanks to a script in the casper-bottom directory, and from there I don't know how to achieve the rest ?
[12:07] <melodie> I have looked also the chan list to see if there is another chan where I could ask, and I didn't see any other more relevant
[12:10] <cjwatson> seb128: good news, this has nothing to do with unity; bad news, argh twisty pile of code
[12:11] <cjwatson> melodie: have a look at the ubiquity-hooks/ directory in the casper source
[12:11] <seb128> cjwatson, thanks for investigating it!
[12:11] <cjwatson> It doesn't have a *specific* example for desktop launchers, but scripts there are run by ubiquity post-install in much the same way that casper-bottom hooks are
[12:12] <melodie> hi cjwatson, among else there is one question I wondered: would the following bug be causing the desktop launchers from the live not be copied to the desktop ? https://bugs.launchpad.net/ubuntu/+source/xdg-user-dirs-gtk/+bug/1163043
[12:12] <melodie> i show you the script too:
[12:13] <melodie> http://paste.ubuntu.com/5670225/
[12:13] <cjwatson> sorry I don't know and can't look right now
[12:14] <melodie> no problem
[12:14] <cjwatson> the whole business of translated directory names is an incredibly stupid design guaranteed to lead to problems, of course
[12:14] <melodie> is there another chan somewhere else for that sort of question ? anyhow I can stay connected
[12:14] <melodie> oh so...
[12:14] <cjwatson> iron rule should be to translate for display but not in the underlying identifier
[12:15] <cjwatson> sadly some people failed to understand this ...
[12:16] <seb128> cjwatson, when you do that you run into issues where your filebrowser/fileselector doesn't match your translated UIs (or if you use an app using a toolkit which doesn't do the translation for you)
[12:17] <seb128> but yeah, each solutions have their issues
[12:17] <melodie> hi seb128
[12:17] <seb128> it's not a problem easy to solve as long as you give users direct access to the fs and don't have one toolkit
[12:17] <seb128> would be easier if we had one API and a file picker ;-)
[12:17] <seb128> melodie, hey
[12:18] <melodie> I saw you have triaged this bug I filled. thank you. :)
[12:18] <seb128> yw
[12:18] <cjwatson> seb128: the problem with the xdg solution is that it moves all the bugs away from xdg and into everyone else's scripts
[12:18] <cjwatson> classic example of externalising costs
[12:19] <cjwatson> which of course looks OK if you aren't on the receiving end :)
[12:20] <seb128> well, Desktop is sort of a special case and trickier
[12:20] <cjwatson> ah, here we go, the aptdaemon bug isn't quite as hard as I thought
[12:20] <cjwatson> missing flush
[12:20] <seb128> but for things like Music it does make sense to be able to define the directory to be whatever you want and to have the name translated
[12:21] <GunnarHj> melodie: Hi Mélodie!
[12:21] <seb128> cjwatson, \o/ on finding the aptdaemon bug ;-)
[12:21] <melodie> seb128 do you have an idea if it is possible to get these 2 poor launchers from the Live to the installed version ? this is the script which is used, maybe could be improved or completed or ? http://paste.ubuntu.com/5670225/
[12:21] <melodie> hi GunnarHj :)
[12:23] <seb128> melodie, can't you just add those files to /etc/skel ?
[12:23] <seb128> hum, I guess that's where the translated "Desktop" directory makes things harder...
[12:24] <melodie> seb128 perhaps not as long as casper creates the directories where it is supposed to go ?
[12:24] <melodie> yes, it is what makes it harder...
[12:24] <seb128> you don't use nautilus right?
[12:24] <seb128> nautilus a gsettings key for those special icons
[12:24] <melodie> I use pcmanfm, and could use as well thunar  or spacefm
[12:24] <seb128> which would make your job easier than having to .desktop files
[12:24] <seb128> to copy*
[12:25] <GunnarHj> melodie: I'm not sure about your suggestion with bold text in the Language Support UI. I do agree it would be motivated - you were not the first to have problem with the drag-and-drop thing - but I don't think we use bold text in other UIs, so it would be a style break.
[12:25] <melodie> GunnarHj then some color maybe ?
[12:26] <GunnarHj> :)
[12:26] <GunnarHj> melodie: Even worse, I'd say.
[12:27] <melodie> I have to check the bug report page to find another idea then
[12:27] <seb128> melodie, sorry, I'm not sure what's the best way to do that, out of shipping a small script that create those on first login
[12:27] <melodie> that would suit the need I'd say
[12:28] <melodie> I don't know how to do that, so if you would I will be very happy to get help at some point
[12:29] <GunnarHj> melodie: In the release after 13.04 we will switch to another UI completely. I'd suggest that we are patient in the meantime.
[12:29] <seb128> melodie, basically add a .desktop in /etc/xdg/autostart that call your script/command and make that script/command write a key/file somewhere to say its job is done and exit when the file exist
[12:29] <seb128> melodie, so it runs once and then do nothing from then on
[12:30] <melodie> nice! and that could also reproduce the process for each new user created: right ?
[12:30] <seb128> yes, those autostarts are run by the user and you should write the key/file in the user dir
[12:31] <melodie> thanks. I'll ask someone to do it that way and will test it right after
[12:33] <melodie> GunnarHj I agree when it comes to patience, there is no other way. Just if I can fetch an idea you could use, I'll give it a try. :)
[12:33] <doko> apw, ogasawara: I was looking at the tcpcopy ftbfs, looks like ip_queue.h isn't included in linux-libc-dev. it is in Debian. why not in Ubuntu?
[12:35] <GunnarHj> melodie: Thanks. :) (Still thinking about your idea - can't help it's tempting to make an exception.)
[12:36] <melodie> I am installing a new language in my version now, to remember how it looks like exactly
[12:37] <GunnarHj> melodie: Hmm... right now is probably a bad time to install a language. You'll probably see what I mean. :(
[12:37] <melodie> I got a dbus error but I neglected it
[12:37] <melodie> and that worked
[12:38] <melodie> I am adding an additional package so that it stops reminding me it is missing...
[12:38] <melodie> there is no option to dismiss it definitely, so...
[12:38] <GunnarHj> melodie: Did you succeed in installing a language on an updated Raring?
[12:38] <melodie> my work box is based on Precise
[12:39] <melodie> ^^
[12:39] <GunnarHj> melodie: Aha, that explains it. ;-)
[12:39] <melodie> when this little project will be fully finished then it will be time to move forward. :)
[12:39] <GunnarHj> Ok.
[12:40] <melodie> the program asked me to install gimp-help-fr for some time now : just thinking if an option to dismiss definitely could be nice to have
[12:40] <melodie> ok
[12:40] <melodie> GunnarHj I might have an idea you could use:
[12:40] <GunnarHj> melodie: Why do you think that would be important?
[12:42] <melodie> GunnarHj let's say it is a wish : the wish to be always free to do things how we want them. If I want to install language packs, but not all of them, because let's say, I don't need gimp help, well, why does this program insist forever ? :)
[12:42] <melodie> about drag and drop, here is the idea:
[12:42] <melodie> just adding 'HowTo:' on a line before the rest
[12:43] <melodie> in french 'Mode d'Emploi:'
[12:43] <melodie> and so on...
[12:43] <GunnarHj> melodie: Well, the simple answer would be that in Ubuntu languages are available on an all-or-nothing basis.
[12:44] <melodie> some of the packages do take quite some space, and it can be nice to be able to choose (it might make it more complicated to deal upstream, on your side, but for people with old boxes, low disk space, or just users who prefer to go minimal, it's nice)
[12:45] <GunnarHj> melodie: About the "HowTo" idea: There is a "Help" button at the bottom of the window.
[12:45] <melodie> GunnarHj this is right however it takes to install yelp... whereas the suggest I submit takes a few caracters to add
[12:46] <melodie> let me see how much adding yelp there brings in with depends...
[12:46] <melodie> it will bring in 27.2 Mo.
[12:47] <melodie> I check in the build directory of the project too...
[12:47] <GunnarHj> melodie: Actually the language support used to be more like you would like it. It was simplified a while ago, and changing it back would be non-trivial.
[12:47] <melodie> I get that
[12:48] <GunnarHj> melodie: Why are you so worried about disk space? Is that really an issue for you?
[12:49] <cjwatson> Language availability in Ubuntu is much less all-or-nothing than it used to be; I would argue that the point of check-language-support and friends was precisely to make it not all-or-nothing.
[12:50] <GunnarHj> cjwatson: Yeah, in the sense that you only install the languages you need, you are right, of course.
[12:51] <cjwatson> That wasn't what I meant.  It's much more fine-grained in terms of per-application packages than it used to be.
[12:52] <cjwatson> In that the only supported interface used to be that of installing language-support-LL, which installed all the support packages available for a given language; now you get to select support packages according to which applications you have installed, and it's clearly within the power of the management tools to be more picky than that if they want to.
[12:52] <cjwatson> Just a matter of how to handle the preferences.
[12:52] <GunnarHj> cjwatson: But a few cycles ago you could check which parts of the language support you wanted to install. That possibility is no longer there.
[12:53] <cjwatson> Right.  But that's a change in language-selector which you seemed to be trying to present as intrinsic to Ubuntu's language support availability.
[12:53] <cjwatson> It's not - it's purely a question of the UI.
[12:54] <GunnarHj> Hmm.. Have to think about that. ;-)
[12:54] <cjwatson> At least, there's nothing in the support package layout to prevent that.
[12:55] <GunnarHj> cjwatson: No, I agree it was a UI change. Still affecting the users' options in practice.
[12:58] <melodie> GunnarHj I didn't answer your question yet : it is interesting to spare disk space whenever possible. It is also often a difficult choice to do when building a project : keep this for the sake of the comfort of the user ? Or let the final user get it by himself ? what if he doesn't even fancy it can exist ? this is why I pay systematic attention to those details.
[13:01] <GunnarHj> melodie: A new UI will need to be written for language support handling when we switch to a new UI for the rest of language/locales settings. Maybe something to consider then.
[13:05] <melodie> GunnarHj this is very nice
[13:05] <melodie> if you can keep the idea aside...
[13:05] <melodie> :)
[13:13] <GunnarHj> melodie: Will try. :)
[13:14] <melodie> GunnarHj thanks. :)
[13:19] <xnox> wgrant: is it possible to "manually" superseed packages in test-rebuild results? e.g. with my pending tcltk-defaults uploads pidgin & ace are fixed from FTBFS.
[13:22] <cjwatson> xnox: It's simpler to retry those packages in the rebuild test
[13:22] <xnox> cjwatson: ah, awesome.
[13:25] <wgrant> xnox: Yeah, what cjwatson said.
[13:27] <mvo> cjwatson: thanks for your aptdaemon fix, shall I upload or are you on it already?
[13:27] <cjwatson> mvo: already uploaded
[13:28] <mvo> ta
[13:28] <cjwatson> Since I was pretty certain of it
[13:29] <davmor2> mvo: how do
[13:30] <mvo> cjwatson: yeah, totally
[13:31] <mvo> davmor2: good, thanks! and you?
[13:31] <davmor2> mvo: good, busy but that is good too :)
[13:44] <doko> xnox, did you give up with the Tcl/Tk multiarch thing?
[13:46] <xnox> doko: I didn't give up, just put in place compat shell script that can be sourced -> calls dpkg-architectures and chain sources the correct one.
[13:46] <xnox> doko: I'm not planning on spending my time fixing universe, when I can do it once and fix it for $most packages.
[13:47] <seb128> xnox, is that for tclConfig.sh changing path?
[13:47] <xnox> seb128: yes.
[13:47] <seb128> xnox, how is your fix working? does it mean I don't need to fix pidgin? ;-)
[13:48] <xnox> seb128: no need to fix pidgin. Pidgin will works out-of-the-box with fix in-place. (tested locally as one of the guinea pig packages)
[13:48] <doko> seb128, glib2.0 did fail again in raring on armhf
[13:48] <seb128> doko, it's weird, the same version built fine in debian and raring last week
[13:48] <doko> TEST: gdbus-close-pending... (pid=27574)
[13:48] <doko>   /gdbus/close-pending:
[13:48] <doko> (/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests/.libs/lt-gdbus-close-pending:27574): GLib-CRITICAL **: g_main_context_wakeup: assertion `g_atomic_int_get (&context->ref_count) > 0' failed
[13:48] <doko> FAIL
[13:48] <doko> GTester: last random seed: R02S9237789288b283d4b059cc2abb315517
[13:49] <doko> /bin/bash: line 1: 19034 Terminated              G_DEBUG=gc-friendly MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) dbus-launch ../../glib/gtester --verbose io-stream memory-input-stream memory-output-stream readwrite g-file g-file-info converter-stream data-input-stream data-output-stream g-icon buffered-input-stream buffered-output-stream sleepy-stream filter-streams volumemonitor simple-async-result srvtarget contex
[13:49] <doko> ts gsettings gschema-compile async-close-output-stream gdbus-addresses network-address gdbus-message socket pollable tls-certificate tls-interaction cancellable vfs network-monitor fileattributematcher resources proxy-test simple-proxy inet-address permission task credentials actions gdbus-connection gdbus-connection-loss gdbus-connection-slow gdbus-names gdbus-proxy gdbus-proxy-threads gdbus-proxy-well-known-name gdbus-introspec
[13:49] <doko> tion gdbus-threading gdbus-export gdbus-error gdbus-bz627724 gmenumodel gdbus-close-pending gdbus-connection-flush gdbus-peer gdbus-exit-on-close gdbus-non-socket gdbus-peer-object-manager appinfo contenttype mimeapps file live-g-file desktop-app-info unix-fd unix-streams gapplication basic-application gdbus-test-codegen gdbus-auth
[13:49] <doko> make[7]: *** [test-nonrecursive] Error 143
[13:49] <doko> make[7]: Target `check-local' not remade because of errors.
[13:49] <doko> make[7]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
[13:49] <doko> make[6]: *** [check-am] Error 2
[13:49] <doko> make[6]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
[13:49] <doko> make[5]: *** [check-recursive] Error 1
[13:49] <doko> make[5]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
[13:49] <doko> make[4]: *** [check] Error 2
[13:49] <doko> make[4]: Le
[13:49]  * seb128 hands a pastebin to doko
[13:50]  * doko hands seb128 https://launchpadlibrarian.net/135923939/buildlog_ubuntu-raring-armhf.glib2.0_2.36.0-1ubuntu1_FAILEDTOBUILD.txt.gz
[13:50] <seb128> doko, thanks
[14:02] <seb128> doko, what builds are used there? is that a normal/real builders or is that a qemu/virtual one?
[14:02] <tkamppeter> Anyone can help me with a problem caused by moving a conffile from one binary package to another? Bug 1162164
[14:02] <doko> seb128, normal, as for every test rebuild
[14:02] <desrt> how many CPUs are being emulated?
[14:03] <desrt> in the builder....
[14:05] <desrt> ie: is it emulating SMP or no?
[14:06] <seb128> desrt, doko is saying that's a normal builder and not a virtual one
[14:06] <seb128> doko, it's weird that we never hit that issue on the normal archive uploads
[14:07] <desrt> is it possible that the normal archive builders were single-core and this builder is multi-core?
[14:07] <desrt> the testcase is testing concurrency issues and the critical is on an atomic update of a refcount.... if that doesn't scream 'threading bug' i don't know what does
[14:08] <doko> afaik, all of these are configured for parallel=2 (or 3), just print DEB_BUILD_OPTIONS
[14:08] <desrt> doko: the build options are not interesting.  it's the hardware that is.
[14:08] <desrt> the testcases are run serially....
[14:08] <doko> desrt, well, then disable parallel tests
[14:08] <desrt> but they have threads
[14:09] <desrt> which is kinda the point... we want to test that our threading is working properly
[14:09] <xnox> tkamppeter: the best you can do is "Replaces: cups (<< 1.6.2-1ubuntu3)" in the "cups-daemon" package. There is no sane way to "unown" and "reclaim ownership" on a conffile and thus move it to a new binary package.
[14:10] <xnox> tkamppeter: where the version is the first one of package cups that does _not_ have /etc/init/cups.conf
[14:11] <desrt> does anyone know how many cores this builder has?
[14:11] <doko> desrt, these are all pandas, so two
[14:12] <desrt> and the other builders on which the build worked?  also two?
 desrt, these are all pandas, so two
[14:12] <xnox> desrt: we have procenv package that a build time does a lot system detection and prints a lot of interesting info. See https://launchpadlibrarian.net/126054733/buildlog_ubuntu-raring-armhf.procenv_0.19-1_BUILDING.txt.gz
[14:13] <desrt> seb128: we should have this in all our builds :)
[14:13] <cjwatson> xnox: are you certain that aleya and mothallah are identical hardware?  (I'm not)
[14:13] <seb128> desrt, did you find the bug?
[14:14] <desrt> seb128: no.  i don't even have an idea for the basis of the bug.
[14:14] <xnox> cjwatson: let me check what other builds of procenv we have in the history...
[14:14] <cjwatson> I checked, don't see one on mothallah.  it's probably quicker to ask webops.
[14:15] <seb128> doko, is there any way to throw a debug version of the package to the builder if we get one?
[14:15] <doko> seb128, upload to a non-virtualized ppa and make it build on armhf only?
[14:17] <ogra_> seb128, want access to the canonical-arm-dev PPA ?
[14:18] <seb128> ogra_, that could be handy but I don't have a strong need for it either, your call
[14:18] <ogra_> well, for doing testbuilds it might help
[14:19] <ogra_> it is real hardware ...
[14:19] <seb128> ogra_, can you get me added?
[14:20] <ogra_> seb128, done
[14:21] <seb128> ogra_, thanks
[14:36] <bdmurray> jodh: is there a ppa with a fix for bug 1163103?
[14:39] <jodh> bdmurray: not atm. It wasn't clear from the bug, but if that message is the only issue, ignore it - it's harmless.
[14:39] <bdmurray> jodh: oh, so it should still work then?
[14:40] <jodh> bdmurray: I certainly hope so :)
[14:40] <jodh> bdmurray: the problem is that the nih calls we're making assume the daemon is running as root. and it isn't :)
[14:45] <xnox> jodh: should be using XDG_RUNTIME_DIR for pid files as a user =)
[14:46] <bdmurray> jodh: and where is it logging?
[14:46] <jodh> xnox: the bridge now does, but NIH isn't xdg-aware yet alas :)
[14:49] <tkamppeter> xnox, thank you very much, strange is the message "trying to overwrite '/etc/init/cups.conf', which is also in package cups 1.6.2-1ubuntu3" as I have checked on my box and cups 1.6.2-1ubuntu3 does not contain /etc/init/cups.conf.
[14:50] <jodh> bdmurray: as of now, syslog (erroneously). The issue is fixed in upstream such that it'll log to stdout and thus end up in ~/.cache/upstart/upstart-file-bridge.log.
[14:50] <xnox> tkamppeter: correct, it doesn't exist on fresh installs. One must upgrade from the time when it did. =) I recently had to deal with a broken conffile dating back to hardy times =))))
[14:52] <tkamppeter> xnox, I have also checked http://packages.ubuntu.com/search?suite=raring&arch=any&searchon=contents&keywords=%2Fetc%2Finit%2Fcups.conf and only cups-daemon provides /etc/init/cups.conf, independent of the architecture.
[14:53] <doko> zul: are these server uploads (rc2) needed for the beta?
[14:53] <zul> doko:  when is the beta out again?
[14:53] <xnox> tkamppeter: sure, but in quantal it was in the cups package. So anyone upgrading from quantal or before, and had that conffile for example modified, it will be there causing upgrade conflict.
[14:54] <doko> zul: Thursday?
[14:54] <tkamppeter> xnox, and cups-daemon contains "Replaces: cups (<< 1.6.1-1~)".
[14:54] <xnox> tkamppeter: yeah, noticed.
[14:54] <zul> doko:  yeah i think they would be nice to have
[14:54] <doko> zul: could you note in the MIR issue, why cinder/nova need python-babel?
[14:56] <zul> doko:  i reopened the MIR that was previously opened but babel causes this bug when its not installed https://bugs.launchpad.net/ubuntu/+source/cinder/+bug/1126378
[14:57] <xnox> tkamppeter: hmmm... it looks like it could be a bug in apt-clone restore (used to upgrade using the desktop cd, as shown in the bug report)
[14:57] <doko> zul: could you add this info in 941913?
[14:57] <zul> doko:  ack
[14:58] <zul> doko:  done
[15:00] <tkamppeter> xnox, should I reassign this bug to apt-clone
[15:03] <xnox> tkamppeter: not sure, needs testing.
[15:03] <xnox> (reproducer)
[15:03] <xnox> tkamppeter: potentially cups may have to move the conffile out of the way....
[15:07] <tkamppeter> xnox, the conffile is /etc/init/cups.conf before and after, how should CUPS move it? Let pre-inst of cups-daemon rename it and post-inst of cups-daemon move it back overwriting the new cups.conf of cups-daemon?
[15:09] <xnox> tkamppeter: you should use rm_conffile on /etc/init/cups.conf in the cups package just like there are for the rest of conffiles.
[15:09] <xnox> tkamppeter: that way it will be removed and it will be "resurrected" afresh with no baggage by cups-daemon.
[15:09] <xnox> tkamppeter: also see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672945
[15:10] <slangasek> "support moving a conffile between packages" - that's called "Replaces:"?
[15:14] <xnox> slangasek: not really, as the conffile stays allocated to the previous package and even with replaces dpkg does not unpack the new one. See tkamppeter's raised issue in bug  https://launchpad.net/bugs/1162164
[15:15] <doko> slangasek, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4438112 ? you seem to know the maintainer
[15:16] <xnox> slangasek: or is the problem here, that we have a too strictly versioned Replaces?
[15:18] <BenC> cjwatson: Is there a way to make the ISO installer initrd check for install media on non-removable disks as well (e.g. hd partition)?
[15:18] <doko> afaik, we can't migrate config files between packages
[15:18] <BenC> I ask because virtio-blk doesn't show up as removable even when media=cdrom on qemu
[15:18] <ogra_> unless "Replaces" suddenly started secretly using dpkg-maintscript-helper
[15:21] <blitzkrieg3> would someone please sponsor bug 861171?
[15:49] <tkamppeter> xnox, but if I use rm_conffile in cups, does this happen before cups-daemon installes cups.conf? Or can it happen I end up without cups.conf at all?
[15:52] <stgraber> cjwatson: DMB meeting minutes in the ubuntu-devel-announce moderation queue for when you have a minute
[15:53] <cjwatson> stgraber: done
[15:53] <xnox> tkamppeter: cups' preinst will move cups.conf out of the way, cups-daemon postinst will put cups.conf in place. If dpkg still barks at you (it shouldn't as far as I remember), then cups-daemon will need a Pre-Depends: cups (at least the first version that did not have cups.conf)
[15:53] <stgraber> cjwatson: thanks
[15:54] <xnox> tkamppeter: there will be a window of no cups.conf on disk and depending on the options to dh_installinit it may be stopped as well while the upgrades are in progress.
[15:57] <slangasek> xnox: the conffile is still attached to the previous package, but is *also* attached to the new package and a subsequent upgrade of the old package fixes up the dpkg database; and regardless of which package it's associated with in the database, TTBOMK the user-visible *behavior* is what we want/expect
[15:57] <slangasek> doko: "know the maintainer" - you mean I touched it last? :)
[15:58] <slangasek> tkamppeter, xnox: I strongly disagree that rm_conffile is warranted here - reparenting of conffiles via Replaces: has been working for years
[15:58] <slangasek> and if it's not working now, we should figure out why and address it
[15:59] <doko> nm, seb did fix it
[15:59] <xnox> tkamppeter: in that case the version number should be higher in the "Replaces" field. It should be same or lower than current cups source package. All the way until next lts.
[15:59] <slangasek> doko: that "nm" is to me?
[16:00] <slangasek> xnox: it should only need to declare Replaces: on the last version of cups that shipped the conffile
[16:00] <xnox> slangasek: in the linked error log, the unpack of packageB claims that conffile is still present in packageA off the versionNew.
[16:00] <xnox> s/off/of/
[16:01] <slangasek> xnox: I haven't seen this link
[16:01] <slangasek> link me? :)
 slangasek: not really, as the conffile stays allocated to the previous package and even with replaces dpkg does not unpack the new one. See tkamppeter's raised issue in bug  https://launchpad.net/bugs/1162164
[16:02] <xnox> slangasek: I did at 16:14 Oxfordshire time ^^^^
[16:02] <xnox> =)
[16:03] <slangasek> xnox: ah, k :)
[16:14] <infinity> rbasak: What was that contentless ping about?
[16:14] <rbasak> infinity: sorry. +1 maintenance. It's April.
[16:14] <infinity> It sure is.
[16:14] <infinity> In a meeting right now, sec.
[16:14] <tkamppeter> xnox, so you mean that any version of cups-daemon N should have Replaces: cups (<< N)?
[16:14] <rbasak> np
[16:15] <xnox> tkamppeter: (<= N)
[16:15] <tkamppeter> xnox, so cupsa-daemon should also replace cups of the same source package version?
[16:16] <tkamppeter> xnox, cups needs cups-daemon.
[16:16] <xnox> tkamppeter: yeah or less.
[16:16] <xnox> *sigh*
[16:17] <xnox> tkamppeter: either get a real solution from slangasek =) or use rm_conffile as my original idea is. Since afaik there is no sane way to "move" a conffile from one package to the other.
[16:18] <tkamppeter> xnox, so should I assign the bug to slanagasek (and perhaps also add a dpkg task)?
[16:19] <tkamppeter> s/slanagasek/slangasek/
[16:19] <xnox> =)))) we should get a simple reproducer of it in a chroot first.
[16:19] <xnox> cause that's the first thing that will slangasek ask for before punting it into "incomplete" state =)
[16:21] <doko> chasing this bus error building libx11 docs on i386 ... can't reproduce it in a script :-/
[16:23] <slangasek> xnox, tkamppeter: right, because I just tested in a quantal chroot with dpkg --auto-deconfigure -i /path/to/cups-daemon.deb, and I don't see this error at all
[16:23] <slangasek> xnox, tkamppeter: if anything, this looks like a possible corrupted dpkg db on the affected system - I strongly counsel against elaborate maintainer script hacks if we only have one report and it's not reproducible
[16:24] <xnox> right, I shall quickly install quantal and then use raring cd to upgrade, as this is how the bug report is filed.
[16:25]  * xnox loves that utah command can just do this for me in the background (download & do a default quantal install)
[16:25] <tkamppeter> xnox, slangasek, I am still waiting for answers of the reporter what he exactly did. I did a fresh installation of Raring for i386 on a 7 year old laptop this weekend and it worked perfectly.
[16:25] <slangasek> indeed
[16:26] <melodie> is it xdg-users-dirs-gtk which creates the default directories in the accounts of new created users at first login ?
[16:33] <dobey> melodie: probably. i think that's what asks if the user wants them moved, when a different locale is selected and the user logs in
[16:34] <melodie> dobey what about this issue ? https://bugs.launchpad.net/ubuntu/+source/xdg-user-dirs-gtk/+bug/1163043
[16:34] <melodie> hi dobey btw... :)
[16:35] <melodie> I'll be back in one hour or so, need to go out now.
[16:35] <melodie> I'll be back and stay connected
[16:35] <dobey> hi. i don't know about that bug. i guess it's a bug though. seems it does that for multiple directories, not just 'Desktop'
[16:37] <melodie> dobey no, only Desktop (at least when switching from English to French)
[16:37] <melodie> dobey you could look at the screenshots I pointed to and you will see that
[16:44] <dobey> oh, i didn't realize "documents" was the french version as well. anyway, seb already marked the bug as low priority 7 hours ago, not sure why you need to ask about it in here
[16:46] <infinity> rbasak: So, if you're looking for things to tackle, the FTBFS list (prioritizing on current failures in the archive, and when those are done and/or too hard, moving on to doko's rebuild test) would be a great place to go.
[16:46] <dobey> if he thought it was filed in the wrong place, he would have moved it
[16:46] <infinity> rbasak: And feel free to just toss up debdiff on some web space or other and aim me at the lot for review/sponsorship/etc.
[16:46] <doko> infinity, the current ftbfs list is empty ;-P
[16:47] <infinity> doko: You have a weird definition of empty.
[16:47] <ogra_> doko, what did you do ? break the backend ?
[16:47] <melodie> dobey just because I wonder if this is related with the other question I asked just before:
 is it xdg-users-dirs-gtk which creates the default directories in the accounts of new created users at first login ?
[16:47] <doko> infinity, well, main
[16:47] <infinity> doko: +1 maint isn't just main.
[16:47] <rbasak> infinity: I tried going through doko's rebuild test this morning, but couldn't see any easy way of not duplicating work of people who are way ahead (doko, xnox).
[16:47] <infinity> Though, very few of those universe failures are likely to be fixable before release.
[16:48] <melodie> dobey someone will help me with a script and asked what script creates the new directories for each new user : this is why I am asking here where the knowledge is :)
[16:48] <xnox> infinity: rbasak: I did upload a compat tcltk which should resolve a fair amount of FTBFS.
[16:48] <infinity> rbasak: Helping Laney unsnag his ghc transition pain before release might be nice too.
[16:49] <rbasak> I'm happy to take some packages to fix if I know I won't get trumped
[16:49] <rbasak> (and I'll be on IRC)
[16:49] <xnox> rbasak: you could be untangling ghc transition, there is an active BigIndian bug blocking a fair chunk of stuff. cjwatson has started poking it, but maybe you'd also be able to fix it.
[16:49] <rbasak> What's the bug?
[16:49] <infinity> rbasak: Which could be in the form of fixing a bug or three, or identifying leaf nodes or small branches we can prune from broken arches to smooth things.
[16:50] <xnox> although it looks like cjwatson was doing test-build with the fix already for that =/
[16:50] <rbasak> xnox: see what I mean? :)
[16:50] <cjwatson> Yeah, I'm working on haskell-cipher-aes/powerpc
[16:50] <infinity> cjwatson: Oh, did you need leviathan back for that? :P
[16:50] <rbasak> Right now my biggest personal blocker is that I feel that I'll waste effort
[16:50] <cjwatson> infinity: Maybe, if I fail to zen it with PPAs
[16:51] <infinity> cjwatson: I'll just turn it on, and you can let me know if you didn't need it.
[16:51] <xnox> rbasak: this is a good list to work off: http://qa.ubuntuwire.com/ftbfs/
[16:51] <infinity> I need to test BenC's latest kernel anyway.
[16:51] <xnox> but it's mostly universe atm.
[16:51] <ogra_> rbasak, there is a whole universe full of armhf FTBFS and you have the fast hw ;)
[16:54] <cjwatson> rbasak: I started late last month, so I'm letting myself run late too.  I'll probably be out of your way in a few days.
[16:54] <cjwatson> rbasak: But, well, just ask
[16:55] <cjwatson> rbasak: haskell-* probably has a horrible learning curve.  You might be better off looking at other things in general ...
[16:55] <cjwatson> Unless it's something you already happen to be familiar with
[16:55] <doko> rbasak, maybe leave a message in +1-maint what you're working on
[16:57] <cjwatson> infinity: Yeah, I think I will need to work through this on leviathan; I'm not quite enough of a savant to be able to guess it, apparently :P
[16:58] <cjwatson> Though I'm pretty sure I'm in the right area.
[16:58] <Whoopie> debfx: Thanks for the virtualbox update. Works great now under raring and precise.
[16:59] <infinity> cjwatson: Alright, let me upgrade and reboot into the new kernel before you get busy with chroots you don't want me eating.
[16:59] <infinity> cjwatson: Or am I too late? :)
[17:01] <cjwatson> infinity: No, go ahead
[17:04] <ahasenack> guys, just wondering, I'm having crashes every 5min or so in X, and I'm reporting them. I'm on Quantal. Is something widespread going on, or is it just me?
[17:04] <ahasenack> no nvidia, just plain intel
[17:04] <xnox> tkamppeter: slangasek: did ubiquity based upgrade off quantal and despite scary messages it did complete fine without cups errors.
[17:05] <slangasek> xnox: does the log show cups-daemon being unpacked before cups?
[17:05] <slangasek> (if not, it's not a complete rule-out)
[17:06] <xnox> slangasek: cups-daemon is unpacked before cups.
[17:06] <slangasek> ok
[17:07] <slangasek> so, whatever was happening in that bug report, it doesn't give much evidence that dpkg is broken :)
[17:09] <infinity> cjwatson: Okay, all upgraded.
[17:10] <mitya57> ahasenack: do you have a bug number?
[17:10] <cjwatson> awesomesocks
[17:10] <ahasenack> mitya57: apport didn't give me one
[17:11] <ahasenack> mitya57: I don't know where it's uploading this stuff to, but I have probably dozens already
[17:11] <ahasenack> 5 just today
[17:22] <xvzf> hi there, what is an "upstream d-i repository"?
[17:23] <cjwatson> xvzf: d-i is the debian-installer project.  What's the context for your question?
[17:25] <xvzf> cjwatson: Hi Colin, I'm Gergely, and we exchanged e-mail about the kickseed project. Your answer contained this expression and I didn't have the clue what it is. It is now clear.
[17:25] <mitya57> ahasenack: ah, it goes to errors.ubuntu.com then
[17:26]  * mitya57 doesn't have access there, so somebody else should look
[17:28] <cjwatson> xvzf: OK.  http://anonscm.debian.org/gitweb/?p=d-i/kickseed.git specifically
[17:29] <slangasek> ev: do we have cross-retracers in launchpad now, or only for errors?
[17:33] <ahasenack> mitya57: it could be https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1159536 ranked at number 6 currently
[17:34]  * xnox realises I should have been off to volleyball 30 minutes ago....
[17:35] <ahasenack> I don't understand why it's marked "fix released", the comment that changed that says "TLB invalidate bug."
[17:39] <mitya57> ahasenack: try asking on #ubuntu-x please
[17:39] <ahasenack> mitya57: ok, thanks
[17:40] <Sarvatt> ahasenack: the upstream intel developer did that, you're hitting https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1140716/ which is a regression in the last 2 quantal and precise kernel updates that just got narrowed down tho the stable update that broke it
[17:40] <ahasenack> Sarvatt: ah, good to know, thanks for the pointer
[17:41] <mitya57> can anybody please mark https://code.launchpad.net/~lqs/ubuntu/precise/uwsgi/fix-for-1131314/+merge/152324 as WIP?
[17:52] <xvzf> join #fedora
[17:53]  * xvzf misses a slash...
[17:56] <asac> anyone heard that recent linux stable kernel update in precise might have caused problems for iwlwifi users? I rebootted today and I cannot connect to my wifi anymore :/
[17:57] <asac> err .. .actually i am on quantal :)
[17:58] <asac> mac80211: fix FT roaming
[17:58] <asac> mac80211: synchronize scan off/on-channel and PS states
[17:59] <asac> thats all i found that could be relevant
[17:59] <asac> iwlegacy: fix IBSS cleanup
[18:01] <asac> ok will observe a bit more :)
[18:03] <infinity> asac: You might want #ubuntu-kernel
[18:40] <bdmurray> mterry: based off the volume of reports on errors about bug 1056545 I think it is worth fixing in Q
[18:42] <mterry> bdmurray, sure, OK
[19:04] <ev> slangasek: Looking at ~ubuntu-archive on osageorange, it looks like apport is running the right revno for that and there are logs for armhf, but pitti could say for certain
[19:04] <slangasek> ev: ok.  it was actually powerpc I was interested in in this case, maybe armhf is set up but powerpc not?
[19:05] <seb128> slangasek, we don't have ppc retracers afaik
[19:05] <slangasek> seb128: ok, but we have cross-retracer capabilities
[19:06] <seb128> slangasek, the number of users didn't make it worth the maintenance cost
[19:06] <slangasek> so why aren't we using the cross-retracing for powerpc :)
[19:06] <seb128> because nobody allocated the time/resources to set it up/maintain it? ;-)
[19:07] <seb128> though that's probably a lower cost since pitti reworked the system to not use chroots with a full system to update daily and keep working
[19:12] <ev> slangasek, seb128: for what it's worth, we don't appear to have ever received core files for powerpc on daisy.ubuntu.com. Just amd64, i386, armhf, and armel.
[19:14] <slangasek> ev: fair enough.  Bug #1162692 for an example of a bug missing retracing.
[19:17] <ev> hm, strange that we didn't get that on daisy
[19:18] <ev> whoopsie successfully builds on ppc, but I wonder if it successfully runs :)
[19:45] <slangasek> ev: so what happens if I just add a 'powerpc' stanza on osageorange?
[19:48] <slangasek> arges: bug #1157678, "SRUed to other series" - are you actually seeing this issue anywhere outside of raring?  This is definitely a new problem in raring for me
[19:48] <arges> slangasek: i should have added 'IF it affects other series' I've only seen it on raring as well.
[19:48] <slangasek> ok
[20:01] <slangasek> ev: apparently the answer is "a whole lot of nothing" because we don't have powerpc on ddebs.u.c
[20:01] <mterry> bdmurray, uploaded quantal version of sessioninstaller too
[20:03] <bdmurray> mterry: thanks, I'll approve it soon
[20:25] <saiarcot895> hi
[20:26] <saiarcot895> could someone sponsor the merges in LP Bug 1077624 (https://bugs.launchpad.net/ubuntu/+source/flightgear/+bug/1077624) for me?
[20:30] <TheLordOfTime> wasn't raring frozen?
[20:32] <saiarcot895> it is, but I thought that once beta was released, the status goes back to Feature Freeze
[20:32] <saiarcot895> do I have to wait till the beta is released?
[20:47] <TheLordOfTime> i'm not sure, but I have a question about the freeze that was announced just over two hours ago.
[20:47] <jtaylor> the freeze only affects seeded packages
[20:47] <TheLordOfTime> but it's not important :P
[20:59] <infinity> saiarcot895: You don't have to wait for the beta to be released, no.
[20:59] <infinity> TheLordOfTime: What's your question?
[21:00] <TheLordOfTime> infinity, nevermind, i found the answer myself :P
[21:01] <infinity> Fair enough.  Then I can go have lunch instead.
[21:13] <saiarcot895> ok
[22:15] <melodie> good night
[22:36] <bdmurray> xnox: bug 1159023 should really be about those three separate packages right?
[22:45] <bdmurray> okay, I sorted that out myself
[22:46] <xnox> bdmurray: yeap. Just open a task for each one. I think desktop-* something has a checker to run against them.
[22:46] <xnox> bdmurray: ok =)
[22:47] <sarnold> thanks bdmurray :)
[22:47] <xnox> I fixed gmpc recently.
[22:48] <bdmurray> xnox: yes, I discovered that in my research