[00:00] <slangasek> cjwatson: heh, right :)
[00:19] <cjwatson> TheMuso: I think vdk2 and vdkxdb2 can be synced; do you agree?
[00:19] <cjwatson> (you're touched-it-last)
[00:20] <luist> hey guys.. i need a live usb to identify the hardware on a machine… i found this project that is supposed to do it: http://sourceforge.net/projects/dhlu/files/  but i dont know how to use the tar.gz or its contents. They said it was tested in ubuntu! How can i test it?
[00:20] <TheMuso> cjwatson: I haven't even looked TBH.
[00:21] <TheMuso> cjwatson: So go ahead.
[00:21]  * TheMuso is still doing alsa related merges.
[00:23] <cjwatson> TheMuso: fair enough, thanks - done.  I think those two were you-as-patch-pilot rather than you-as-yourself anyway
[00:23] <TheMuso> Right.
[00:23] <cjwatson> (just noticed because I was fixing vdkbuilder2 to stop failing to sync)
[00:23] <TheMuso> ah ok.
[00:58] <TheMuso> slangasek: Unless you have a particular need/desire to do so, I'm happy to take care of the jack merge, as I need it to merge alsa-plugins with debian.
[00:59] <slangasek> TheMuso: please go ahead
[00:59] <TheMuso> Ok thanks.
[02:10] <slangasek> cjwatson: new upstream version of wget in Debian adds libidn support, and there's no udeb for that.  It looks like you've done some work on that recently for libssl udeb support (bug #503339).  Do you know if wget-udeb has features over the busybox one that we need, or would we maybe be just as well off to drop wget-udeb?
[02:10] <ubottu> Launchpad bug 503339 in wget (Ubuntu Lucid) "UEC lucid installer: CC fails to register when separated from CLC" [High,Fix released] https://launchpad.net/bugs/503339
[02:13] <slangasek> cjwatson: in fact, I can't find any references to wget-udeb in seeds or in the debian-installer source
[02:14] <nigelb> *groan*
[02:14] <nigelb> Morning
=== kentb is now known as kentb-out
[03:03] <slangasek> RAOF: hi, I see that you have changes staged in bzr for avahi; do you want to take over the Debian merge as well?  I have no attachment to it
[03:04] <RAOF> Neither do I, except that I wanted debugging symbols for it at one point.
[03:04] <RAOF> I'll take the merge if you want, though.
=== zyga is now known as zyga-gone
[03:05] <slangasek> RAOF: it's yours :)
=== GrueMaster_ is now known as GrueMaster
[04:20] <pitti> Good morning
[04:20] <pitti> micahg: ffox7 maverick> fine for me this week; I need to request a full maverick export and prepare them, so I need a week of advance notice
[04:21] <micahg> pitti: so what would be the timeline for hitting updates?
[04:23] <pitti> micahg: I need to ask dpm to have a maverick LP export (they don't happen automatically any more), so I think I can have the new packs ready for -proposed upload at EOW
[04:24] <micahg> pitti: that only gives us 10 days in updates before the next firefox release, can we do the week after UDS instead and target for Firefox 8?
[04:27] <pitti> micahg: sure
[04:28] <micahg> pitti: ok, thanks
[04:33] <micahg> pitti: do you have moderation rights to the precise-changes list?
[04:33] <pitti> micahg: no, I don't; is that moderated at all?
[04:34] <micahg> pitti: must be, all my upload E-Mails seem to be stuck in moderation, I noticed Daviey's were cleared earlier today
[04:35]  * micahg will bug the sysadmins when one is around then...
[05:48] <slangasek> pitti: morning
[05:48] <pitti> hey slangasek, how are you?
[05:48] <slangasek> pitti: not bad! you?
[05:48] <pitti> slangasek: pretty well, thanks
[05:48] <slangasek> pitti: great :)
[05:49] <pitti> playing whack-an-SRU
[05:49] <pitti> they feel like a hydra these days, but that's pretty normal right after release :)
[05:49] <slangasek> pitti: yep, I see :) and I just saw bug #788514 had an SRU for onboard, which seems rather strange to me... surely we're not changing packaging helpers in an SRU?
[05:49] <ubottu> Launchpad bug 788514 in pyxdg (Debian) "python packages on the CDs not using dh_python2" [Unknown,New] https://launchpad.net/bugs/788514
[05:49] <pitti> the whole SRU is rather strange..
[05:50] <pitti> I left a comment in the FFE, and it has some details
[05:50] <slangasek> which bug is the FFe?
[05:50] <pitti> bug 872374
[05:50] <ubottu> Launchpad bug 872374 in onboard (Ubuntu) "Oneiric-proposed: new version of Onboard with GI, gsettings,..." [High,New] https://launchpad.net/bugs/872374
[05:52] <slangasek> pitti: ah... makes sense I guess
[05:52] <slangasek> and anyway, it's had enough eyes on it by now ;)
[05:53] <slangasek> actually, it looks like 788514 shouldn't have been listed in the changelog at all
[05:53] <slangasek> will be interesting to see if this SRU successfully passes verification, I guess
[05:55] <pitti> yeah, I'd like to get some feedback from actual onboard users there, not just a cursory "it still starts" kind of thing
[06:02] <TheMuso> I'll make sure the word gets out the community at large. I certainly wouldn't have uploaded it if Kate hadn't put a provisional stamp on it.
[06:07] <micahg> any tips on -Werror=format-security errors?
[06:07] <micahg> seems to be new in precise
[06:08] <slangasek> micahg: insert a "%s" in front of whatever string variable you're currently passing
[06:09] <pitti> micahg: doko and cjwatson discussed it yesterday, and it seems it was a not-quite-intended effect of the merge
[06:09] <pitti> ... dpkg merge
[06:09] <pitti> while it's certainly a great thing to have, it makes tons of universe packages FTBFS, so I think they wanted to back it out again
[06:09] <micahg> pitti: so, should I wait rather than fix?
[06:10] <micahg> slangasek: would this be something to upstream, at least to Debian?
[06:10] <pitti> micahg: well, fixing format string errors is always good :)
[06:10] <pitti> micahg: yes, definitively something for upstream
[06:10] <slangasek> yes
[06:10] <pitti> we wanted to back it out not because the warnings are bad, but because it'd introduce too much universe FTBFS just yet
[06:11] <micahg> ok, will give it a shot then
[06:11] <micahg> the package I'm fixing ATM is in main (directfb)
[06:11] <pitti> the usual case is something like printf(var) or printf(_("hello %s"))
[06:11] <pitti> sorry, second without the %s
[06:11] <micahg> wanted to get the libjpeg changed and got more than I bargained for :)
[06:11] <pitti> i.e . if a translator translates "hello" as "foo %s" etc, you get crashes
[06:12] <slangasek> I "upstreamed" unixodbc fixes to myself for this already; they were false positives in that the strings aren't user controllable, but all the same
[06:12] <slangasek> s/crashes/exploits/
[06:13] <Chipzz> pitti: I wonder how much such a thing really happens though. And I wonder /if/ such a thing happens, bad intentions weren't involved in the first place?
[06:13] <pitti> Chipzz: certainly not bad intentions in most cases
[06:14] <pitti> and we did have crashes due to bad format strings, it's not just a theoretical issue
[06:14] <slangasek> yes, it happens due to bad tooling, not bad intentions
[06:15] <micahg> something like this seems like a false positive: snprintf( ret_desc->name,   DFB_GRAPHICS_DEVICE_DESC_NAME_LENGTH, device_info.name );
[06:16] <slangasek> micahg: are you sure device_info.name can never contain a format string?
[06:16] <slangasek> better safe than sorry
[06:18] <RAOF> There's no special attention needed when merging packages which now use dpkg-buildflags to get hardening flags, is there?  That'll just work for us, too?
[06:19] <micahg> RAOF: that's what I was told
[06:19] <slangasek> RAOF: correct
=== tkamppeter_ is now known as tkamppeter
[06:51] <micahg> got it, those format string errors weren't so bad...
=== micahg changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cnd
[06:59]  * micahg wonders if cnd is still piloting...
[07:00] <dholbach> good morning
[07:01] <didrocks> micahg: I guess he is forever! :-)
[07:01] <didrocks> hey dholbach
[07:03] <dholbach> salut didrocks
=== Claudinux_ is now known as Claudinux
=== Laibsch1 is now known as Laibsch
[07:46] <slangasek> jamespage: is libslf4j-java on your radar already for MIRs?  mysql-connector-java also wants it; if libslf4j-java goes to main (along with ant-contrib, which I see the MIR for), we can make that a sync
[07:47] <jamespage> slangasek, its not but I can add it to the list
[07:47] <jamespage> ant-contrib has already been in main so should not be an issue
[07:47]  * slangasek nods
[07:47] <slangasek> libslf4j-java is wanted by libmaven2-core-java... I guess that means we probably need it?
[07:48] <jamespage> slangasek, I'm working on removing the maven parts in component mismatches at the moment
[07:48] <slangasek> ok, I'll go ahead and sync this then, and assume the rest will shake out on its own - thanks :)
[08:00] <jamespage> slangasek: should be fine libslf4j-java was in main until oneiric anyway
[08:00] <slangasek> ah, ok
[08:48] <cjwatson> slangasek: we use wget-udeb in eucalyptus-udeb and system-integrity-check; it was originally introduced for the latter, I think on the grounds that it had HTTPS support, although system-integrity-check doesn't seem to use that facility
[08:48] <cjwatson> slangasek: in the case of eucalyptus-udeb we use wget-udeb because the CLC only speaks HTTPS
[08:49] <cjwatson> slangasek: perhaps the udeb could straightforwardly be a separate build pass without libidn support?
[09:45] <micahg> hi Mirv, thanks for the update on the libvoikko issue, I'll should be able to take care of it later today
[09:46] <micahg> which reminds me, pitti, Bug #832582 is a regression caused by a firefox security upgrade in another package (libvoikko), would you like it to sit in -proposed for a week before pushing to -updates/-security or is me running through the test case sufficient?
[09:46] <ubottu> Launchpad bug 832582 in libvoikko (Ubuntu Natty) "mozvoikko makes Firefox 6 crash" [Medium,In progress] https://launchpad.net/bugs/832582
[09:47] <pitti> micahg: I'm fine with moving to -updates as soon as it's verified
[09:47] <apw> cjwatson, i have been musing about how hard it is to switch to a verbose debug boot, as the construction of the command line etc includes variables i am wondering if we could have a separate menu entry in the top level grub2 menu which would toggle the type of boot "Option: Verbose" and that could set variables to flip the boot style
[09:47] <micahg> pitti: thanks
[09:48] <micahg> pitti: I'm going to build it in the Mozilla Security PPA since it needs to go to -security, do you want it copied through proposed at all?
[09:48] <pitti> micahg: ah, security route WFM
[09:49] <pitti> micahg: in fact, better to have in -security, as people who only have -seurity, but not -updates should still get it
[09:49] <micahg> pitti: exactly, thanks
[09:56] <cjwatson> apw: it starts getting unwieldy; really once we start having toggleable options I think we want to be doing something involving gfxmenu
[09:57] <apw> cjwatson, sounds like a beermat conversation at UDS level problem to me
=== zyga-gone is now known as zyga
=== zyga is now known as zygqa
=== zygqa is now known as zyga
[10:08]  * cjwatson uploads coreutils.  what could possibly go wrong
[10:08] <nigelb> Famous last words? :P
[10:09] <cjwatson> this is why I'm doing it at the start of a day not the dend
[10:09] <cjwatson> end
[10:09] <Mirv> micahg: ok, thank you for the information!
[10:10] <nigelb> heh, good idea :)
[10:10] <nigelb> You lose a day and not a night of sleep.
[10:10] <nigelb> Speaking of sleep.... haven't seen infinity around since the release.
[10:16] <cjwatson> nigelb: everyone's entitled to the odd holiday
[10:19] <nigelb> cjwatson: Ah! :)
[10:20] <apw> crazy notion ... noone is allowed to sleep let alone have time _off_
[10:30] <lynxman> apw: I'm all for that, clockwork orange style
[10:50] <doko_> pitti, seb128: could somebody from the desktop team take over the gamin merge?
[10:52] <pitti> doko_: yes, can do
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
=== firewave is now known as FireWaveJob
[12:40] <cjwatson> doko_: could you merge hdf5 (or I'll do it if you prefer)?  switching that to libjpeg-dev via the merge will fix several build failures
[12:44] <doko_> cjwatson, will do
[12:44] <cjwatson> ta
[13:06] <OdyX> pitti, tkamppeter: FYI, http://wiki.debian.org/Teams/Printing/RethinkingTheStack#Action_1_-_Rename_printing_driver_packages
=== deryck_ is now known as deryck
[13:06] <cjwatson> tkamppeter: BTW, the cups installability problem from yesterday should be resolved; I gave back all the failed builds, I think
[13:10] <OdyX> cyphermox: did you get my "RFC: usb-modeswitch *" mail (that is To: debian-devel) ? I'd like to have your input on that. (or slangasek's fwiw).
[13:11] <cyphermox> hadn't seen it no, looking now
[13:13] <cyphermox> I rather 5, but that's because I've already been spending lots of time on that; I do need to bug upstream to include it in the tarball though, after making sure it's in sync with the current tcl stuff
[13:48] <ximion> hi! does someone know why all recipe-builds on LP fail with this error:
[13:48] <ximion> dh clean --parallel --with python2
[13:48] <ximion> make: dh: Command not found
[13:49] <ximion> This happens now for three days, is it just me or is there something wrong for everyone?
[14:02] <geser> missing debhelper in Build-Depends?
[14:05] <OdyX> cyphermox: I would have guessed so. :-)
[14:06] <OdyX> cyphermox: what about 2 ? What would be the impact on the first CD ?
[14:06] <OdyX> (jimtcl's package being currently 464k, before me stripping most of it out.)
[14:06] <cyphermox> OdyX: embedding doesn't sound like such a bad idea to get to a standalone binary; but it won't be possible to know that it needs a rebuild when jimtcl changes (if separate), since it won't show up in nbs and stuff
[14:08] <OdyX> cyphermox: embedding is nice at first sight as it "converts" the tcl script into a standalone binary, but it's clumsy. From the distribution point of view, it's hard to justify to do static-linking where everywhere else we do dynamic, especially for a script under /usr.
[14:08] <cyphermox> right
[14:09] <cyphermox> OdyX: well, 240k on the CD isn't huge but CD size is always a major concern; if we have to I guess it can be done. that said...
[14:10] <cyphermox> OdyX: ... it doesn't cover the second case that we'll again have a tcl interpreter getting loaded at boot time, which was another reason why usb-modeswitch-dispatcher was rewritten
[14:10] <OdyX> cyphermox: we could even consider a "jimsh-tiny" that has only what usb-modeswitch needs.
[14:11] <OdyX> cyphermox: ah right. Could you maybe explain that in a mail answering mine to debian-devel ?
[14:11] <cyphermox> OdyX: otoh, how is the jimsh that usb-modeswitch ships?
[14:11] <cyphermox> I mean, is it very big?
[14:12] <OdyX> cyphermox: as far as I can see, it's a libjim.a of 316K
[14:13] <cyphermox> OdyX: ok
[14:13] <OdyX> cyphermox: when compressed into usb_modeswitch_dispatcher, the remaining binary is 188k
[14:16] <cyphermox> I wish Josua would be so kind as to ship both and allow for which version to be chosen at build time :)
[14:17] <OdyX> cyphermox: well, as I always said (I think), if the (your) C program is included upstream, I consider that "upstream" and will use that; problem solved.
[14:18] <cyphermox> right
[14:18] <cyphermox> working on it, I just sent another email to him :)
[14:20] <OdyX> nice .
[14:25] <pitti> doko_, seb128: committed our gamin chagnes to Debian, uploaded, synced
[14:26] <seb128> pitti, thanks
[14:30] <tkamppeter> cjwatson, thanks, I have already seens it.
[14:37] <doko_> lucas, what's the status of ruby1.9? should we get it into main for precise?
[14:38] <lucas> doko_: the target for finishing the migration to gem2deb is the freeze date for wheezy
[14:38] <lucas> doko_: doing it for the freeze date for precise might be difficult
[14:38] <lucas> doko_: burndown chart: http://pkg-ruby-extras.alioth.debian.org/wheezy/
[14:40] <lucas> doko_: unless we get help from the ubuntu side, of course :P
[14:44] <kelemengabor> mvo: hi, could you take a look at bug #873905 ? The proposed update-manager package seems to contain a high impact translation regression.
[14:44] <ubottu> Launchpad bug 873905 in update-manager (Ubuntu Precise) "Update-manager not using current translations during upgrade" [High,In progress] https://launchpad.net/bugs/873905
[14:50] <mvo> kelemengabor: sure
[14:50] <kelemengabor> thanks!
[14:51] <doko_> lucas, just wondering if we should get ruby1.9 into main then (to build 1.9 extensions) ... and keeping 1.8 as the default
[14:51] <doko_> cjwatson, ^^^
[14:52] <cjwatson> I'm OK with that, presumably it's not on CDs
[14:53] <Riri> New development site
[14:53] <Riri> http://goo.gl/lBJYo
[14:53] <Riri> http://goo.gl/lBJYo
[15:00] <doko_> jdstrand, are you ok having ruby1.9 in main (in addition to 1.8)? ^^^
[15:00] <jdstrand> whoa
[15:00] <jdstrand> no way
[15:00] <jdstrand> unless things have changed a lot recently
[15:01] <jdstrand> aiui, 1.9 was basically a test bed is and constantly changing
[15:01] <jdstrand> very, very hard to support
[15:01] <doko_> jdstrand, see lucas plan above
[15:01] <jdstrand> if it has stabilized, then maybe
[15:01] <lucas> doko_: ah, then you probably have to include it in main given that gem2deb depends on both
[15:02] <doko_> jdstrand, please lets sort it out this week. so we don't merge packages, removing ruby1.9 support
[15:03] <jdstrand> lucas: has 1.9 stabilized?
[15:03] <jdstrand> lucas: keep in mind, my recollection may be quite old...
[15:04] <lucas> jdstrand: yes
[15:05] <lucas> jdstrand: in debian, we are considering switching to 1.9 as default for wheezy
[15:05] <jdstrand> so we are actually talking about ruby1.9.1
[15:06] <jdstrand> the problem is that supporting 2 rubies for 5 years is suboptimal
[15:08] <doko_> jdstrand, but iiuc, we would have to patch a lot of packages for precise, if we do not?
[15:08] <slangasek> cjwatson: yep, looks like a separate no-libidn pass is the way to go
[15:08] <jdstrand> doko_: I don't know, I just now am coming up to speed
[15:09] <jdstrand> doko_: on the other hand, it looks like 1.8.7 will only get upstream support unitl June 2013
[15:09] <jdstrand> http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
[15:09] <jdstrand> so upstream is recommending 1.9
[15:10] <doko_> jdstrand, right, but iiuc, gem2deb will build for both (and we'll have to have both in main), unless we commit to convert to 1.9, going ahead of Debian
[15:11] <jdstrand> looking at upstream and lucas' comments, I think ruby1.9.1 in main would be fine. I wonder if we can demote ruby1.8...
[15:11] <doko_> cjwatson, do you fix libgd2?
[15:11] <jdstrand> doko_: it might be worth helping them, as we will be stuck with 4 years of 1.8.7 support without upstream. last I looked at the codebases, they were radically different
[15:12] <jdstrand> again, that was a couple of years ago
[15:12] <doko_> lucas, do you stick to 1.9.1, or will there be minor updates?
[15:13] <jdstrand> well, that is jsut the package name
[15:13] <lucas> doko_: see package description:
[15:13] <lucas>  .
[15:13] <lucas>  In the name of this package, `1.9.1' indicates the Ruby library
[15:13] <lucas>  compatibility version. This package currently provides the `1.9.3'
[15:13] <lucas>  branch of Ruby, which is compatible with the `1.9.1' branch.
[15:13] <jdstrand> the actual upstream version is 1.9.3~rc1-1
[15:13] <doko_> ahh, ok
[15:13] <lucas> we are very likely to stick with 1.9.3 in wheezy, yes
[15:14] <jdstrand> I'm guessing that is because of the early 1.9 prerelease snapshots
[15:14] <lucas> there will be a few, bugfix-only updates
[15:14] <lucas> the stable branches of ruby tend to be maintained quite reasonably
=== smb` is now known as smb
[15:15] <jdstrand> that is consistent with my experience. last I looked at ruby1.9 (the source package) it had not yet stabilized
[15:15] <jdstrand> hence the initial reaction :)
[15:17] <jdstrand> doko_: we would probably want Daviey to weigh in on ruby1.8 demotion or ruby1.9 by default
[15:19] <hallyn> tyhicks, do you want to create a blueprint for ecryptfs?
[15:19] <kirkland> hallyn: i think he has one
[15:19] <hallyn> oh lemme search harder
[15:19] <tyhicks> hallyn: https://blueprints.launchpad.net/ubuntu/+spec/security-p-ecryptfs
[15:19] <hallyn> cool, thx
[15:21] <tyhicks> hallyn: np - let me know if you have other ideas we need to discuss
[15:23] <mvo> kelemengabor: its uploaded now, thanks again for the quick notification !
[15:23] <kelemengabor> yw :)
[15:25] <hallyn> tyhicks, nope, testing is on there, i'm good :)
[15:25] <doko_> jdstrand, Daviey sounds find, but lets sort out it this week
[15:25] <tyhicks> hallyn: despite it being at the bottom, it is one of the top items to discuss
[15:26] <hallyn> tyhicks, hopefully i'll be disciplined enough to review the emails from this cycle about it beforehand
[15:30] <cjwatson> doko_: I already did
[15:33] <doko_> cjwatson, ahh, I see. binaries not yet avail
[15:35] <cjwatson> doko_: should just have published but maybe not yet mirrored, except for powerpc which was stuck behind firefox/thunderbird builds last I looked
[15:35] <cjwatson> oh, powerpc has built too, so should be available in ~1hr
[15:35]  * cjwatson retries libgd-gd2-perl for giggles
[15:36] <pitti> oh, someone flushed the precise-changes@ queue?
[15:38] <cjwatson> we've been asking IS about that, maybe somebody processed it
[15:39] <cnd> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[15:39] <cnd> micahg, thanks :)
[15:40] <didrocks> cnd: what a commitment, a full day of piloting! :)
[15:40] <cnd> hah
[15:49] <ricotz> hello, is this a known debhelper problem "dpkg-shlibdeps: error: package. is not a valid version" on precise?
[15:53] <cjwatson> ricotz: if it is it is certainly not affecting all packages
[15:53] <cjwatson> ricotz: sounds more like a broken shlibs file to me
[15:57] <cjwatson> ricotz: I noticed that in cogl - is that what you're looking at?
[16:09] <ricotz> cjwatson, yes, and a custom cairo packages which uses a splitted symbols file too
[16:12] <cjwatson> ricotz: so I think this is probably junk in the shlibs file and that that would be a good place to start investigating; I can't reproduce this with a cogl/i386 build in pbuilder
[16:12] <cjwatson> ICBW of course but it doesn't look like a general debhelper problem at this point, to me
[16:12] <ricotz> https://launchpadlibrarian.net/82920262/buildlog_ubuntu-precise-amd64.cairo_1.11.3%2Bgit20111015.3813066f-0ubuntu1~12.04~ricotz0_FAILEDTOBUILD.txt.gz
[16:13] <ricotz> i havent built it locally yet, but this failed on i386 and amd64
[16:14] <cjwatson> ok, so build locally and then peer at the shlibs files; maybe also run with DH_VERBOSE=1
[16:14] <ricotz> cjwatson, alright, will do, thanks
=== dendrobates is now known as dendro-afk
[16:35] <Daviey> doko_ / jdstrand: I don't have a weighted opinion either way TBH (RE: ruby)
[16:35] <superm1> mvo, got some logs for the lightdm upgrade problem that keeps happening https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/876945
[16:35] <ubottu> Ubuntu bug 876945 in update-manager (Ubuntu) "Upgrade didn't properly set-up lightdm" [Undecided,Confirmed]
=== deryck is now known as deryck[lunch]
[16:45] <brendand> eh, why has unity stopped working after the most recent updates?
[16:45] <seb128> did it?
[16:45] <seb128> what is your .xsession-errors?
[16:46] <brendand> /usr/lib/nux/unity_support_test: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
[16:46] <brendand> looks suspicious
[16:47] <mvo> thanks superm1, I'm not sure I will manage tonight, but I put it on my list for tomorrow
=== tkamppeter_ is now known as tkamppeter
[16:48] <brendand> unity-2d-panel: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
[16:48] <brendand> seb128: also, though i've been trying both 3d and 2d
[16:49] <seb128> brendand, seems your libGL is screwed, do you use binary drivers?
[16:49] <seb128> brendand, dpkg -S libGL.so.1
[16:49] <brendand> seb128 - ah. i activated fglrx and then deactivated it.
[16:50] <superm1> thanks mvo
[16:50] <seb128> brendand, seems like it let you libGL alternative broken or something
[16:50] <slangasek> brendand: please file a bug against fglrx-installer then; it's not supposed to ever leave libGL.so.1 broken like that
[16:50] <mvo> thank you superm1
=== beuno is now known as beuno-lunch
[16:51] <brendand> seb128 - actually i deactivated it because my display wouldn't come back after suspend with it activated. i'll file the bug
[16:51] <seb128> brendand, did you use jockey to enable,disable it?
[16:52] <seb128> slangasek, bregma: bug #855943
[16:52] <ubottu> Launchpad bug 855943 in fglrx-installer (Ubuntu) "Installing then uninstalling FGLRX makes Oneiric's Unity unbootable" [Undecided,Confirmed] https://launchpad.net/bugs/855943
[16:52] <seb128> "known", I pointed it to tseliot before Oneiric released
[16:53] <seb128> but maybe it should get milestoned or assigned to somebody
[16:54] <maco> stgraber: http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2011-October/006721.html this was debian response to that
=== dendro-afk is now known as dendrobates
[16:56] <slangasek> seb128: yes, that surely should be a higher priority than 'undecided' :/
[16:56] <slangasek> seb128: triaged, thanks
[16:56] <seb128> slangasek, thanks
=== deryck[lunch] is now known as deryck
[17:37] <dobey> is there any policy documentation on how to split up gir1.2-foo packages from a single source? don't recall seeing anything in deb policy manual
[17:42] <luist> hey im getting this problem: http://pastie.org/2718936 on my chroot. im following this: https://help.ubuntu.com/community/LiveCDCustomizationFromScratch is that really a problem?
=== beuno-lunch is now known as beuno
[18:01] <ricotz> cjwatson, this debhelper problem is caused by "/var/lib/dpkg/info/libegl1-mesa:amd64.symbols", so it seems like debhelper changed its behaviour here
[18:01] <ricotz> libEGL.so.1 libegl1-mesa #MINVER# | libegl1-x11
[18:01] <ricotz>  # package.
[18:01] <ricotz>  _eglBindContext@Base 7.8.1
[18:03] <slangasek> no, debhelper doesn't interact with symbols files
[18:03] <slangasek> dpkg-shlibdeps / dpkg-gensymbols do all the work
[18:04] <ricotz> slangasek, ok, it looks like the "old" one left this comment part in the symbols file which looks like
[18:04] <ricotz> +libEGL.so.1 libegl1-mesa #MINVER# | libegl1-x11
[18:04] <ricotz> + # These are all internal symbols between libEGL and the
[18:04] <ricotz> + # drivers.  Handle the dependency explicitly in the driver
[18:04] <ricotz> + # package.
[18:04] <ricotz> + (regex)"^_egl.*@Base$" 7.8.1
[18:04] <slangasek> so it looks like a dpkg-shlibdeps behavior change; I can confirm that comment was present in /var/lib/dpkg/info/libegl1-mesa:amd64.symbols in oneiric, and we didn't have the build failure there
[18:05] <slangasek> is rebuilding libegl1 enough to fix the broken comment?
[18:05] <ricotz> slangasek, havent checked, i was looking at the cogl and my cairo failures which leads to this
[18:09] <cjwatson> I'm failing to find any relevant changes in dpkg
[18:11] <cjwatson> it seems to think comments must start at the beginning of a line ("#" not " #") in both oneiric and precise
[18:13] <slangasek> looks like it might be a difference in the packages actually being pulled in as build-dependencies?
[18:13] <slangasek> building cogl in oneiric doesn't use libegl1-mesa
[18:13] <ricotz> cjwatson, looks like it, but why are two lines stripped and one left in?
[18:13] <slangasek> so maybe libegl1-mesa is busted in oneiric but nothing uses it
[18:13] <ricotz> slangasek, the armel build does
[18:14] <slangasek> oh, that's going to be actual work to test
[18:14] <slangasek> alright
[18:14] <slangasek> go go gadget cross-compiler
[18:15] <ricotz> slangasek, you can try this too https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2004607/+listing-archive-extra
[18:15] <ricotz> which uses libegl on all archs
[18:16] <cjwatson> ricotz: I haven't parsed my way all the way through this code, but perhaps the shorter line with only one word in the comment looks enough like a legitimate symbol line that dpkg's parser retains it
[18:16] <ricotz> and went fine on oneiric
[18:17] <ricotz> cjwatson, could be, the other lines have more spaces
[18:19] <slangasek> pfffff, can't cross-compile cogl because of gir
[18:20] <slangasek> ok
[18:22] <zul> slangasek: is there a reason why we cant have samba 3.6.0 for percise
[18:23] <ricotz> slangasek, mesa build fails too on precise
[18:23] <slangasek> zul: I don't know; currently it's only in experimental, please don't merge it from there as the packaging is not current wrt various improvements in unstable
[18:23] <zul> slangasek: k
[18:24] <slangasek> zul: as for whether it's ready for prime time and should be included in precise, I can't say - I suggest posting to the mailing list (pkg-samba-maint@lists.alioth.debian.org) to find out what bubulle's planned timeline is for unstable
[18:24] <ricotz> slangasek, cjwatson so this is parsed as valid entry instead of being ignored
[18:25] <zul> slangasek: k i will
[18:25] <cjwatson> ricotz: regardless of parser bugs, the file is buggy
[18:25] <cjwatson> the leading space before # should be dropped
[18:25] <cjwatson> (though I can't say for sure that that will fix the bug)
[18:26] <slangasek> kees: are you planning to take care of the merges that you're TIL on, or would you like me to find someone else to do them?
[18:26] <ricotz> cjwatson, i already pinged RAOF and Sarvatt ^ and now again ;)
[18:26] <slangasek> kees: oh, pam is one of them, I guess I know someone who could do that merge ;P
[18:27] <slangasek> RAOF: say, what's the difference between a fake merge from experimental and a real one? (mesa)
[18:27] <slangasek> ricotz: since I have Debian XSF commit rights, I'll go ahead and commit the fix now to the Debian git
[18:28] <ricotz> slangasek, ok
[18:28] <cjwatson> slangasek: it does occur that the parser bug might misfire even without the leading space, so still worth testing ...
[18:29] <slangasek> cjwatson: yep, will do
[18:30] <kees> slangasek: please feel free to find other folks if I'm blocking. I probably won't have time for merges for a few weeks
[18:31] <slangasek> kees: ack - I don't know that anything's blocked currently, but I'd rather we not let things like sudo linger until FF :)
[18:32] <kees> hehe
[18:32] <slangasek> cjwatson: what do you think about changing MoM to spit out UNRELEASED as a changelog target instead of the current devel dist?
[18:34] <slangasek> cjwatson, ricotz: confirmed that egl1-using cairo package builds fine on oneiric in spite of this broken .symbols file comment, so something certainly seems to have changed in dpkg
[18:37]  * SpamapS got his askubuntu T-shirt today. :-D
[18:37] <SpamapS> jcastro: ^^ :-D
[18:38] <jcastro> Not me. :(
[18:38] <cjwatson> slangasek: makes sense; done (at least for future merges)
=== dendrobates is now known as dendro-afk
[18:38] <SpamapS> jcastro: sent priority mail, so may be stuck somewhere :p
[18:41] <slangasek> cjwatson: cool, thanks :)
[18:52] <ricotz> cjwatson, oh, did you fix it? where?
[18:53] <cjwatson> ricotz: no.  there were two overlapping conversations heree.
[18:53] <cjwatson> *here
[18:53] <ricotz> ah, i see
[19:01] <c2tarun> hi, my system froze few minutes ago, I have to power reboot, is there any way to know the reason by viewing log files/
[19:04] <cjwatson> I think on the whole working on a library transition with a half-day build queue is too frustrating and I should do something else for a while instead
[19:05] <highvoltage> I suggest some ice-cream, cjwatson.
[19:06] <cjwatson> ... but icecream isn't involved in this library transition - no, wait
[19:06] <nigelb> I as about to suggest alcohol, but I see the irony in suggesting icecream :)
[19:21] <stgraber> slangasek: for that ifupdown bug, I confirmed that it's a regression in the 0.7 series (reproduced on Debian using unstable and then installing the latest ifupdown from experimental). I'll file a bug and then see if I can maybe figure out the fix (I tend to get lost in ifupdown's code...)
[19:41] <slangasek> stgraber: oh, you found ifupdown's code to get lost in, did you ;)
=== kancerman_ is now known as kancerman
[19:41] <slangasek> would love to see ifupdown rewritten in straight C someday
=== akgraner` is now known as akgraner
=== yofel_ is now known as yofel
[19:57] <slangasek> cjwatson, ricotz: confirmed that installing dpkg-dev+libdpkg-perl from precise is enough to trigger this build failure with oneiric packages... so wherever that behavior change is, it's in dpkg somewhere
[21:26] <LoRez> where would I go to find a contractor to package something?
[21:27] <ScottK> Here is not a bad place perhaps.
[21:38] <LoRez> I need ftp://ftp.comtrol.com/dev_mstr/rts/drivers/linux/devicemaster-linux-4.22.tar.gz packaged up.  It's a kernel module and utilities.
[21:54] <LoRez> preferably for lucid
=== dendro-afk is now known as dendrobates
[22:25] <micahg> are there any plans for xz debs on images for P?
[22:26] <slangasek> what plans do you have in mind?  I believe we already went through several cycles ago and changed the compression type for all the low-hanging fruit
[22:31] <micahg> slangasek: oh?  I thought there were issues w/it for the live fs  I was thinking Firefox/Chromium since they're huge
[22:31] <slangasek> there are issues in that compressing .debs has no impact whatsoever on livefs size
[22:31] <cjwatson> micahg: you're welcome to use it for individual debs, as long as you Pre-Depends: dpkg (>= 1.15.6)
[22:32] <cjwatson> but as slangasek says, it won't affect the livefs
[22:33] <micahg> cjwatson: ok, it might be worthwhile for bandwidth issues though since we update these often, I'll make the changes if there are no objections. what about in a stable release?  would this be something we could switch safely
[22:33] <cjwatson> I can't advise making non-required changes in stable releases
[22:33] <micahg> ok, will ask pitti about it later
[22:34] <cjwatson> I mean that's a no vote (though not a veto) from me, not "no opinion"
[22:34] <cjwatson> it's definitely not possible for lucid
[22:34] <cjwatson> it didn't have a new enough dpkg
[22:34] <micahg> ah, ok, will discuss amongst my team then, yeah, not for lucid, but for everything later, I can at least do it for Precise though
[22:35] <cjwatson> yes
[22:35] <cjwatson> after precise we'll be able to drop the Pre-Depends
[22:36]  * micahg doesn't mind the Pre-Depends, these are Ubuntu only anyways
[22:39] <cjwatson> Unable to obtain lock  held by cjwatson@bazaar.launchpad.net on crowberry (process #20203), acquired 4041 hours, 14 minutes ago.
[22:39] <cjwatson> that might not be current any more
[22:39] <StevenK> cjwatson: bzr break-lock ?
[22:39] <cjwatson> yes I know
[22:39] <cjwatson> I just found the length of time amusing
[22:39] <StevenK> Hah, yes.
[22:40] <cjwatson> pretty much exactly a release cycle :)
[22:41] <slangasek> hah
[22:59] <penguin42> can a qt person look at bug 877791 please - multiple qt apps crashing under unity and someone has attached a one line fix; if the fix is right it would seem appropriate for an update (appmenu-qt)
[22:59] <ubottu> Launchpad bug 877791 in appmenu-qt (Ubuntu) "appmenu crashes on AppMenuPlatformMenuBar::setAltPressed" [Medium,Confirmed] https://launchpad.net/bugs/877791
[23:09] <SpamapS> pitti: when you're around.. I think its about time we wave bug 665185 through to lucid-updates. It hsa been in -proposed a long time, and was allowed in without a TEST CASE...
[23:09] <ubottu> Launchpad bug 665185 in sysvinit (Ubuntu Lucid) "/etc/init.d/sendsigs fails to kill some processes" [High,Fix committed] https://launchpad.net/bugs/665185
[23:09] <SpamapS> pitti: since its effectively a race condition that it is testing.. I think we should allow it through.. simple patch.. clearly needed to help keep peoples' data safe.