[07:14] <ion> Huh. Why is a beta version of Firefox 5 in natty-proposed?
[07:17] <micahg> ion: to build the new language packs and for extended user testing, natty getting Firefox 5 as a security update on June 21
[07:18] <micahg> it's more of an RC, but it's from the "beta" channel
[07:20] <ion> Upgrading Firefox 4 to Firefox 5 is guaranteed not to break anything? All extensions will be compatible?
[07:20] <micahg> ion: no, but we have no choice
[07:21] <lifeless> ion: upstream are not supporting 4
[07:21] <ion> How nice
[07:21] <lifeless> ion: and backporting security fixes from 5 to 4 is ... an interesting proposition
[07:21] <micahg> ion: last number I saw was 76% extension compatibility
[07:22] <micahg> Lucid and Maverick will be upgraded in the future as well, but for the moment 3.6 is supported
[09:34] <directhex> okay. i've isolated the thing that breaks mono on arm.
[09:34] <directhex> well, "isolated"
[09:34] <cjwatson_> slangasek: given that debconf switched to git somewhere in there, perhaps the best strategy is either something like rebase-foreign, or else stitch something together with import-dsc; I expect it will be somewhat manual in any event ...
[09:35] <jamespage> morning
[09:35] <directhex> gcc 4.6. specifically ubuntu's gcc-4.6
[09:36] <jamespage> please could a member of the archive admin team reject 'libpam4j' from the new upload queue - thanks
[09:40] <cjwatson_> jamespage: done
[09:40] <jamespage> cjwatson: thankyou
[09:51] <cjwatson> slangasek: I've applied the GtkAssistant patch to debconf upstream now, for the next release
[09:57] <directhex> cjwatson: afaik both gcc 4.5 and 4.6 on ubuntu should target the same thing, right? i see the same --with-arch, --with-mode and --with-fpu flags for both
[09:58] <cjwatson> I hadn't heard of target changes there, which doesn't necessarily mean there are none
[10:00] <directhex> i see a few removed flags as the only differences (--enable-gold --enable-ld=default --with-plugin-ld=ld.gold)
[10:05] <directhex> i want to be absolutely sure that i've done everything possible on my side - but i can't see much more I can do with my area of competence than say "an unmodified upstream tarball is okay with ubuntu gcc-4.5, and 4.6 on all arches except arm, so I think the issue is gcc-4.6 on arm"
[10:20] <cjwatson> directhex: have you tried building with -O0 on armel?
[10:21] <directhex> cjwatson, no. i'll do that next. see you in some hours!
[10:21] <cjwatson> directhex: if that works, bisect optimisation flags to try to narrow it down
[10:21] <cjwatson> similarly if you're using any -fthingy options then play with those
[10:21] <cjwatson> directhex: there's no way to do anything incrementally?
[10:22] <directhex> cjwatson, not in a way i trust. it's "successfully" building the runtime, but the built runtime is "bad" and won't execute code properly. and i don't want to only partially rebuild when i don't know which thing is choking
[10:32] <cjwatson> directhex: *nod*
[10:32] <cjwatson> frustrating.
[10:33] <directhex> when you've been at it since friday morning, mostly waiting for builds to finish, yeah
[10:33] <directhex> anyone got a super fast ARM board to mail me?
[12:48] <debfx> cjwatson: http://people.canonical.com/~ubuntu-archive/seeds/kubuntu.oneiric/ doesn't seem to get updated from the branch
[12:51] <cjwatson> hmm
[12:51] <Daviey> pitti: Am i correct in saying with http://bugs.debian.org/616318 , you were expecting the Depends to remove dpkg-dev (Ubuntu delta) and NOT the Build-Depends which the DM has done?
[12:55] <cjwatson> debfx: fixed, sorry about that - thanks for the report
[13:11] <directhex> cjwatson, the complete build isn't finished, but it looks like the -O0 build is okay
[13:12] <cjwatson> OK, so now you get to figure out which optimisation broke it :-/
[13:13] <directhex> is O1 worth trying? i know it's the same as O2 on some compilers, i don't remember if that includes gcc
[13:14] <cjwatson> -O1 is not the same as -O2 and is worth trying
[13:15] <cjwatson> gcc.info has the list of exactly which optimisations each one turns on
[13:18] <directhex> look like about 27 extra -ffoo flags from o0 to 01, and same from o1 to o2. so really, o1 is a bisect anyway :p
[13:24] <cjwatson> directhex: sure, it's just the first obvious-and-useful bisect
[13:24] <directhex> i just wish this process were faster :p
[13:53] <speakman> http://askubuntu.com/questions/120/how-do-i-avoid-the-s-to-skip-message-on-boot
[13:53] <speakman> Looks like nobootwait doesn't work
[14:50] <directhex> cjwatson, getting there. O1 seems fine.
[15:19] <pitti> jelmer: any SRU needs a corresponding bug to track, so subscribing ~u-sru to the bug will do
[15:20] <pitti> jelmer: u-sru does sponsor the odd upload, but it's not its primary role indeed
[15:20] <jelmer> pitti: ok
[15:20] <pitti> Daviey: correct; it doesn't matter as a build dependency
[15:20] <jelmer> pitti: Thanks, I'll link a bug
[15:50] <smoser> in a modified debian package, should Vcs-* be changed ? it seems there are a fair amount of different solutions
[15:53] <smoser> XS-Debian-Vcs-* , Xs-Vcs-*, XSBC-Original-Vcs-*
[15:53] <smoser> the '-Debian' seems to make the most sense to me, but google doesn't seem to find anything clear cut on what we should be putting
[16:02] <smoser> other than this thread: https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html but doesn't look like anything completely decided there.
[16:04] <cjwatson> smoser: we settled on XS-Debian-Vcs-*, but I don't have a reference for you
[16:05] <smoser> so should that always be changed if there is a change made ?
[16:10] <cjwatson> smoser: generally I think so, but it's not vital or anything
[16:53] <apw> does anyone have oneiric nerwork manager working with wifi ?
[16:53] <apw> and is the branding all sick or is something wrong with my install
[16:53] <jibel> a
[16:54] <jibel> apw, bug 796286
[16:54] <jibel> apw, it's private subscribing you
[16:54] <apw> jibel, thanks
[16:58] <apw> pitti, is the apport retracer working ok ?
[17:01] <apw> pitti, the bug above seems to be marked for retracing, but 22 hours has gone past ... hmm, suspect not so well
[17:27] <mterry> doko__, got a mir for you when you get a chance: bug 491644
[17:29] <mterry> kees, same for you -- I subscribed you to librsync in that bug  ^
[17:46] <micahg> mterry: kees is off this week
[18:03] <mterry> micahg, ah, thanks
[18:05] <directhex> cjwatson: bisecting is slow, but yielding results. it's one of these: -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fschedule-insns
[18:30]  * Daviey has come across 2 packages today where the only Ubuntu delta is dropping Depends on locales-all.. Why don't we have this?
[18:31] <Daviey> would it be cheaper to have a locales-all meta package to locales, than maintaining this?
[18:31] <slangasek> locales-all and locales aren't the same thing; locales-all is a package that contains pre-generated locales for all packages
[18:31] <slangasek> what packages have a dependency on this in Debian?
[18:32] <Daviey> slangasek, i just saw python-django... and there was another one i uploaded yesterday... lemme check
[18:32] <slangasek> a quick look at stable shows only openoffice.org-l10n packages, gforge-web-apache2, and libc6
[18:32] <slangasek> python-django> no earthly reason that should depend on locales-all in Debian either
[18:33] <slangasek> and I don't see that it *does* in unstable or stable
[18:35] <Daviey> slangasek, is your search returning build-depends aswell?
[18:35] <slangasek> oh, you didn't say build-depends ;)
[18:35] <Daviey> sorry
[18:36] <slangasek> locales-all as a metapackage depending on locales *definitely* wouldn't satisfy a build-dep
[18:36] <slangasek> packages that need locales at build time should really generate them themselves
[18:37] <slangasek> that's in both Debian and Ubuntu, I mean
[18:39] <Daviey> Hmm
[18:39]  * Daviey is looking for the other example
[18:44] <Daviey> Gah, can't find it - i was certain i saw another.
[19:11] <slangasek> Daviey: well, python-django in unstable seems to have added a build-dep alternative on the en langpack, so it looks like that delta could be dropped now
[19:12] <slangasek> also, I've just looked up the correct env vars and commandlines to use a locale from a local directory, so I'll probably submit that as a patch to python-django and blog the recipe for later use
[19:13] <Daviey> slangasek, I'll watch out for that, thanks.. Kinda frustrated i can't find the other package i saw it.
[19:17] <slangasek> Daviey: libapache2-mod-perl2? php5?
[19:17] <Daviey> slangasek, was just looking at php5 :)
[19:17] <Daviey> locales-all. -- Now has alternative language-pack-de for use in tests. <--
[19:19] <Daviey> but yes, the one i was thinking of was libapache2-mod-perl2
[19:19] <Daviey> thanks
[19:28] <smoser> Daviey, slangasek i had tried building python-django, tihnking it might just build
[19:28] <smoser> but http://paste.ubuntu.com/626043/
[19:44] <Daviey> slangasek: So, it seems the delta with python-django was never needed.. Seems that it was really an issue with sbuild's dep handling.
[19:44] <slangasek> Daviey: ah, heh
[19:44] <Daviey> (works in pbuilder, fails in smoser's sbuild)
[19:44] <slangasek> right
[19:45] <Daviey> guesing, http://bugs.debian.org/403246
[19:47] <micahg> that's a config option for sbuild IIRC, works fine in LP
[19:47] <micahg> as long as it's not a versioned build-dep first
[19:48] <Daviey> bah, it shouldn't matter
[19:49] <micahg> Daviey: in Debian, only the first alternative is used, so it makes sense as a default
[19:49] <Daviey> micahg: you are saying that it is OK for this to FTBFS, Build-Depend: foo (>=X) | bar ?
[19:50] <micahg> Daviey: no, that's due to LP using an old hacked version of sbuild IIRC, I have a bug filed for it
[19:50] <Daviey> ah, i see
[19:50] <slangasek> bug filed for what?
[19:50] <micahg> slangasek: versioned alternative build-deps failing
[19:50] <Daviey> against soyuz i assumed.
[19:50] <slangasek> oh, ok
[19:51] <micahg> bug 594916
[19:52] <Daviey> oh joy.
[19:52] <smoser> but this is not versioned.
[19:52] <smoser> so we should be fine on this as a sync at least.
[19:52] <micahg> smoser: so your local sbuild has a config option for that
[19:53] <Daviey> smoser: bah, we were quite happy spinning off on a tangent then.
[19:53] <Daviey> smoser: Yeah, switch to a sync please :)
[19:53] <smoser> micahg, oh? well i just built sbuild from oneiric for my natty system
[19:53] <smoser> so that will "just work" also i would hope
[19:53] <Daviey> smoser: lets see :)
[19:54] <smoser> although it failed, wanting me to run : sbuild-update --keygen
[19:54] <smoser> which is still waiting on some entropy
[19:54] <micahg> smoser: look for this line in /etc/sbuild/sbuild.conf: #$check_depends_algorithm = "first-only";
[19:54] <Daviey> i'm gonna dput the debian package to a PPA just to satisfy my curiosity, as i'm not sure i can wait for the sync. :)
[19:55] <smoser> so that needs to be 'alternatives', eh?
[19:56] <smoser> so is that bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403246 not valid ?
[19:56] <micahg> smoser: it is fixed, just not the default :)
[19:57] <smoser> ah. but it was fixed in 0.62, which was still > my natty version
[20:03] <Daviey> smoser: we'll see what happens: https://launchpad.net/~davewalker/+archive/junk/+sourcepub/1772041/+listing-archive-extra
[20:04] <smoser> i need 279 bytes of freaking entropy
[20:04] <smoser> oln my headless sytem
[20:04] <smoser> damamnana
[20:04] <Daviey> smoser: you need an entropy key :)
[20:05] <smoser> jdjdjdjdksadf
[20:05] <smoser> salkfirirmenw
[20:06] <sbeattie> smoser: does it have a working tpm chip?
[20:06] <smoser> wonder why i never had to do this before
[20:06] <smoser> probably not, sbeattie
[20:06]  * smoser apologizses for random keys to channel
[20:08] <mdeslaur> hehehe
[20:08] <nigelb> smoser: cat on the keyboard? :)
[20:08] <mdeslaur> smoser: those are the exact same random keys I use!!
[20:08] <smoser> yeah, every one can now guess my keys.
[20:08] <smoser> darn.
[20:09] <smoser> will start again
[20:11] <Daviey> smoser: if you still can't find enough entropy, let me know the details you want and i'll generate it here and email it across.
[20:11] <Daviey> (Don't worry, i'll encrypt the private key before emailing it!)
[20:17] <smoser> well, i did get enough.
[20:17] <smoser> i did the same thign on my laptop here.
[20:17] <smoser> but then ran into another issue... that sbuild doesn't seem to happy on natty.
[20:56] <jono> is ldm safe to use in Oneiric yet?
[21:02] <stgraber> jono: ldm has been perfectly usable for years ;) (ldm == LTSP display manager)
[21:02] <jono> stgraber, :-)
[21:02] <jono> LightDM :-)
[21:02] <stgraber> jono: now, for lightdm, I'm using it and it "works for me"
[21:02] <jono> stgraber, how do I enable it instead of GDM?
[21:02] <stgraber> jono: in my case I just tried it with: sudo stop gdm && sudo start lightdm
[21:03] <saamm> hello, what does mouse polling rate = 0 mean in Ubuntu?
[21:03] <stgraber> jono: not sure how to change the default though (but I got prompted when installing lightdm, so it's probably some debconf magic)
[21:04] <jono> thanks stgraber
[21:04] <LaserJock> would a dpkg-reconfigure gdm work?
[21:04] <stgraber> I'd think so, yes
[21:04] <stgraber> jono: np
[21:12] <saamm> is there a wiki page on mouse polling rate?
[22:46] <lynxman> ping slangasek
[22:47] <slangasek> lynxman: hi there
[22:47] <lynxman> slangasek: hi o/
[22:47] <slangasek> I assume you got my email :)
[22:47] <lynxman> slangasek: I've just got your email yeah :)
[22:48] <lynxman> slangasek: would it be okay if I fix all these issues and upload a new version tomorrow?
[22:48] <slangasek> lynxman: certainly
[22:48] <lynxman> slangasek: excellent, thank you very much for the email :)
[22:48] <slangasek> lynxman: when you've done so, please ping me to have another look at the package, so it doesn't just end up at the end of the queue for whichever archive admin next processes NEW
[22:49] <lynxman> slangasek: I'll do so, thanks :)
[22:49] <slangasek> lynxman: do you agree that it's ok to combine these plugins into a smaller number of packages, or are there reasons that we want one binary package per plugin?
[22:50] <slangasek> I'm assuming it's possible to enable/disable plugins at runtime using a config file
[22:50] <lynxman> slangasek: there's architectural reasons for it
[22:50] <lynxman> slangasek: exactly!
[22:50] <lynxman> slangasek: and each plugin has its own set of dependencies
[22:50] <slangasek> ok
[22:50] <slangasek> well, most of the plugins don't have interesting dependencies
[22:50] <slangasek> half of them depend on puppet and only puppet
[22:50] <lynxman> slangasek: hm yeah, I just copycatted the way they've done it upstream
[22:50] <lynxman> slangasek: I have direct contact with the author though, and he's in UK time
[22:51] <lynxman> slangasek: so I'll ping him tomorrow morning and see what he says about the suggestion as well, it sounds more than reasonable
[22:51] <slangasek> ok, let me know what you guys decide either way
[22:59] <lynxman> slangasek: will let you know as soon as I know as well ;)
[23:23] <slangasek> Daviey: Debian bug #630421, fwiw
[23:24] <directhex> -frerun-cse-after-loop
[23:25] <cjwatson> pitti: so, live-build seems to have saved a couple of megabytes, but it's obscured by (a) libegl1-mesa (b) python3.2 and (c) mono 2.10 (as warned by directhex) having eaten a chunk of space between them
[23:26] <cjwatson> pitti: unfortunately cdimage was ENOSPC for a couple of days so comparison data is hard to come by
[23:26] <directhex> once i've beaten this armel thing i can focus on getting mono apps and their disk usage back under control
[23:27] <directhex> this is my confirmation build right now as to the problem flag
[23:27] <cjwatson> pitti: you can look at successive livefs builds on http://cardamom.buildd/~buildd/LiveCD/oneiric/ubuntu/ from the DC - 20110613.2 is the first live-build one there
[23:41] <broder> cjwatson: +1, congrats, etc :)
[23:51] <Daviey> slangasek: looks elegant!
[23:55] <RAOF> What's pulling libegl1-mesa onto the CD?
[23:56] <RAOF> Ah, cairo.
[23:56] <slangasek> ah, python3 has found its way on now, has it?
[23:56] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/rdepends/ALL/libegl1-mesa
[23:56] <bryce> RAOF, cairo??
[23:56] <slangasek> cairo?  sounds like a bug then :)
[23:57] <cjwatson> slangasek: lsb-release
[23:57] <bryce> RAOF, leftover from wayland?  (*small tear*)
[23:57] <slangasek> cjwatson: heh, ok
[23:57] <RAOF> slangasek, bryce: I don't think it's a bug; the ARM guys were porting the cairo gl backend to autoselected gl/egl.  If that's landed then I'd expect a dep on both.
[23:58] <slangasek> RAOF: "a dep on both" - I would certainly consider that a bug, intended or not
[23:58] <slangasek> I would expect an egl dep on armel, and a gl dep elsewhere
[23:58] <RAOF> Oh.  Ra raw.  Hello memory usage bugs on nvidia!
[23:58] <slangasek> or at most, an ORed dep satisfied by the sensible alternative on each arch
[23:59] <RAOF> slangasek: That would require cairo backends to be loadable; they aren't.
[23:59] <slangasek> no, it would just require us to build for the sensible backend on each arch :)
[23:59] <slangasek> who needs an egl backend on x86?