[04:04] <zruty> How to file a bug without knowing the package causing the issue?
[04:06] <micahg> zruty: is there a window?
[04:06] <zruty> no
[04:07] <micahg> zruty: ask in #ubuntu-bugs to get some help
[04:07] <zruty> No process (that I know of), no window, no nothing. Just something that does not work (which does work in Win)
[04:07] <zruty> Okay
[05:10] <pitti> Good morning
[05:29] <pitti> dupondje: good morning
[05:29] <pitti> dupondje: any luck getting the cryptsetup split into Debian?
[06:59] <dholbach> good morning
[08:06] <maximilius> Hello & sorry for this. I know DEVEL is not for user support questions. but i really need somebody with a clue to help me troubleshoot this problem.
[08:06] <maximilius> In a Gnome-Terminal i SSH to a remote host and use irssi there. As soon as i launch Rhythmbox, Liferea or if i browse a modern website with Firefox or Chromium i get a slideshow in "irssi" when switching channels e.g. or when typing.
[08:09] <maximilius> the hardware is an AMD64 3200 with 2GB RAM and a GeForce 8400 GS so this box should be able to handle the load, right?
[08:12] <maximilius> Ubuntu 10.04 11.10 and 12.04 show all this same problem
[08:13] <maximilius> please, how can i get to the source of the problem?
[08:26] <janimo`> @pilot in
[08:30] <jamespage> anyone know if the LP buildd's support inotify?
[08:32] <pitti> jamespage: I don't see why they wouldn't, but I'm not 100% sure
[08:32] <pitti> jamespage: you mean for test suites, etc}
[08:32] <pitti> jamespage: glib uses inotify, and its tests succeed on the builders
[08:33] <jamespage> pitti, https://launchpadlibrarian.net/98985481/buildlog_ubuntu-precise-i386.nodejs_0.6.12~dfsg1-1ubuntu1~precise1~ppa1_FAILEDTOBUILD.txt.gz
[08:33] <jamespage> its in a PPA builder - not sure whether that makes a difference
[08:34] <jamespage> the test that fails passes in my local sbuild - the feature depends on inotify and the test fails with ENOSYS which would indicate it does not
[08:35] <pitti> jamespage: ah, it's possible that glib falls back to something else if inotify isn't available
[08:36] <jamespage> pitti, I can allow this test to optionally FAIL so I can work around it but would like to know for sure
[09:06] <cjwatson> jamespage: I don't know specifically about inotify, but they do run hardy-era kernels
[09:06] <cjwatson> so it's not usually a surprise to find the odd missing feature
[09:15] <janimo`> dholbach, hi, how can a merge request be taken off the sponsors list? I see no equivalent of the unsubscribe button that bugs have
[09:15] <dholbach> janimo`, you can mark the status of the whole merge proposal as 'work in progress' or 'rejected'
[09:17] <janimo`> dholbach, ok. I only see work in progress as an option. The linked bug has been marked won't fix, but that was not very obvious in the review page until I looked for it explicitly
[09:17] <dholbach> janimo`, in that case please ask in the channel for somebody (TB + other ~ubuntu-branches people) to mark it as rejected
[09:18] <janimo`> dholbach, what about deleting the proposal is that not something usually done?
[09:19] <dholbach> I usually try to keep it around, so the contributor can maybe click on "resubmit"
[09:19] <dholbach> I don't know
[09:19] <dholbach> anyone else ^?
[09:20] <janimo`> dholbach, I find some merges get into the sponsoringl ist when they would better be left as discussion among the various people involved in the package/bug
[09:20] <micahg> I would think to only delete if there's something destructive
[09:20] <dholbach> janimo`, I agree
[09:21] <janimo`> as they are clearly not beginners asking for a non-controversial change
[09:21] <janimo`> dholbach, the reason I tiptoe around most of the time in the sponsoring qa list is many issues seem specific bugfixes better left to the submitter and the de facto maintainer to sort out
[09:22] <dholbach> janimo`, in that cases it might make sense to get in touch with the maintainers and discuss it with them
[09:22] <janimo`> dholbach, well they are subscribed to the specific bugs and attachments  I'd hope
[09:23] <dholbach> you know how sometimes things get lost in big mailboxes
[09:23] <janimo`> does anything with a debdiff attached automatically make it to the list ?
[09:23] <dholbach> I usually ping them or join their IRC channel
[09:23] <dholbach> yes, there's a bot running which adds debdiff bugs to the sponsoring queue
[09:24] <janimo`> cyphermox, I unsubscribed sponsors from 915095 as that is something you've touched before
[09:26] <cjwatson> janimo`: in general one does not delete things from LP
[09:26] <cjwatson> "one does not simply WALK into Mordor"
[09:26] <janimo`> cjohnston, yeah. I wish the button was not that prominent on the side then, it is unclear it is not a good thing to do, solely from the UI
[09:27] <janimo`> cjohnston, sorry for pinging you twice, one of them by accident
[09:37] <pitti> jibel: hm, the lucid-precise-universe upgrade test didn't run today?
[09:37] <pitti> jibel: the at-spi fix is in, so I'm hoping it can resolve the upgrade path better now
[09:38] <pitti> jibel: not a biggie, I can wait until Monday; by then we'll hopefully also have LibO built
[09:42] <jibel> pitti, there was a maintenance in the lab yesterday evening and the slave didn't restart. I'll start the job.
[09:42] <pitti> jibel: ah, thanks
[09:43] <jibel> slave = "jenkins slave" to avoid any confusion
[10:02] <jamespage> larsduesing, want me to take a run at fixing those upstart issues? I have already refactored in the process tracking stuff locally
[10:09] <cjwatson> jelmer: I've done bug 968273 for you, but please note that syncs are now self-service when you have upload permissions to the package in question, which you do: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html
[10:11] <janimo`> @pilot out
[10:44] <hrw> are there chances to get http://paste.ubuntu.com/907017/ intergrated into precise? This is fix for debian bug #659588 (which is also present in Ubuntu)
[10:48] <pitti> hrw: yes, absolutely; now that 2.30-2 has hit unstable, it'd be good to merge again anyway
[10:48] <hrw> pitti: so request sync rather then submit patch?
[10:49] <pitti> hrw: I believe we need to merge, we still have some transient delta
[10:49] <hrw> right
[10:49] <pitti> hrw: is there an ubunty counterpart for this bug? if so, pleaes feel free to assign to me
[10:50] <hrw> pitti: Bug #950967
[10:50] <pitti> hrw: thanks, grabbing
[10:50] <hrw> pitti: thx
[10:52] <hrw> pitti: it will unblock lot of packages for cross builds ;)
[11:27] <dupondje> pitti: as told, there will be first a new release in debian with only bugfixes, next upload will be the split
[11:27] <dupondje> but the maintainer is quite buzzy atm, so need to spank him :)
[11:29] <dupondje> slangasek: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/874774 could you simulate this? Tried here, but it always mounts the swap just fine :(
[12:10] <mdeslaur> slangasek: think you could milestone a few of the broken openssl bugs? the 1.0.1 upload is breaking a lot of stuff...
[12:17] <jayson_> Hello!  I just wrote a patch for annotate-output to add some features.  Ubuntu's is forked from upstream so sending it there isn't helpful.  It's not a bugfix so opening one wouldn't be right.  Where /should/ I submit it?
[12:21] <dupondje> jayson_: you can open bugreports for new features also :) its not for bugs only.
[12:25] <cjwatson> mdeslaur: I'd welcome suggestions on a fix, since the Debian maintainer doesn't seem to have any immediate bright ideas
[12:26] <cjwatson> admittedly -tls1 does seem to solve all the ones I've seen so I suppose maybe a change of defaults or something ...
[12:26] <jayson_> OK, cool.  Will do.  Thanks!
[12:27] <cjwatson> jayson_: I don't see any Ubuntu-specific changes to annotate-output at the moment, though
[12:28] <mdeslaur> cjwatson: hrm, upstream bug says to disable tls1.2 in the client for now
[12:28] <cjwatson> jayson_: so not sure what you mean by us being forked.  The package as a whole has Ubuntu-specific changes, but that script doesn't
[12:29] <mdeslaur> cjwatson: if there's no better solution before we release, maybe we should do that and fix with a SRU later on once they figure something out
[12:29] <cjwatson> mdeslaur: do you have a reference to the upstream bug, please?
[12:29] <mdeslaur> cjwatson: http://rt.openssl.org/Ticket/Display.html?id=2771&user=guest&pass=guest
[12:30] <cjwatson> thanks
[12:31] <cjwatson> I've milestoned it
[12:31] <cjwatson> (bug 956371)
[12:31] <cjwatson> it was already rls-p-tracking but I guess we have to tick all the boxes
[12:31] <cjwatson> err, sorry, bug 965371
[12:34] <jayson_> cjwatson: compare /usr/bin/annotate-output vs http://jeroen.a-eskwadraat.nl/sw/annotate/annotate - the former has options for format strings and --help, the latter does not
[12:34] <mdeslaur> cjwatson: thanks
[12:41] <cjwatson> jayson_: in practice the current upstream for that script is Debian, wherever they originally got it from, and Debian's and Ubuntu's version of that script are identical.
[12:41] <cjwatson> jayson_: what you're seeing is the changes that Debian made since the initial import.
[12:43] <jayson_> Oh, I thought it was originally pulled by Ubuntu, not Debian.  Checked again, you're right!  I'll send the patch to Debian.  Thanks!
[12:49] <Whoopie> seb128: Hi, regarding bug 965279, I'm not sure if the battery status icon should be hidden in all sessions. To my understanding, gnome-shell doesn't use indicator-power, so it needs g-s-d's battery icon.
[12:51] <seb128> Whoopie, gnome-shell has its own shell indicator
[12:52] <seb128> gnome-classic as the indicator
[12:52] <seb128> unity has the indicators
[12:52] <seb128> other desktop don't use gsd
[12:52] <Whoopie> seb128: ok, thanks for the explanation.
[13:46] <smb> cjwatson, Doing some slightly more special iso testing I found some unexpected things happening in the lands of fakeraid and the installer. Somehow I thought that all fakeraid was handled by dmraid (and bug reports seemed to say it works). However we failed to put the right dm module into the udebs without noticing.
[13:49] <smb> The d-i file has dm-raid4-5, unfortunately the modules name is dm-raid45. This probably goes on for a while now. It is probably just hidden by the fact that md(adm) now understands some other meta-data formats, one of them being the Intel Matrix Storage Manager format (which is probably the most widely spread)
[13:53] <smb> Does not seem to completely work on the box I tested as I only get it up read-only and did not yet succeed in making it rw. The question is whether fixing the modules name for udeb (while correct) could have some unexpected results for the installation process. So maybe it would be better delayed till after release to be targetted to a point update...
[13:56] <smb> Daviey, Maybe of interest to you ^ though for server I believe people usually avoid fakeraid usage and go mdraid directly (or hw raid)
[13:57] <cyphermox> janimo`: the patch was incorrect for a variety of reasons though I'm happy to see the process for sponsoring and patching a package was dead on. I updated 915095 accordingly; m-b-p-i tends to be a little special anyway
[13:58] <cjwatson> smb: please go ahead and put the correct module into the udeb
[13:58] <cjwatson> before release
[13:58] <Daviey> smb: Oo, i didn't know md now supported other formats
[13:58] <smb> cjwatson, Ok, will do then
[13:58] <Daviey> smb: I'd rather fakeraid support was removed.. but can't see that happening :)
[13:59] <smb> Daviey, Me neither
[13:59] <janimo`> cyphermox, ok
[14:00] <cyphermox> janimo`: thanks for looking at it :)
[14:01] <janimo`> cyphermox, piloted by it ;)
[14:01] <cyphermox> ah, right
[14:02] <cyphermox> vibhavp: if you want to help writing patches for the 17 or so bugs in m-b-p-i, that would be very cool; then I'll poke upstream to get the patches committed and cut a new snapshot.
[14:05] <vibhavp> cyphermox: sure!
[14:06] <cyphermox> vibhavp: bug 912728 looks very straightforward, needs full triaging and the patch is provided
[14:07] <vibhavp> I need to make debdiffs for them?
[14:07] <cyphermox> well, it's not quite a patch it seems, but fixing that up should be simple enough :)
[14:07] <cyphermox> debdiff, or fix the patch directly as a patch and send it to the upstream bug tracker (GNOME, in the NetworkManager project)
[14:08] <cyphermox> I prefer option 2, since we usually just sync the package from Debian directly
[14:08] <vibhavp> Ill report a bug in the GNOME BTS, right?
[14:08] <cyphermox> yes
[14:08] <vibhavp> alrighty
[14:09] <cyphermox> bonus points if you fix the "patch" included in the LP bug report to make it a real patch to add to the upstream bug :)
[14:09] <vibhavp> Ah, I understood
[14:10] <vibhavp> He copied the entire file
[14:10] <cyphermox> yeah
[14:10] <vibhavp> thats easy
[14:13] <vibhavp> The component will be general, right?
[14:13] <cyphermox> yes
[14:13] <vibhavp> And the version is "0.9.x"
[14:15] <vibhavp> Done, attaching patch
[14:22] <vibhavp> cyphermox: Done
[14:22] <vibhavp> https://bugzilla.gnome.org/attachment.cgi
[14:23] <vibhavp> oops :)
[14:23] <vibhavp> cyphermox: https://bugzilla.gnome.org/show_bug.cgi?id=673180
[14:23] <cyphermox> ok
[14:24] <cyphermox> have you also linked the bug report in launchpad? you should be able to add that link via "Also affects project"
[14:24] <vibhavp> done
[14:24] <cyphermox> thanks
[14:24] <vibhavp> next!
[14:25] <cyphermox> vibhavp: yeah, let's just move to pm so as not to disrupt here :)
[14:25] <vibhavp> sure
[14:58] <pitti> doko: hm, should gccgo-4.7 really produce the gcc-4.7-base, fortran, and other packages as well?
[15:07] <doko> pitti: ugh, does it?
[15:08] <pitti> doko: spotted in https://launchpad.net/ubuntu/precise/+queue?queue_state=0
[15:08] <pitti> doko: and from apt-cache showsrc gccgo-4.7 | grep ^Binary
[15:08] <doko> pitti: no, will fix it
[15:09] <pitti> doko: thanks
[15:09] <pitti> doko: probably needs another gcc-4.7 upload then, so that the binaries of that have a higher version?
[15:10] <doko> pitti: there is no gcc-4.7 in precise
[15:11] <pitti> doko: oh right; apt-cache showsrc gcc-4.7 actually shows gccgo-4.7, sorry
[15:11] <pitti> doko: so these will/shoudl just become NBS, I figure
[15:12] <doko> yes
[15:13] <pitti> doko: the libraries are a bit more tricky then
[15:13] <pitti> e. g. lib32stdc++6 is currently built by gccgo-4.7
[15:13] <pitti> but ought to be from gcc-4.6
[15:14] <arges> Hello. Trying to apply an upstream patch for 'nss-pam-ldapd', I see that this package is primarily imported from debian and in fact i don't see a debian/patch directory. not sure how to approach a fix for this bug... do i need to submit something to debian first? or  should I create the patch directory in ubuntu?
[15:19] <doko> pitti: wait, is this already in the archive?
[15:19] <SpamapS> @pilot in
[15:19] <pitti> doko: NEW only has the armhf binaries, I didn't check the others
[15:19] <apw> cjwatson, am i right in saying that if you add a machine to the blacklist then linux_gfx_payload=text _and_ we stop supplying handoff ?
[15:19] <pitti> doko: ah, i386/amd64 FTBFSed
[15:20] <pitti> doko: so let me quickly reject the armhf binaries before someone accepts them, ok?
[15:20] <slangasek> mdeslaur: what's "a few"?  The only one on my radar is the TLSv1 autodetection problem; if there are other bugs, could you point them out / set the bug importance?
[15:20] <doko> pitti: yes please
[15:20] <pitti> doko: hang on, it's probably less bad than I thought -- Binary: shows them all, but it seems they are not actually built
[15:20] <pitti> doko: https://launchpad.net/ubuntu/+source/gccgo-4.7/4.7.0-0ubuntu1/+build/3368176
[15:21] <slangasek> dupondje: no, I haven't ever been able to reproduce that bug yet
[15:21] <pitti> doko: it still has gobjc and fortran, shoudl it?
[15:21] <doko> pitti: no
[15:21] <pitti> doko: ok, rejected
[15:22] <pitti> doko: thanks for looking into it
[15:25] <mdeslaur> slangasek: I duped  one, the others that I thought were dupes look unrelated once I looked at them carefully.
[15:25] <cjwatson> apw: sorry, head in something else right now, is that what the code implies?
[15:26] <apw> cjwatson, s'ok we'll work it out
[15:28] <cjwatson> apw: AFAICS it doesn't delete vt.handoff=7 from the kernel command line in that case, merely doesn't load video modules in GRUB
[15:29] <cjwatson> that was what I interpreted you as arguing should change in our conversation yesterday
[15:29] <apw> cjwatson, that might be counter to what i was expecting ... yeah interestingly this is a second case where handoff is an issue, due to bad drivers; though the jury is out as the testing is not yet done correctly
[15:30] <cjwatson> it's basically the same as yesterday's case
[15:30] <cjwatson> as far as any fix is concerned anyway
[15:32] <apw> cjwatson, concur, any fix would be the same.  either i need to check if you did leave me in graphics mode and ignore handoff if you did not, or grub needs to tell us what it did do
[15:32] <apw> though why its an issue today and not all last cycle i am most confused by
[15:47] <Daviey> didrocks: hola, sphinx/1.1.3+dfsg-2ubuntu1 seemed to lack dh python2 transition, or still depend on python-support.
[15:47] <Daviey> didrocks: it's depwait.
[15:48] <didrocks> Daviey: hey, weird, I built it here IIRC
[15:49] <didrocks> Daviey: I'll have a look if you wish (probably Monday though)
[15:50] <cjwatson> didrocks: your build chroot probably has universe enabled
[15:50] <didrocks> cjwatson: yeah, should be why I didn't spot that
[15:51] <didrocks> anyway, I'll fix it if that can wait on Monday, still some stuff to end before the week-end
[15:52] <Daviey> didrocks: someone might beat you to it :)
[15:52] <slangasek> apw, cjwatson: is there a bug number for that discussion, by chance?  it probably has bearing on half a dozen plymouth bugs, so I'd like to know what's going on :)
[15:53] <didrocks> Daviey: TBH, I won't be upset by that :)
[15:53] <cjwatson> slangasek: I asked apw to file one but haven't checke
[15:53] <cjwatson> d
[15:54] <apw> slangasek, the disucssion was in the context of an ongoing bug with not seeing the encrypted password prompt for an lvm encrypted root setup, in the first instance
[15:54] <apw> slangasek, LP#942846
[15:54] <mpt> ev, bug 794757
[15:55] <apw> slangasek, the new one is not yet a bug as far as i know, its with hwe
[15:55] <ev> mpt: cheers
[15:55] <slangasek> apw: right, is that the "it shows up if you double-tap esc" bug that I kicked your way this week?
[15:55] <slangasek> (bug #966403)
[15:55] <slangasek> or a different one?
[15:56] <apw> slangasek, that would be the same symptoms by the sounds of it.  what graphics do they have ?
[15:56] <slangasek> apw: nouveau
[15:56] <slangasek> but that's booting *with* splash
[15:56] <apw> slangasek, ok so that sounds like what rtg found when he was trying to reproduce it
[15:56] <slangasek> + vt.handoff
[15:57] <slangasek> so my analysis was that this was a behavior change in the nouveau driver since last cycle, because I don't think anything else pertinent has changed that would cause tihs
[15:57] <slangasek> this
[15:57] <apw> slangasek, yeah, i wish i had somethign which reproduced it so i could reproduce it
[15:57] <apw> erm, or something ... all the boxes i have tested just work
[15:58] <slangasek> including nouveau ones?
[15:58] <apw> i have no nvidia kit here, i am waiting on my radeon to install now
[15:58] <slangasek> ok
[15:59] <apw> to try and reproduce this same issue
[15:59] <slangasek> note that radeon and intel by default use the drm interface directly, nouveau is set to use /dev/fb due to historical hangs with multimonitor
[15:59] <slangasek> so to entirely reproduce this you'd have to bodge the driver somehow
[16:00] <apw> slangasek, i wonder if we could switch it over to drm as an experiment
[16:00] <slangasek> there's a plymouth option (Ubuntu specific) to force it
[16:01] <slangasek> so we could ask people to test with that
[16:01] <apw> slangasek, what is that so i can get rtg to test with it also
[16:03] <slangasek> apw: sorry, OTP now - it's obvious from the plymouth source package patches, otherwise I can look it up for you in a second
[16:04] <apw> slangasek, no problem will look
[16:06] <apw> slangasek, plymouth:force-drm
[16:10] <apw> slangasek, ok that didn't help rtg though he was able to use ESC ESC to fix thigns
[16:11] <apw> slangasek, what does plynouth do on esc ... switches back to normal text mode right and back to splash again
[16:14] <slangasek> apw: correct
[16:15] <apw> dammit now the cd writer thing just explodes
[16:17] <jodh> slangasek: https://bugs.launchpad.net/plymouth/+bug/553745/comments/183
[16:21] <cjwatson> coo
[16:22]  * apw is pleased to find brasero still works ... oneone know what the 'CD Writer' thing is called which pops up by default so ic an file a bug ?
[16:24] <bkerensa> audiojack stopped working since B2
[16:24] <bkerensa> :(
[16:36] <hallyn> @pilot in
[16:38] <bkerensa> diwic:  ping
[16:44] <slangasek> jodh: huzzah! \o/
[16:44] <stgraber> jodh: yay! (apparently slangasek and I just saw the same bugmail ;))
[16:52] <jodh> slangasek/stgraber: progress at last!
[16:52]  * jodh heads off to sniff out a cold beer...
[16:53] <slangasek> jodh: though I wish you hadn't merged those bugs, I'm now drowning in bug mail ;)
[17:07] <micahg> cjwatson: if I get board over? the weekend, mind if I upload aptitude
[17:07] <micahg> s/board/bored/
[17:07] <cjwatson> micahg: too late
[17:07] <cjwatson>   Uploading aptitude_0.6.6-1ubuntu1_source.changes: done.
[17:07] <micahg> cjwatson: ooh, good to hear :)
[17:08]  * micahg was seeing the natives getting restless
[17:08] <cjwatson> not that it entirely fixes the multiarch bugs, so I haven't closed the one that's on rls-p-tracking
[17:08] <cjwatson> but at least they won't be getting restless at me :P
[17:10] <slangasek> cjwatson: does it fix it well enough that we should un-track the bug now?
[17:10] <cjwatson> I don't know, I'm not enough of an aptitude user to be qualified to say
[17:11] <cjwatson> (IOW I find its interface incomprehensible anyway and have a hard time saying when it's less incomprehensible)
[17:11] <cjwatson> I've commented on the bug, and given its activity level I expect we'll hear from affected users soon enough
[17:11] <astraljava> Oohh... aptitude having multiarch support?
[17:11] <astraljava> Schweet!
[17:11] <cjwatson> ish, see what I just said
[17:11] <astraljava> Well yeah, but something is better than nothing. :)
[17:20] <raffa50> hello
[17:20] <raffa50> how can i insert a new mime type?
[17:21] <hallyn> ppetraki: cjwatson: lp:~psusi/ubuntu/precise/multipath-tools/fix-dmraid  splits multipath-tools-boot into kpartx-boot for dmraid.  WOuld that require seed changes to not break installs?
[17:21] <hallyn> (since you were just dealing with that...)
[17:21] <raffa50> example: i made an application  (that you can install whit a .deb) that makes a .slyproj file, but the user should open it whit double click
[17:22] <raffa50> (whit double click on .slyproj my application should open)
[17:24] <raffa50> sorry for my bad english i'm italian and i'm making ad IDE
[17:25] <hallyn> raffa50: check the comment at top of /etc/mime.types - i think it's relevant
[17:25] <raffa50> where?
[17:25] <hallyn> (in other words, see the mime-support package, and email that list if you want something added)
[17:25] <hallyn> on your system...
[17:25] <raffa50> ah root dir
[17:25] <hallyn> head -40 /etc/mime.types
[17:26] <hallyn> i'm surprised, i'd have expected an /etc/mime.types.d that gets included from ~/.mimetypes at least
[17:26] <raffa50> .deb can't add my mime type to the user?
[17:26] <hallyn> if the user already exists, yes
[17:26] <raffa50> i made an ide
[17:26] <raffa50> that creates a file
[17:26] <raffa50> whit extension .slyproj
[17:26] <raffa50> ok?
[17:26] <hallyn> yes
[17:27] <raffa50> i want that the user can open it
[17:27] <hallyn> yes
[17:27] <raffa50> whit double clik
[17:27] <hallyn> yes
[17:27] <raffa50> it is possible?
[17:28] <hallyn> as the comment says, you can add the entry to ~/.mime.types
[17:28] <hallyn> all i'm saying is that if you then create a new user after installing tha tpackage, that user won't get that .mime.types automatically
[17:28] <hallyn> i wonder if there is another, file-manager-specific, way
[17:28] <raffa50> not me
[17:28] <raffa50> an user that download
[17:28] <hallyn> raffa50: might ask in #ubuntu-desktop
[17:28] <raffa50> myu program
[17:28] <cjwatson> hallyn: it doesn't need seed changes if there's a dependency.  I haven't checked whether that's so
[17:29] <raffa50> no way!
[17:31] <hallyn> it adds a dep from multipath-tools-boot to the new kpartx-boot, yes
[17:31] <hallyn> thx
[17:34] <jodh> slangasek: yes, sorry. In fact bug 553745 now seems totally unviewable :(
[17:48] <slangasek> jodh: yes, that's also part of why I didn't bother merging the bugs ;)  Good thing you now have all the info you need in order to fix it ;)
[18:25] <smoser> pitti, wonder how valid you think this bug is
[18:25] <smoser> bug 969462
[20:16] <cnd> bdmurray, is it possible to do a search of unmilestoned bugs?
[20:31] <bdmurray> cnd: could you elaborate a bit?
[20:32] <cnd> bdmurray, I can search for all bugs for utouch-grail
[20:32] <cnd> or bugs against specific milestones
[20:32] <cnd> but how do I search for bugs that haven't been milestones
[20:33] <hallyn> @pilot out
[20:34] <bdmurray> cnd: I think you'd have to iterate through all bugs and make sure they don't have a milestone
[20:34] <cnd> ugh
[20:34] <cnd> bdmurray, ok, thanks :)
[21:20] <bkerensa> pitti: Do you by chance know of any updates that got pushed today that could have caused headphones not be sensed or broken alsa?
[21:21] <bkerensa> pitti: I just see you have done some work with those packages and my audio is gone and debugging is not doing a thing for me.
[21:36] <broder> any AAs around willing to accept the mosh backports from binNEW?
[21:38] <hallyn> cyphermox: around?
[21:38] <cyphermox> yes
[21:39] <hallyn> cyphermox: great! :)  I was wondering, on libnl-3-dev vs libnl-dev,
[21:39] <cyphermox> libnl-3-dev is libnl 3.2.3; libnl-dev should be libnl 1.something
[21:39] <hallyn> cyphermox: why /usr/include/libnl/netlink instaed of /usr/include/netlink? is that so both pkgs can be installed?
[21:40] <hallyn> cyphermox: new libvirt just #includes <netlink/msg.h>, so won't build with just libnl-3-dev...
[21:40] <cyphermox> not really, I think upstream just changed it
[21:40] <hallyn> that's not very nice :)
[21:40] <cyphermox> hallyn: should still build, I think libnl-3-dev is supposed to give you the right includedir
[21:40] <hallyn> didn't on my test rig
[21:40] <hallyn> i had to symlink the dir
[21:41] <cyphermox> shouldn't be required, see /usr/lib/pkgconfig/libnl-3.0.pc
[21:41] <cyphermox> I think there may be an issue with cflag paths
[21:42] <cyphermox> actually, come to think of it, I believe I may have an email about this kind of issue from the debian maintainer, let me check
[21:43] <dylan-m> Hey, can anyone give me a hint for when Precise's new desktop background is going to appear?
[21:46] <cyphermox> nevermind, it was for ipvsadm
[21:46] <hallyn> cyphermox: ok, so it *should* "just work"
[21:46] <cyphermox> hallyn: should, but it's not unheard of that projects don't use pkgconfig files :)
[21:47] <hallyn> i would think libvirt does.  it ships its own anyway :)  not that i have any idea how to use those
[21:47] <cyphermox> hallyn: is this failing with what's currently in the archive or are you working on another branch?
[21:48] <hallyn> upstream git definately.  I don't *think* I had a problem with what's in the archive, and at any rate the buildd built one fine last night
[21:48] <cyphermox> hallyn: do you have a branch I could play with, or at least logs from the failure? I'm pretty sure you'd see the issue from the log
[21:48] <cyphermox> (and then looking at Makefile to see what the value for LIBNL_CFLAGS is, if any)
[21:50] <hallyn> cyphermox: I'm afraid not right now.  It's on a box that's shut down atm.  Can I ping you monday after i push it somewhere?
[21:50] <cyphermox> hallyn: certainly. Or I'll mess around with it during the weekend
[21:51] <cyphermox> if it's from git, I'm pretty sure you'll get the same behavior just building directly from the git tree
[21:51] <hallyn> cyphermox: no, they're on libnl1 still, so we have to convert to libnl-3 with some patches from our tree
[21:51] <Darxus> Does precise really not have the Gtk3 perl module, or am I just not finding it?
[21:52] <cyphermox> hallyn: ah, I see
[21:52] <cyphermox> so the libnl-3 patch probably doesn't correctly apply for that new version
[21:52] <hallyn> yeah, that could be.  so it's my fault :)
[21:52] <hallyn> cyphermox: ok, thanks.  That just may give me all the guidance I need :)
[21:52] <hallyn> have a good weekend
[21:53] <cyphermox> hallyn: np. feel free to ping anytime, I'll be home and not far from a computer anyway.
[23:45] <SpamapS> @pilot out