[04:16] <pitti> Good morning
[04:16] <pitti> tkamppeter: it's worth a try now, anyway
[04:16] <Nafai> good morning pitti! :)
[05:40] <didrocks> good morning
[06:22] <tkamppeter> pitti, what do you mean with "It is worth a try now"?
[06:22] <pitti> tkamppeter: reuploading your crash report
[06:23] <tkamppeter> pitti, will try.
[06:25] <tkamppeter> pitti, bug 856139, let's see ...
[06:47] <pitti> tkamppeter: meh -- seems it just doesn't like that crash; I don't think it's the oboslete dbgsyms, seems the memory is just too disrupted
[06:47] <pitti> tkamppeter: do you get anything sensible in gdb?
[06:54] <tkamppeter> pitti, I did not try gdb, how do I proceed for that, especially as I cannot reliably reproduce the problem.
[06:54] <pitti> tkamppeter: you can install apport-retrace, and try
[06:54] <poolie> hi pitti
[06:54] <pitti> apport-retrace -S system -g -v /var/crash/yourcrashfile.crash
[06:54] <pitti> hey poolie
[06:55] <pitti> tkamppeter: that'll build a temp dir with all debug symbols it can get, and put you into a gdb session with that crash
[06:55] <pitti> tkamppeter: so you can do "bt full", poke around in the frames, etc.
[07:06] <dholbach> good morning
[07:13] <robert_ancell> mr_pouit, hey, did you get that lightdm alternatives patch to work?
[07:43] <OdyX> tkamppeter: oh, right.
[08:06] <doko_> cyphermox, ping
[08:11] <ricotz> doko_, the new clutter/cogl upload includes the armhf bits which will hopefully work in 12.04
[09:00] <tkamppeter> pitti, it seems that apport-retrace has a bug, see http://paste.ubuntu.com/695005/
[09:14] <Sweetshark> pitti: fyi: I have a 3.4.3-1ubuntu3 locked and loaded -- it compiled locally and is currently testcompiling on armel -- it fixes bug 835153, bug 835663, bug 779798, bug 841562 and bug 850372. When would you be allowed to upload that for final?
[09:18] <Sweetshark> eh, thats bug 835662 (not 835663)
[09:27] <tkamppeter> pitti, see bug 856216 for my experience with apport-retracer.
[09:35] <pitti> Sweetshark: we can upload it right now, i'll be caught in unapproved
[09:36] <pitti> tkamppeter: will look in a bit, still doing release-y stuff
[09:37] <pitti> tkamppeter: "No keyring installed", uh
[09:38] <pitti> tkamppeter: you don't need root there, btw; all user stuff
[09:38] <pitti> tkamppeter: can you please add the output of "apt-key list" to the bug?
[09:39] <tkamppeter> pitti, which keyring does it need and how do I get such a keyring?
[09:39] <pitti> you knock on elmo's door with some chocolate and ask nicely
[09:39] <pitti> no, it should be there already
[09:40] <pitti> tkamppeter: it complained about the standard ubuntu archive one
[09:40] <pitti> tkamppeter: I'll try to reproduce this, but I need the apt-key output
[09:40] <tkamppeter> pitti, done.
[09:43] <pitti> tkamppeter: do you have anything in /etc/apt/trusted.gpg.d/ ?
[09:44] <tkamppeter> pitti, crash file attached.
[09:46] <tkamppeter> pitti, yes, see bug
[09:58] <pitti> tkamppeter: can you attach /etc/apt/trusted.gpg.d/jockey-drivers.gpg to the bug? just to ensure that I have the same files?
[09:58] <pitti> tkamppeter: (it's nothing secret, just the public GPG keys from epson, etc.)
[10:05] <tkamppeter> pitti, attached.
[10:48] <tkamppeter> pitti, can you have a look at bug 856274? It seems that it has a problem with its i386 version.
[10:50] <pitti> tkamppeter: seems like mirror lag
[10:51] <pitti> tkamppeter: followed up
[10:57] <pitti> tkamppeter: hm, still can't reproduce that apport-retrace bug
[10:58] <pitti> tkamppeter: if you do a normal "sudo apt-get update", do you see similar GPG errors?
[11:02] <pitti> tkamppeter: anyway, as for the actual crash, I think there's a bug in python-apt or in apport-retrace, it doesn't seem to install all debug symbols that it downloaded
[11:02]  * pitti investigates tthis
[11:04] <pitti> ah, no, it's there, I just mislooked
[11:05] <pitti> tkamppeter: oooh, I know
[11:05] <pitti> tkamppeter: cups-dbg only has debug symbols for libcups2, nothing else; in particular, not for /usr/sbin/cupsd
[11:14] <pitti> it seems the upstream build system already strips the daemon
[11:17] <tkamppeter> pitti, perhaps we should patch the build system for Oneiric so that it does not strip any executable or library from CUPS, so that we can investigate crashes. Can you look into this?
[11:18] <pitti> yeah, usually the build system shoudln't do this, especially not if you build with -g -O2
[11:18] <tkamppeter> pitti, if I run "apt-get update" manually I do not get any GPG errors, only a not available http://ftp.freestandards.org/.
[11:19] <pitti> tkamppeter: can you reproduce that crash?
[11:19] <pitti> tkamppeter: I have rebuilt cups with debugging symbols now, but as the core dump is from a different binary, it doesn't match any more
[11:19] <tkamppeter> pitti, no. I get it here and there when I create CUPS queues.
[11:20] <pitti> tkamppeter: so, I'm afraid this .crash file is useless :(
[11:20] <pitti> tkamppeter: I'll look into fixing cups-dbg
[11:21] <tkamppeter> pitti, AFAIR it happens preferably if creating queues with the dnssd backend pointing to CUPS queues on other servers.
[11:21] <pitti> without my "sudo ln -s /bin/true  /usr/bin/strip" hack, that is :)
[11:23] <tkamppeter> pitti, when you have the fixed package up, with debug symbols for all executables and libs of CUPS, please tell me, then I will update and try to get the crash again by quickly creating many print queues.
[11:23] <pitti> tkamppeter: test build running
[11:24] <pitti> tkamppeter: do you have cups-dbg installed? If so, even the locally created StackTrace in the .crash file should be useful
[11:25] <apw> slangasek, when you say brief clear to black is that literally just before plymouth, and does the backlight turn off in teh gap, ie. could it be a mode switch?
[11:26] <pitti> tkamppeter: that also explains why we don't have any -dbgsym packages
[11:27] <tkamppeter> pitti, I have it installed, but apport-retracer still crashes for me.
[11:28] <pitti> tkamppeter: for that one, perhaps you can tar up /etc/apt/ and attach it? I'll try to replace mine with your's
[11:29] <pitti> mvo: do you have an idea what could be wrong in bug 856216?
[11:29] <pitti> mvo: apt-get update doesn't complain, and I installed the very same /etc/apt/trusted.gpg.d/jockey-thing as Till has, but I don't get the error
[11:30] <pitti> tkamppeter: cups-dbg fix pushed to bzr
[11:31] <pitti> tkamppeter: if you install cups-dbg, you won't actually need apport-retrace; just say "report" to the crash report, and then cancel when it asks you to upload to launchpad, then the .crash file will have the stack trace
[11:31] <tkamppeter> pitti, /etc/apt attached.
[11:32] <mvo> pitti: you modify dir::etc::trusted where it should be trustedparts maybe? check apt-config dump|grep trusted
[11:32] <tkamppeter> pitti, then it has it already, as it is from the report.
[11:32] <mvo> pitti: just a wild guess without having looked at this in more detail though
[11:33] <pitti> mvo: actually not, I just set RootDir
[11:33] <pitti>         apt.apt_pkg.config.set('RootDir', apt_root)
[11:33] <pitti>         apt.apt_pkg.config.set('Debug::NoLocking', 'true')
[11:33] <pitti>         apt.apt_pkg.config.clear('APT::Update::Post-Invoke-Success')
[11:33] <pitti> mvo: ^ that's all it does
[11:33] <pitti> mvo: but if it was a general bug, I should get it, too
[11:33] <pitti> mvo: something on Till's system is different than mine
[11:33] <mvo> pitti: ok, then I need to look a bit close, I'm in a call now, I can check after that. a permissions problem is ruled out as well? gpg is pretty picky here sometimes
[11:33] <pitti> anyway, post-lunch problem, bbl
[11:34] <pitti> mvo: thanks; I'll poke this some more
[11:35] <tkamppeter> pitti, http://paste.ubuntu.com/695060/
[12:13] <pitti> tkamppeter: "(no debugging symbols found)"
[12:13] <pitti> tkamppeter: is that with the current bzr packages?
[12:14] <pitti> tkamppeter: when I do "gdb /usr/sbin/cupsd", I get (no debugging symbols found)"; but after installing the locally built cups-dbg, I get "Reading symbols from /usr/sbin/cupsd...Reading symbols from /usr/lib/debug/usr/sbin/cupsd...done."
[12:18] <doko_> pitti, seb128 please have a look at bug 831143, the package doesn't seem to work at all, but is a dependency of ephiphany-browser
[12:31] <tkamppeter> pitti, the paste was of before today's BZR, so still without your cups-dbg fix.
[12:31] <pitti> ah
[12:48] <tkamppeter> pitti, building CUPS from BZR ...
[12:54] <cyphermox> doko_: pong
[12:56] <tkamppeter> pitti, installed the new CUPS, now I must get the bug triggered again ...
[12:57] <doko_> cyphermox, looking at the wireless-regdb ftbfs, wondering which package in Ubuntu does have this information?
[12:59] <cyphermox> doko_: crda
[12:59] <cyphermox> afaik it should be the only one
[13:00] <cyphermox> doko_: actually, I mean crda is, I think, the only package to use this
[13:01] <doko_> cyphermox, well, wireless-regdb was never built
[13:02] <doko_> so we maybe should remove these two packages
[13:02] <cyphermox> oh, yeah probably
[13:02] <cyphermox> weird, because I could have sworn we always did have a package to do this
[13:05] <cyphermox> doko_: ok, found what I was looking for, I was thinking of iw
[13:06] <cyphermox> so yeah, I do agree these packages could be removed
[13:06] <cyphermox> shoudln't it be easy to just not sign the reg data?
[13:07] <doko_> cyphermox, please go ahead and upload a fix
[13:07] <cyphermox> doko_: ok I'll have a look
[13:17] <dobey> do packages seeded for default install/CD *have* to be in something else's Depends/Recommends that's already there?
[13:18] <cjwatson> I don't think you mean the same thing by the term "seeded" as I do
[13:18] <cjwatson> can you rephrase your question?
[13:19] <cjwatson> (I use "seeded" to mean "explicitly added to a seed as opposed to pulled in purely by dependencies")
[13:20] <cyphermox> doko_: I'll need sponsoring shortly
[13:21] <dobey> cjwatson: oh; typically whwenever we wanted something on CD, we always got the "something needs to Depends/Recommends it"
[13:22] <dobey> cjwatson: perhaps that created some confusion :)
[13:23] <cjwatson> dobey: in order for something to be on the CD, it must either be explicitly listed in a seed, or listed in Depends/Recommends of something that's already there
[13:23] <cjwatson> (listing it in (e.g.) the desktop seed will cause it eventually to be depended upon by ubuntu-desktop)
[13:23] <dobey> ok
[13:24] <cjwatson> the rule of thumb is that you explicitly seed things that are top-level requirements
[13:24] <Chipzz> cjwatson: would it be incorrect to say that to have stuff included on the CD, you have dependency-trees, and the seeds are the roots of those that pull in all other dependencies?
[13:24] <cjwatson> Chipzz: that's roughly correct
[13:24] <dobey> and eww; but i always end up uninstalling ubuntu-desktop anyway, so i can uninstall things it depends on
[13:24] <cjwatson> dobey: that's orthogonal
[13:24] <cjwatson> dobey: and in any case there is a syntax for causing ubuntu-desktop to only Recommends something
[13:25] <cjwatson> if it's not core desktop infrastructure, it should typically be Recommends
[13:25] <Chipzz> cjwatson: are seeds always meta-packages?
[13:25] <dobey> ok
[13:26] <cjwatson> Chipzz: no
[13:26] <cjwatson> for example the ship seed (which defines the set of packages added to the pool on the alternate CD but not installed by default) is not a metapackage
[13:27] <cjwatson> or rather is not used to generate a metapackage
[13:27] <Laney> recommends> I wish :-)
[13:33] <cyphermox> doko_: well, forget this, crda is not installable, it tries to install /sbin/crda which is already provided by wireless-crda (which is required by the kernel)
[13:35] <doko_> apw, ogasawara: any idea why crda cannot be used?
[13:36] <apw> doko_, sounds like something rtg would be most familiar with
[13:36] <cyphermox> oh fun, it's just a duplicate package
[13:36] <apw> cyphermox, could well be
[13:36] <cyphermox> I'm trying to figure out which is the latest version
[13:37] <apw> i suspect we added wireless-crda, as we had kernels requiring it before debian, so we might be able to merge them.  rtg was point man on crda so i'd recommend bring it to his attention
[13:38] <ScottK> mvo: I'm just upgrading my test server via ssh and I noticed that the dialogue around the alternate sshd is much improved (particularly around firewalls).  Thanks.
[13:39] <mvo> ScottK: great, thanks!
[13:40] <apw> cyphermox, doko_, ok tgardner is looking into it
[13:41] <cyphermox> ok
[13:43] <apw> cyphermox, when was crda last sync'd and how would if find out the real debian version now
[13:44] <cjwatson> https://launchpad.net/ubuntu/+source/crda/+publishinghistory  http://packages.qa.debian.org/crda
[13:44] <doko_> apw, http://packages.qa.debian.org/c/crda.html
[13:44] <cyphermox> apw: crda was probably auto-imported
[13:44] <cyphermox> I doubt anyone touched it :)
[13:44] <cjwatson> we're in sync with Debian
[13:44] <apw> then i suspect its pretty out of date.  the DB it contains is updated fairly often
[13:45] <cyphermox> apw: then you mean wireless-regdb and the database from the wireless-crda package, those are in sync
[13:45] <doko_> apw, the db is packaged in wireless-regdb
[13:45] <cyphermox> it's both 2011-04-28, the debian package adds an EU domain
[13:46] <apw> ahh ok
[13:46] <cyphermox> your package appears to only have just a bit of extra code to crda to have it work with libnl3
[13:47] <apw> cyphermox, then it osunds like potential for a merge ...
[13:50] <tgardner> cjwatson, given that wireless-crda is in the desktop seed, do you really want to change that right now ?
[13:51] <tgardner> I suggest we change to crda+wireless-regdb during the P cycle.
[13:52] <doko_> nobody said right now. seen while cleaning up the archive. it's fine if this is done for P
[13:52] <tgardner> doko_, works for me
[13:52] <tgardner> I'll git it on my todo list for when P opens
[13:52] <cyphermox> yeah, I think we should probably do this in P
[13:53] <tgardner> I'll start a bug so tha it doesn't get forgotten
[13:57] <tgardner> skaet, sure would be handy to be able to specify milestones for the P series already. do we have to wait until the P archive is opened ?
[13:59] <ScottK> tgardner: You can.
[13:59] <ScottK> (IIRC)
[14:00] <skaet> tgardner,  we need a name for p-series first before the milestones can get populated.
[14:00] <ScottK> Ah, right - milestones, not series.
[14:00] <ScottK> skaet: It would also be nice to have a name so we can update development tools in oneiric to know what to call P.
[14:01] <skaet> ScottK,  agreed.  absence of a name is starting to get in the way. :P
[14:05] <tkamppeter> pitti, I succeeded the stacktrace now, with CUPS locally built from BZR and doing ~60 queue addition/removal operations, and on one removal it actually crashed. Will paste the stacktrace into the bug.
[14:06] <pitti> tkamppeter: ah, great
[14:07] <cjwatson> tgardner: yeah, P is fine
[14:07] <tgardner> cjwatson, ack
[14:13] <tkamppeter> pitti, bug 855445
[14:19] <pitti> tkamppeter: ah, that looks a lot more useful
[14:21] <ScottK> mvo: As I mentioned, I just upgraded my test server to oneiric.  It appears that I've no packages left that require python-central, but it wasn't removed on upgrade.  Is that something you could check for?  Would you like a bug about this?
[14:25] <mvo> ScottK: that is interessting, yes, a bug would be nice
[14:25] <ScottK> OK.
[14:28] <ScottK> mvo: Bug 856458
[14:29] <mvo> thanks scottk!
[14:54] <rbasak> hey cyphermox, sorry I didn't understand https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/856209/comments/3 at all. Which same default route, and what do I point to the same device with link-local?
[14:55] <cyphermox> rbasak: ah, I mean, could you try with the link-local address to your router
[14:55] <cyphermox> here I get a standard global ipv6 address from dhcp, and my defualt route is automatically set properly by NM, to the link-local address of the router
[14:57] <rbasak> Ah, so you want me to see what happens if I specify the link-local router address as the gateway in the settings?
[15:03] <doko_> plars, pitti: please could you have a look at bug 756043 ?
[15:03] <pitti> doko_: yeah, can do
[15:04] <plars> doko_: I haven't looked at it in a while, but I know there's a new upstream version
[15:05] <cyphermox> rbasak: yup
[15:08] <doko_> yeah for configure modularization ...
[15:09] <doko_> dnl insert here your program name and version number
[15:09] <doko_> AC_PROG_CC
[15:09] <doko_> KDE_DO_IT_ALL(phaseshift,0.4)
[15:14] <slangasek> apw: I'm not sure if the backlight turns off; I get different behavior based on whether I have an external monitor plugged in or not, in one of these cases I briefly get a cursor and in the other I don't.  (I think the cursor is with the external monitor plugged in.)
[15:19] <rbasak> cyphermox: didn't work; I've commented in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/856209/comments/4
[15:21] <Laibsch> I have added http://paste.debian.net/131459/ to my pbuilderrc s suggested in http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#altcompiler to build with gcc 4.4 (4.6 has a bug on my CPU), but logging in to the pbuilder and doing "gcc --version" still show 4.6.1.  What's wrong?
[15:22] <seb128> mvo, is /usr/share/update-notifier/notify-reboot-required still used nowadays?
[15:22] <mvo> seb128: yes
[15:22] <seb128> it seems to do nothing there
[15:22] <seb128> like I did sudo /usr/share/update-notifier/notify-reboot-required
[15:22] <seb128> it created the files in /var/run
[15:23] <seb128> but neither update-manager nor the indicator nor anything says I need to restart
[15:24] <cyphermox> rbasak: ok, so there's really something very broken there, I'll see what I can make with this
[15:25] <rbasak> OK thanks
[15:26] <mvo> seb128: right, you need to touch /var/lib/update-notifier/dpkg-was-run as well, this is done automatically by apt after it ran dpkg
[15:26] <seb128> mvo, thanks
[15:30] <mvo> yw
[15:36] <apw> slangasek, i guess i'd like to see it boot in total.  might you be able to video it on your phone or something
[15:37] <slangasek> apw: ok, will try to do that later today.  First I'm trying to see if I can reproduce it on my old T60, since that would give me more flexibility to play
[15:38] <apw> slangasek, if you arn't using crypto, installing and removing those tools moves the mode switch about in the boot and is a good way to know if it is the modeset
[15:38] <slangasek> apw: I am using crypto ;)
[15:38] <apw> damn
[15:38] <slangasek> part of why I want to reproduce it on another box first
[15:38] <slangasek> though I do have an unencrypted VG on here partly for just this sort of thing, so I can install to that if needed for testing
[16:05] <slangasek> mdeslaur: bug #856534 looks like something we should get fixed for release; do you have interest/time to work on this?
[16:09] <mdeslaur> slangasek: I'll take a look, thanks
[16:34] <pitti> doko_: moserial uploaded
[16:34] <pitti> plars: ^ FYI
[16:34] <plars> pitti: awesome, you rock!
[16:35] <plars> pitti: according to comments from the author, that one should work better with current vala versions
[16:35] <pitti> yep, it works fine with 0.14
[16:35] <pitti> 2.32 didn't work either
[16:35] <pitti> and 3.0 makes more sense in oneiric anyway
[16:40] <doko_> lucas, is libdb-ruby worth fixing, or better just remove it?
[16:59] <pitti> kees, mdz, cjwatson: oh, we have TB meeting today; apparently no selected chair, but not much of an agenda anyway
[17:00] <mdz> pitti, indeed
[17:02] <cjwatson> oh, hmm, it's inconvenient for me this week - my brainstorm update is that a couple of people have responded but so far the response rate is not great; I'll start harassing people soon
[17:02] <cjwatson> I'll try to attend but possibly only by IRC-from-phone
[17:06] <chmrr> I'm one of the upstream maintainers of https://launchpad.net/rt/ -- https://launchpad.net/rt/+packages shows that request-tracker3.8 packages list rt/4.0 as upstream, instead of rt/3.8  What's the right way to fix this on launchpad, as I don't seem to have rights to change them myself?
[17:07] <cjwatson> it'd be best to ask #launchpad
[17:07] <chmrr> Will do; thanks!
[17:08] <cjwatson> oh, that interacts with an Ubuntu package, hmm
[17:08] <cjwatson> let me see
[17:08] <Laney> I see remove/link buttons, don't know what gave me permissions there though
[17:08] <cjwatson> chmrr: I've fixed it for you
[17:08] <chmrr> Thanks!
[17:08] <cjwatson> I guess I need to fix natty/maverick too ...
[17:09] <cjwatson> ignore the "Bilimbi Test" one, that's an LP test of derived distributions
[17:09] <chmrr> Yeah, I was wondering what was up with that
[17:10] <cjwatson> the Ubuntu ones should all be fixed now
[17:10] <cjwatson> Laney: upload privileges to the package
[17:11] <Laney> thought as much
[17:11] <cjwatson> (at least, I expect so)
[17:11] <chmrr> lucid's request-tracker3.8 reports it's against master, which is also wrong
[17:12] <cjwatson> OK, I've made that 3.8 too
[17:12] <chmrr> Thanks!
[17:12] <kees> pitti: cool, I'm around
[17:59] <stgraber> @pilot in
[17:59] <stgraber> infinity: still piloting?
[18:01] <infinity> stgraber: Oh, no, just retarded.
[18:01] <infinity> @pilot out
[18:43] <slangasek> mterry: bug #854202> who did you hear from that we're not dropping these packages from the CD?  I expect that's correct, but ubuntuone-couch is currently out of main and has other dependencies, so I want to be sure to follow up with the primary source before simply promoting the packages
[18:44] <mterry> slangasek, from pitti and dobey.  It was only dropped from main because deja-dup dropped the recommends recently
[18:44] <Laney> slangasek: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/856405
[18:45] <slangasek> mterry: ok; is that true of python-mocker as well?
[18:45] <mterry> slangasek, I don't know about mocker
[18:45] <slangasek> mterry: is there a channel log for this that I can peruse to my satisfaction, or should I just leave it to pitti?
[18:45] <slangasek> the latter may be simpler :)
[18:46] <Laney> it was discussed a bit in #-release earlier, but only retrospectively
[18:46] <mterry> slangasek, I think it was brought up in last #ubuntu-desktop meeting, but again, retrospectively
[18:49] <mterry> slangasek, https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-09-20 (the meeting I mentioned)
[19:01] <cnd> it looks like there's some support for pkg-create-dbgsym in ppas
[19:01] <cnd> looking at the source for pkg-create-dbgsym, it seems that if "Build-Debug-Symbols: yes" is set somewhere, it will build them
[19:01] <cnd> is there any docs on this?
[19:02] <cnd> pitti, ^^ ?
[19:08] <slangasek> mterry: thanks - and I found the previous MIR for mocker, so I've repromoted both packages
[19:38] <doko_> slangasek, do you mind updating qemu-linaro to the recent release, fixing the build failure?
[19:49] <slangasek> doko_: I don't /mind/, no, but it requires a FFe... was just discussing that on #ubuntu-release this morning, I'll go ahead with it soon
[20:12] <bladernr> Does anyone off hand know who maintains mesa-utils (glxinfo, glxgears, glxheads) or who/where to poke with bugs and questions?  I keep running into dead ends on Launchpad and google gives me blog posts about mesa-utils, but nothing useful
[20:18] <doko> seb128: could you pitti please have a look at the seed build failure? looks like you did request the sync and did ignore the build failures
[20:18] <seb128> doko, will do if I've time next week
[20:18] <seb128> doko, if pitti doesn't beat me to it but it called it a week already
[20:18] <doko> seb128, sorry, but next time please spend your time before doing syncs like these
[20:19] <Sarvatt> bladernr: ubuntu-x-swat, #ubuntu-x. its a new package which was split off from the mesa source is probably why there's a dearth of info
[20:19] <bladernr> Sarvatt:  awesome! thanks a lot :)
[20:19] <seb128> doko, 3.0.0-1 built
[20:19] <doko> yeah, but not -2
[20:19] <seb128> it has no code change
[20:20] <doko> and no reaction from your side
[20:20] <seb128> we would have got the same issue without syncing it
[20:20] <seb128> right, it's a toolchain segfault
[20:20] <seb128> not a seed issue
[20:20] <doko> seb128, bullshit
[20:21] <seb128> well -1 built fine and there is no code change
[20:21] <seb128> well "toolchain" can be "build-depends"
[20:21] <seb128> but seed didn't change between the version which built and the one which didn't, it was only packaging cleaning
[20:21] <seb128> the same version built in debian and is in testing
[20:21] <doko> seb128, when will you learn that the toolchain uncovers issues in broken code?
[20:22] <seb128> well nothing tell you that it doesn't expose a bug in the toolchain either
[20:22] <seb128> doko, you are just doing claims, it could be either way
[20:23] <seb128> only debugging will tell us, but -1 built and -2 which is what we have built in Debian and is in testing
[20:23] <doko> usually I'm right with my "claims". it's the non-action on your side which concerns me
[20:23] <seb128> well, it's not in the default install so I don't really care
[20:24] <seb128> which I admit is not a position everybody share, but we have the resources to either make our default install good or everything medium, I prefer to focus on what is most used
[20:24] <seb128> but feel free to drop seed from oneiric and epiphany-browser with it if nobody fixes it
[20:26] <seb128> seems similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582774
[20:27] <doko> seb128, please could you reply to the launchpad issue that it is ok to remove epiphany-browser? I'm fine with this
[20:28] <seb128> well, I'm not deciding with that but if the issue is not fixed that's what we should do
[20:28] <seb128> but if somebody cares and want to fix the issue they should be able to do it
[20:28] <seb128> it's true for any ftbfs not fixed by oneiric...
[20:32] <micahg> doko: seb128, can we just remove the binaries and not the source in case someone wants to fix it?
[20:34] <doko> we can, but still shows up as a ftbfs. I don't see any harm to remove the sources too. cjwatson does want to improve the sync script to not accept the same version again, if it was already in ubuntu
[20:34] <seb128> well no reason to not sync that one next cycle
[20:35] <micahg> doko: I don't think showing up as an FTBFS is a bad thing, it might encourage someone to fix it
[20:35] <seb128> it could well be a toolchain bug since it built before in the cycle and builds in debian
[20:35] <doko> removal doesn't mean not syncing new versions
[20:36] <doko> seb128, just be honest and clear, that you even that you didn't event check to build the package with -g
[20:36] <doko> s/even/even check/
[20:37] <doko> damn mousepad
[20:37] <seb128> what -g would change?
[20:38] <stgraber> kenvandine: ping
[20:38] <doko> get a backtrack which you could look at?
[20:38] <kenvandine> stgraber, pong
[20:39] <stgraber> kenvandine: Currently reviewing https://code.launchpad.net/~vanvugt/ubuntu/natty/light-themes/fix-772972-natty/+merge/70667 but don't know much about the design stuff, is that something we want in natty as an SRU?
[20:40] <seb128> doko, right, I could fix an issue in the default installation that most users will run into or debug something nobody use...
[20:40] <doko> seb128, then we should remove it. agreed?
[20:41] <seb128> not that I don't like epiphany-browser but be realistic most users run firefox and chromium
[20:41] <kenvandine> stgraber, i haven't seen the bug... but it might be worthy of a SRU
[20:41] <kenvandine> jitters sound annoying
[20:41] <seb128> doko, well I personally don't care enough to spend my time on it but others might do
[20:41] <seb128> so I will not speak for them there
[20:41] <doko> ok, removing
[20:41] <seb128> we should let them a chance to fix it if somebody cares enough to step for it
[20:41] <seb128> ok
[20:42] <seb128> doko, you will probably not make friends over it ;-) I would rather let people who care another week chance to fix it
[20:43] <doko> seb128, I disagree. the bug report was filed a month ago. there is no reason why we cannot reintroduce the sources again
[20:43] <seb128> doko, well your call, I've nothing to do with it ;-)
[20:44] <micahg> doko: post-release, it's easier if the sources are there already
[20:44] <doko> besides syncing in the first place :-/
[20:44] <micahg> it's not like it's abandoned upstream
[20:44] <seb128> doko, I synced a debian revision with no code change, we would have got the same issue without that sync
[20:45] <seb128> -1 built, -2 doesn't without code change
[20:45] <seb128> it's something else which changed
[20:45] <seb128> it would have showed up in your rebuilt test
[20:45] <doko> seb128, and you din't care about the build results
[20:45] <doko> repat loop on
[20:45] <doko> repeat even
[20:45] <seb128> how that has to do with the issue?
[20:46] <seb128> you would have got the same issue if -2 wouldn't have been synced
[20:46] <stgraber> kenvandine: ok, diff looks reasonable and the change seems to be in Oneiric (though a lot more changed so not too easy to check). I'm going to sponsor that and get more testing once it's in -proposed
[20:46] <doko> seb128, expose the issue months earlier, and not hiding with "let's wait one more week"?
[20:47] <seb128> well if anything the sync exposed the issue earlier
[20:47] <seb128> because it failed to build at the sync, not in an archive rebuilt later on
[20:48] <smoser> slangasek, around ?
[20:48] <slangasek> smoser: hey there
[20:48] <smoser> i'm playing around with a cloud-image booting locally in kvm
[20:48] <smoser> and after a bunch of poking / digging, i'm seeing stuff like
[20:48] <smoser> /sbin/dhclient-script: line 73: /etc/resolv.conf.dhclient-new: Read-only file sy
[20:48] <smoser> chmod: cannot access `/etc/resolv.conf.dhclient-new': No such file or directory
[20:48] <smoser> can't create /var/lib/dhcp3/dhclient.eth0.leases: No such file or directory
[20:49] <smoser> oh...
[20:49] <micahg> doko: FTBFS are SRU worthy, so please just remove the binaries
[20:49] <smoser> slangasek, i think that network-interface.conf is coming up before / is RW
[20:50] <smoser> and nothing is enforcing it to wait, although it clearly needs it.
[20:50] <chrisccoulson> politcally, removing epiphany will be very bad for us btw ;)
[20:50] <slangasek> smoser: what do you mean, "clearly needs it"?
[20:50] <smoser> well, if it can't write resolv.conf, then i can't resolve hostnames
[20:50] <slangasek> network-interface.conf should certainly not be writing to the root fs
[20:50] <smoser> and i don't want to pass /etc/hosts files around
[20:50] <smoser> :)
[20:50] <micahg> chrisccoulson: right :)
[20:50] <seb128> yeah, removing epiphany would be an error
[20:51] <slangasek> smoser: what's writing to /etc/resolv.conf?  That's not the standard behavior of ifupdown
[20:51] <smoser> dhclient is
[20:51] <slangasek> smoser: God forbid
[20:51] <smoser> dhclient is getting called on the add of eth0
[20:51] <smoser> which is happening before / is rw
[20:52] <slangasek> smoser: no, dhclient does not write to /etc/resolv.conf either; it'll be some hook script called by dhclient in /etc/dhcp3/dhclient-{enter,exit}-hooks.d - and not a standard one
[20:52] <smoser> well... i dont knwo about not a standard one
[20:52] <ScottK> jbicha: One of the changes in http://launchpadlibrarian.net/80663925/yelp-tools_3.1.6-0ubuntu1_3.1.7-0ubuntu1.diff.gz is that it now refers to files in /opt/gnome.  That seems "bad".  Would you please double check this.
[20:53] <slangasek> smoser: point is, writing this to /etc/resolv.conf is *wrong*, and whatever is doing that is *buggy*.  If something wants to provide interfaces for managing resolv.conf dynamically, it should be symlinking this file to somewhere in /run and managing it there
[20:53] <smoser> i'll see what i can find, but there is nothing in the image that is not in main.
[20:53] <seb128> ScottK, is that an autogenerated file? i.e one that will be overwritten on build? it's often the case with GNOME components
[20:54] <slangasek> it is not correct to wait for writable root before bringing up the network interfaces - in some configurations, / may never be made writable
[20:55] <smoser> slangasek, well, its /sbin/dhclient-script that is writing it
[20:55] <smoser> isc-dhcp-client
[20:56] <seb128> doko, chrisccoulson, micahg: seed 3.2 builds fine it seems, I will upload it
[20:56] <smoser> depended on by isc-dhcp-client and ubuntu-minimal
[20:56] <smoser> errr... well not depnedend on by itself, but by ubuntu-minimal
[20:57] <smoser> why exactly i have ubuntu-minimal installed i'm not sure.
[20:58] <slangasek> because it's not an Ubuntu system without ubuntu-minimal? :)
[20:59] <slangasek> so I'm surprised that isc-dhcp-client is doing this... let me dig into the history and get back to you
[21:00] <smoser> slangasek, so how would you think i should get entries in resolv.conf on a dhcp system ?
[21:00] <ScottK> seb128: I don't know.  It's possible.
[21:01] <ScottK> seb128: I don't know much about Gnome stuff, but the diff seemed worth a second look.
[21:01] <seb128> ScottK, well I didn't look at this one but it's 99% chance
[21:01] <ScottK> OK.
[21:02] <ScottK> I'll accept it then.
[21:02] <seb128> thanks
[21:06] <slangasek> smoser: /etc/resolv.conf should be a symlink to somewhere managed in /run
[21:06] <slangasek> smoser: which *used* to be how we did this; I don't understand why we've regressed here
[21:08] <smoser> hmph.
[21:08] <smoser> on my sys, i have resolvconf managing it so it is a symlink, but i know on installation i it complains it is not a symlink and I end up fixing it.
[21:09] <smoser> slangasek, but in the non-dhcp case, then, what would be managing resolv.conf ?
[21:10] <seb128> doko, ok, seed 3.2 uploaded and in approved, it builds fine there
[21:11] <seb128> the new version is part of GNOME and has a small diff so it shouldn't need a feature freeze exception
[21:11] <slangasek> smoser: well, that's a question - I don't have an immediate answer for you.  I can just say that architecturally, assuming /etc/resolv.conf should be managed in-place is wrong :)
[21:12] <slangasek> smoser: btw, /sbin/dhclient-script has a loop that waits for / to become writable... is that not working?
[21:12] <smoser> must not be working
[21:12] <slangasek> smoser: does your /etc/fstab not have a line for the rootfs?
[21:13] <smoser> LABEL=cloudimg-rootfs              /               ext4    defaults        0
[21:13] <smoser>  0
[21:13] <slangasek> should work
[21:13] <smoser> nope
[21:13] <smoser> oh.
[21:13] <slangasek> *should* work :)
[21:13] <smoser> yeah, it should
[21:15] <smoser> slangasek, yeah, that loop seems sane
[21:16] <smoser> i'll poke more at this later.
[21:16] <slangasek> smoser: ok... I'll continue poking at the history to see where things have gone astray, and see what we can do about getting this all properly architected for p
[21:16] <smoser> interestingly, if /etc/resolv.conf *were* a symlink to /run, it would sit and wait until root is rw
[21:16] <smoser> it waits for '-w /etc/'
[21:16] <slangasek> yep
[21:17] <smoser> later.
[21:17] <slangasek> enjoy :)
[21:17] <smoser> thanks for your help, slangasek
[21:17] <micahg> seb128: will epiphany 3.0 work with it though?
[21:19] <seb128> micahg, there is like 25 commits between 3.0 and 3.2 and mostly translation updates and bug fixes, so I guess so
[21:19] <seb128> micahg, if not we will fix epiphany
[21:41] <jtaylor> doko: glib2.0 fails to build with APPEND {CFLAGS,LDFLAGS} -flto (binutils 2.21.53.20110810-0ubuntu3 with PR ld/13201 "fixed")
[21:43] <jtaylor> http://paste.ubuntu.com/695329/ bug should get filed soon by the guy who found it
[21:44] <jtaylor> is flto still not ready for general use or could this be an as-needed related bug?
[21:45] <doko> jtaylor, is this with the glib2.0 in the archive?
[21:45] <jtaylor> yes
[21:45] <jtaylor> 2.29.92-0ubuntu1
[21:46] <jtaylor> its weird ldd -r libglib.so does not list any undefined references
[21:46] <doko> in general, anything else than -g -O2 (distribution defaults) should be handled by the package maintainer
[21:46] <jtaylor> those functions are connected to FORTIFY_SOURCE or?
[21:47] <doko> jtaylor, please check with -U_FORTIFY_SOURCE if you can
[21:48] <jtaylor> running
[21:52] <jtaylor> ok now I get this: /tmp/glib2.0-2.29.92/./glib/tests/mem-overflow.c:137:1: sorry, unimplemented: gimple bytecode streams do not support the optimization attribute
[21:53] <jtaylor> but it got past the linking issue from before
[21:53] <doko> I'll look at it tomorrow, but not now
[21:53] <jtaylor> no problem thanks
[21:59] <stgraber> @pilot out
[22:15] <jtaylor> bug 856839
[22:43] <Sweetshark> Hi all. I have a question about bug status handling: Could somebody have a look at https://bugs.launchpad.net/df-libreoffice/+bug/745836/comments/51 and give me an opinion/judgement before that escalates into a bug-state-war? (asking here because ubuntu-bugs is silent)
[22:53] <Viper550> Hello
[22:55] <bdrung> tumbleweed: $ syncpackage ubuntu-dev-tools
[22:55] <bdrung> syncpackage: Error: Debian version 0.132 does not exist!
[23:01] <Laney> https://launchpad.net/debian/+source/ubuntu-dev-tools