[01:50] <Cas-> the distribute log for oneiric is a mess
[01:50] <Cas-> https://launchpad.net/ubuntu/+source/distribute/+changelog
[01:50] <Cas-> can i propose that oneiric simples get the same version as in precise?
[01:56] <micahg> Cas-: what do you mean the log is a mesS?
[01:57] <Cas-> i mean that the version 0.16.6 is just patched and patched instead of just pulling release versions
[01:58] <micahg> we don't update release version in stable releases unless they are totally broke beyond fixing
[01:58] <micahg> backports are possible for some applications
[01:58] <Cas-> we i think this is one of them
[01:58] <micahg> Cas-: is there something wrong with the version in precise?
[01:58] <micahg> err...oneiric
[01:58] <Cas-> yes
[01:59] <micahg> bug #?
[01:59] <Cas-> https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/938786
[02:01] <Cas-> basically a fix from 0.16.7 was applied to 0.16.6 that was actually broken and then fixed in 0.16.8
[02:01] <micahg> Cas-: as soon as the current package in -proposed migrates to -updates, we can upload this fix
[02:03] <Cas-> the list of changes for distribute is very small http://pypi.python.org/pypi/distribute#changes so thats why i suggested oneiric should match  precise version of 0.6.24
[02:04] <micahg> yeah, we generally don't do that, are there other specific fixes needed for oneiric besides this one?
[02:04] <Cas-> not that i have specifically encoutered
[02:06] <micahg> ok, so let's just do one more SRU then, I"ll give you a bug task, but I'm not comfortable uploading the change, I'd prefer someone with a python background review it, do you want to prepare a debdiff? (it can be sponsored on your behalf then and go straight in the sponsorship queue)
[02:07] <Cas-> the only change that matters is the tab indent in pkg_resources.py
[02:08] <Cas-> i dont have a setup for debdiff
[02:09] <micahg> bzr branch works also
[02:14] <Cas-> well it's late here i'll need to sort it 2mw
[05:10] <pitti> Good morning
[06:36] <pitti> is LP being upgraded or so? it's horribly unstable ATM
[06:38] <lifeless> pitti: we're looking at it
[06:38] <lifeless> pitti: no, its not mid-deploy (and that doesn't cause instability anyhow); we're seeing broken connections to the db master and currently divide-and-conquering the path
[06:38] <pitti> lifeless: ah, thanks
[06:39] <lifeless> we've just tried something; tell us if its better worse ?
[06:46] <pitti> I did three changes now, they all succeeded
[06:46] <pitti> before I needed to try each bug state change some 5 times
[06:46] <lifeless> cool
[06:46] <lifeless> thanks
[06:49] <pitti> bzr commit worked as well
[06:57] <pitti> ev: FYI, I fixed the ui.py test failures in apport trunk now
[07:09] <pitti> cjwatson, slangasek, StevenK: it seems /srv/launchpad.net/ubuntu-archive/ubuntu-germinate/ does not get updated any more; any hint how I could debug this? is that being called by soyuz or by some cronjob which I fail to see?
[07:10] <slangasek> pitti: hmm, I suppose this would be related to cjwatson's changes this cycle to speed up publishing, but I'm afraid I don't know the details
[07:11] <pitti> it just stopped two days ago
[07:11] <StevenK> That's what I was thinking.
[07:11] <pitti> three now
[07:11] <slangasek> ah
[07:11] <slangasek> so it's still supposed to be done as part of the publisher run
[07:11] <pitti> and I figure that's rather bad, as I assume live CD builds etc. depend on this?
[07:11] <slangasek> but there's been some restructuring
[07:11] <pitti> (not to mention breakign http://people.canonical.com/~ubuntu-archive/component-mismatches.txt etc.)
[07:12] <slangasek> well, that output impacts the task fields in the archive
[07:12] <pitti> right, so our recent seed changes will probably not take effect
[07:13]  * slangasek nods
[07:17] <slangasek> infinity: hmm, wubi livefs build failure, "mount: unknown filesystem type 'ext4'" - is that related to the changes I saw you making?
[07:33]  * ogra_ wonders where infinity's live-build upload went 
[07:56] <Adri2000> I'm not sure if it's useful to say this, or if it's done regularly anyway: libhighgui2.1 and libcv2.1 binary packages are NBS and can now be removed
[08:08] <pitti> Adri2000: I did so an hour ago or so
[08:08] <pitti> after sitplus finally built on powerpc
[08:08] <pitti> Adri2000: I'm watching this regularly, yes
[08:13] <dholbach> good morning
[08:14] <diwic> good morning dholbach
[08:14] <dholbach> hey diwic
[08:17] <Adri2000> pitti: cool. btw, I can't find anymore the list of removed packages (no removals.txt at http://people.canonical.com/~ubuntu-archive/), where is it?
[08:17] <pitti> Adri2000: I don't know whether there is a replacement
[08:19] <Adri2000> it was useful in some cases :)
[08:23] <geser> Adri2000: do you need a list of removed packages or the reason (and date) when a package got removed? the later can be found in LP
[08:24] <Adri2000> geser: even binary package removals can be found in LP? how?
[08:30] <geser> Adri2000: sure, e.g. https://launchpad.net/ubuntu/oneiric/amd64/libcv2.1 should mention it once it's removed (don't have a better example right now)
[08:31] <Adri2000> ok, https://launchpad.net/ubuntu/precise/amd64/libcv2.1 mentions it so it's good :)
[08:32] <geser> ah right, forgot to replace the release in the url
[08:40] <pitti> also, e. g. https://launchpad.net/ubuntu/+source/libaws/+changelog
[08:41] <pitti> or https://launchpad.net/ubuntu/+source/libaws/+publishinghistory (with more data)
[09:22] <tkamppeter> Anyone taking care of bug 911436? It leads to crashes of the CUPS daemon, especially when the CUPS package gets updated and therefore the daemon restarted.
[09:26] <tkamppeter> slangasek, you have set bug 911436 to "Triaged" a while ago, are you working on solving it?
[09:29] <ev> pitti: cheers!
[09:29] <pitti> lamont, infinity: temporarily stealing some buildds for i386 for the langpack upload, as it's all quiet otherwise
[09:29] <pitti> (just FYI)
[09:30] <pitti> ev: so AFAICS from yesterday's discussion we still need a way to disable apport's LP bug filing, but not whoopsie submission post-release, right?
[09:31] <chrysn> how can i, in build conflicts, conflict against a specific range of versions?
[09:31] <chrysn> (in particular, libglew released packages using 1.5.2 code as "1.5.7.is.1.5.2", which makes it kind of tricky to depend on what you'd normally call libglew1.5-dev (>= 1.5.4) )
[09:44] <tjaalton> I need a quick FFe for wayland, which now has a real upstream release instead of the git snapshots we've had before. it's also a build-dependency of the new mesa bugfix release I'm preparing
[09:45] <tjaalton> nothing else depends on it, so risk of regression is negligible
[09:46] <pitti> tjaalton: eek, that would mean wayland needs to go into main?
[09:46] <tjaalton> it is already
[09:46] <tjaalton> ok sorry, I'll rephrase
[09:46] <pitti> eek :)
[09:46] <tjaalton> the new mesa build-depends on this release :)
[09:46] <pitti> tjaalton: so, otherwise this sounds fine
[09:46] <tjaalton> it has that build-depend already
[09:46] <tjaalton> *has had
[09:48] <tjaalton> so the bugfix mesa release needs this new wayland to build libwayland-egl
[09:48] <tjaalton> mesa will fix a bunch of crashers, at least bug 926379
[10:04] <tjaalton> pitti: so I take it that it's ok to update wayland too?
[10:04] <pitti> tjaalton: yes, fine for me
[10:04] <tjaalton> thanks!
[10:04] <pitti> tjaalton: you might want to coordinate with bryce, he did the wayland updates before
[10:05] <tjaalton> these are maintained in pkg-xorg git, so yeah he should know what's happening :)
[10:06] <tjaalton> Sarvatt did the previous upload
[10:09] <tjaalton> pitti: there's also the default wayland compositor, weston, that could be synced from experimental (NEW)?
[10:09] <pitti> tjaalton: no idea about that; that seems less urgent and more invasive, and should probably get an FFE bug
[10:10] <tjaalton> yes less urgent
[10:10] <tjaalton> I'll leave it for now
[10:15] <infinity> slangasek: Potentially.  I'll look at it in the morning.
[10:19] <bryceh> pitti, yes the merge is fine by me; I have no plans to look at or work on wayland this cycle
[10:20] <bryceh> pitti, also since no one really uses the compositor I don't really see any harm in letting that be sync'd in.  It's really only existing for testing purposes, for people who want to observe compositors crashing a lot.
[10:20] <pitti> *chuckle*
[10:26] <dholbach> what is whoopsie and why does it use 89% of 8G of RAM? :)
[10:26] <pitti> ev: ^
[10:26] <pitti> dholbach: ev's new crash reporting daemon
[10:26] <ev> gah
[10:27] <pitti> the joys of C programs?
[10:27] <ev> :)
[10:27] <ev> I did run it through memcheck
[10:27] <ev> dholbach: do you have any .upload files in /var/crash?
[10:28] <dholbach> 28294 whoopsie  20   0 37.0g 7.0g 1116 S    0 90.4   0:33.84 whoopsie
[10:28] <dholbach> ev, no, just a bunch of .crash files
[10:29] <ev> interesting
[10:29] <ev> did you elect to report any crashes using the new apport UI?
[10:29] <dholbach> yes
[10:30] <ev> dholbach: could you pastebin a ls -la of /var/crash
[10:31] <ev> curious to know if there's anything particularly large in there
[10:31] <dholbach> ev, http://paste.ubuntu.com/853789/
[10:31] <dholbach> ev, maybe it's struggling with the one owned by daniel.daniel?
[10:32] <ev> dholbach: well, it's not supposed to touch anything at all if there isn't a matching .upload file for it
[10:32] <dholbach> aha
[10:33] <ev> dholbach: could you possibly do sudo stop whoopsie; CRASH_DB_URL=http://localhost /usr/bin/whoopsie -f > whoopsie.log 2&>1 for a bit
[10:33] <dholbach> sure
[10:33] <ev> and see if it starts growing out of control
[10:33] <ev> much appreciated
[10:33]  * ev goes memleak hunting
[10:34] <dholbach> ev,
[10:34] <dholbach> aniel@daydream:~$ sudo stop whoopsie; CRASH_DB_URL=http://localhost /usr/bin/whoopsie -f > whoopsie.log 2&>1
[10:34] <dholbach> whoopsie stop/waiting
[10:34] <dholbach> Trace/Breakpoint ausgelöst (Speicherabzug geschrieben)
[10:34] <dholbach> daniel@daydream:~$
[10:35] <dholbach> hum, let me try to find a translation for this :)
[10:35] <dholbach> in any case it crashed
[10:35] <dholbach> whoopsie crashed with signal 5 in __libc_start_main()
[10:36] <dholbach> "Trace / breakpoint is triggered (dump written)"
[10:37] <ev> dholbach: if you would be so kind, CRASH_DB_URL=http://localhost gdb --args /usr/bin/whoopsie -f
[10:37] <ev> r then bt
[10:37] <dholbach> I guess I will need some debug symbols - right now it's useless
[10:38] <ev> :)
[10:40] <ev> dholbach: https://bugs.launchpad.net/ubuntu/+source/whoopsie-daisy/+bug/939392 for the memleak bug
[10:40] <dholbach> ev, http://paste.ubuntu.com/853800/
[10:41] <ev> ah, whoops
[10:41] <ev> I'll fix that, but...
[10:41] <ev> sudo CRASH_DB_URL=http://localhost /usr/bin/whoopsie -f >whoopsie.log 2&>1
[10:42] <pitti> http://daisy.ubuntu.com/ doesn't seem to exist/
[10:42] <pitti> ?
[10:42] <ev> pitti: not yet - IS is working on that
[10:43] <dholbach> ev, I'll let you know if anything interesting turns up
[10:43] <ev> dholbach: cheers, and sorry about this
[10:43] <dholbach> no, no - it's fine
[11:04] <jml> hello
[11:06] <jml> something has happened such that my local apt is broken and I can no longer upgrade
[11:06] <pitti> jml: did you try sudo apt-get -f install?
[11:06] <pitti> (withouth the '?')
[11:06] <jml> pitti: hah. of course. :)
[11:06] <pitti> jml: what does it say?
[11:07] <jml> pitti: http://paste.ubuntu.com/853832/
[11:07] <jml> E: Internal Error, No file name for libc6
[11:07] <pitti> erk
[11:07] <pitti> and mvo is on holiday
[11:08] <pitti> jml: perhaps try this:
[11:08] <pitti> sudo rm /var/lib//apt/lists/* /var/cache/apt/*cache*
[11:08] <pitti> sudo apt-get update
[11:08] <pitti> sudo apt-get -f install
[11:09] <jml> pitti: ok. will try that
[11:09] <pitti> jml: perhaps save the caches before, for later investigation
[11:09] <jml> oops :)
[11:10] <jml> pitti: /var/lib/apt/lists/partial still exists. Should I remove that?
[11:10] <pitti> jml: keep the dir
[11:10] <pitti> you can remove the files in it
[11:10] <jml> o
[11:10] <jml> k
[11:10] <pitti> jml: by gut feeling is that the caches were broken, the apt lists are usually okay
[11:11] <pitti> modulo memory/fs corruption of course
[11:12] <jml> pitti: still get the same error on apt-get -f install
[11:13] <pitti> jml: can you please show me "apt-cache policy libc6"?
[11:14] <jml> pitti: http://paste.ubuntu.com/853840/
[11:15] <pitti> that looks fine
[11:15] <pitti> jml: does "sudo apt-get install --reinstall libc6" work?
[11:15] <pitti> i. e. does it know about the package name ther?
[11:16]  * jml tries
[11:16] <pitti> jml: oh, wait
[11:16] <pitti> jml: perhaps it thought it already downloaded the libc6 .deb, but didn't
[11:16] <pitti> jml: rm /var/cache/apt/archives/* might helP?
[11:17] <jml> yay
[11:17] <jml> boo
[11:17] <geser> googling suggests that it might be related to /var/lib/dpkg/status
[11:18] <pitti> I don't know how to regenerate status, though
[11:18] <jml> http://paste.ubuntu.com/853844/
[11:19] <geser> there should be a backup file
[11:20] <geser> see bug #859188 for a similar problem
[11:20] <jml> geser: 'status-old' is identical to 'status', fwiw.
[11:21] <geser> try "apt-get install --reinstall libc6:i386 libc6:amd64"
[11:22] <jml> geser: $ sudo apt-get install -y --reinstall libc6:i386 libc6:amd64
[11:22] <jml> Reading package lists... Done
[11:22] <jml> Building dependency tree
[11:22] <jml> Reading state information... Done
[11:22] <jml> You might want to run 'apt-get -f install' to correct these:
[11:22] <jml> The following packages have unmet dependencies.
[11:22] <jml>  libc-dev-bin : Depends: libc6 (< 2.14) but 2.15-0ubuntu2 is to be installed
[11:22] <jml>  libc6 : Depends: libc-bin (= 2.15-0ubuntu2)
[11:22] <jml>  libc6:i386 : Depends: libc-bin:i386 (= 2.15-0ubuntu2)
[11:22] <jml>  libc6-dev : Depends: libc6 (= 2.13-24ubuntu4) but 2.15-0ubuntu2 is to be installed
[11:22] <jml>  libnih1 : Depends: libc6 (< 2.15) but 2.15-0ubuntu2 is to be installed
[11:22] <jml> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
[11:22] <jml> sorry
[11:22] <jml> I honestly hit C-c on the URL in the browser
[11:22] <geser> hmm
[11:22] <geser> there are some more backups in /var/backups/dpkg.status.*
[11:23] <jml> (I could swear that something about recent Ubuntus introduces a lag on keyboard input when switching windows/desktops)
[11:25] <jml> well, here's the diff between current status and the first one that has a difference: http://paste.ubuntu.com/853852/
[11:25] <geser> is this an upgrade precise -> precise?
[11:25] <pitti> jml: that libnih1 is old
[11:25] <geser> I'm wondering why it doesn't want to upgrade the other packages
[11:26] <pitti> especially since he already  has libc6 2.15
[11:26] <jml> geser: yes, it is.
[11:26] <pitti> jml: apt-cache policy libnih1?
[11:26] <jml> http://paste.ubuntu.com/853853/
[11:28] <geser> does it upgrade libc6 if you leave out the --reinstall?
[11:28] <pitti> jml: sudo apt-get install --reinstall libc6 libnih1 libc-dev-bin libc6:i386
[11:29] <geser> and try adding libc-dev-bin libc6-dev libnih1 to the list of packages to install
[11:29]  * pitti ^5s geser
[11:31] <jml> hmm
[11:32] <jml> pitti: the --reinstall command just errors out with unmet dependencies...
[11:33] <pitti> jml: you can try adding all the unmet ones until it works
[11:33] <geser> or you get a meaningfull error
[11:34] <diwic> jml, I had that problem when upgrading precise a while ago and found in some bug (don't remember number) that "sudo dpkg -i /var/cache/apt/archives/libc...." was the right way to resolve the problme
[11:34] <jml> http://paste.ubuntu.com/853861/
[11:34] <diwic> after that you can continue with "-f install" and the "dist-upgrade"
[11:34] <jml> after I add packages, I get the original libc6 error again :\
[11:35] <geser> bah :(
[11:35] <jml> diwic: oddly, I don't have a libc6 deb in my apt/archives folder
[11:35] <diwic> bad luck
[11:36] <diwic> :-/
[11:36] <geser> apt-get download libc6
[11:36] <pitti> ... and sudo dpkg -i libc6_*.deb
[11:36] <pitti> (it'll land in the current folder, not the apt cache)
[11:37] <geser> as this seems to be a multi-arch issue (as mentioned in that bug) perhaps slangasek knows how to get out of it (he commented on that bug)
[11:39] <jml> ok
[11:40] <jml> so the libc6 install failed because libc-bin wasn't at the right version, but I installed (dpkg -i) libc-bin from apt/archives and then tried installing the downloaded libc6. That seemed to work, and apt-get -f install seemed to finish successfully
[11:40] <jml> (although weirdly, the config system used readline rather than the pretty aubergine TUI)
[11:40] <hrw> who maintains ubuntu-seeds?
[11:41] <pitti> jml: great!
[11:41] <pitti> hrw: the "owners" of the respective derivatives, e. g. ~ubuntu-core-dev, ~xubuntu-dev, and so on
[11:41] <jml> and apt-get dist-upgrade is downloading a lot of stuff now :)
[11:41] <hrw> pitti: thx
[11:41] <jml> pitti, geser, diwic: thanks so much!
[11:42] <diwic> jml, np - but it has happened on two machines here so I assumed it was generic enough that someone would actually fix it, but we'll see...
[11:44] <pitti> diwic, TheMuso: WDYT about bug 930703 ?
[11:44] <pitti> I think it's about time
[11:46] <diwic> pitti, I don't know of any application using the esound interface; that said, I tend to err on the side of caution at this part of the cycle
[11:47] <diwic> pitti, but I guess such applications would then bring this in through some kind of dependency, huh?
[11:48] <pitti> diwic: I think we should promote libesd0's Suggests: pulseaudio-esound-compat to Recommends:
[11:49] <pitti> then everythign which still actually needs esound will still get it
[11:49] <pitti> but we avoid installing it by default
[11:49] <pitti> not that it takes much space or so, but it offers a wildly obsolete API
[11:50] <diwic> pitti, that sounds okay to me
[11:54] <Q-FUNK> jibel: pitti suggested that I talk to you about adding a check for $(dpkg-query -W -f='${Conffiles}\n' | grep obsolete | awk {'print $1'}) to https://jenkins.qa.ubuntu.com/view/Precise/
[11:55] <pitti> jibel: hm, that's perhaps something which could be added to ./AutoUpgradeTester/post_upgrade_tests/test_lts_upgrade_system.py ?
[11:56] <pitti> jibel: OOI, for changes to these scripts, is it enough to commit, or does it need an upload?
[11:56] <pitti> jibel: IOW, are you running from bzr or from the pacakge?
[11:56] <Q-FUNK> jibel: for reference, you can check how I use that stanza in src: upgrade-system
[12:01] <pitti> ev: before you continue to hack on apport, please pull trunk into your branch (your branch is merged)
[12:01] <ev> will do
[12:01] <pitti> ev: I made quite intrusive structural changes to the tests
[12:01] <ev> cool, will have a look
[12:01] <pitti> ev: the tests are now all in test/ and all look alike
[12:01] <ev> yay!
[12:01] <pitti> ev: this also makes it possible to run them against the installed system libs, too
[12:02] <pitti> hm, thehre are now 4889 LOC in apport/ and 8462 LOC in test/
[12:03] <ev> :D
[12:03] <tkamppeter> pitti, hi
[12:03] <pitti> hey tkamppeter
[12:03] <apw> pitti, heard of apport exploding when trying to submit bugs?  crashing python in fact:
[12:03] <apw> *** glibc detected *** /usr/bin/python: double free or corruption (fasttop): 0x000000000378bf60 ***
[12:04] <pitti> apw: not on my radar; sounds like a bad transfer annotation somewhere in GTK
[12:04] <pitti> apw: are you able to reproduce this?
[12:04] <apw> pitti, i tried to submit an xorg bug, and its failed twice, not sure its identicle symptoms tho
[12:05] <pitti> apw: ah, not a crash, just "apport-bug xorg"?
[12:05] <pitti> what did you click?
[12:05] <apw> pitti, ok so ubuntu-bug xorg, clicked the first two entries in the first dialog, the last one in the second, then hit 'Send' without changing anything in the third
[12:06] <apw> last two are identicle heap corription thingies
[12:06] <tkamppeter> pitti, I got the Ubuntu-branded test page today. I will put it into the cups-filters package. I will put it into debian/local/ (where the apport hook is) and replace the upstream page by this one in the case that the package is built for Ubuntu. Is this OK?
[12:06] <pitti> apw: second question is about lightdm log files; yes or no?
[12:07] <apw> pitti, sorry i also said yes to that one
[12:07] <pitti> tkamppeter: sure; could you do this in debian/rules with if dpkg-vendor --is ubuntu; then ... ?
[12:07] <pitti> tkamppeter: then we can keep it in sync with Debian
[12:07] <apw> so i was saying its 'reproducible' and 'happened more than once'; they could have my logs; and i would 'do anything' to get it fixed
[12:08] <pitti> apw: meh, works fine here
[12:09]  * apw ubuntu-bug ubuntu-bug's to see what happens
[12:09] <apw> ok that seems to work ... so i can file a bug about not being able to file a bug
[12:10] <pitti> apw: the .crash report might be more useful, though
[12:10] <pitti> full GTK stack trace and such
[12:10] <apw> so will there be a crash report for the apport crash?
[12:11] <apw> i'd assume it suppressed there to prevent circles
[12:11] <pitti> no, it shouldn't
[12:12] <pitti> apport has plenty of crash reprots
[12:12] <pitti> most of which are not very useful of course, but still, they are there
[12:13] <apw> hmmm, so i ran it three times, and got 3 aborts on my terminal, but only one maybe in /var/crash, does it do local dup detection ?
[12:13] <pitti> apw: the file name is by program name and user id, so yes
[12:13] <ev> didrocks: are you planning on uploading activity-log-manager 0.9.2 today? I only mention it because it should Breaks and Replaces on whoopsie < 0.1.10, as its taking ownership of the GNOME Control Center stuff.
[12:14] <apw> pitti, ok so i have a crash here, so how do i tickly apport to make a bug out of it
[12:14] <pitti> apw: usually it pops up by itself, but you can apport-bug /var/crash/*apport*.crash
[12:15] <apw> ev, would i expect all my reports in /var/crash to be readable by woopsie?
[12:15] <apw> pitti, seems i have like 10 in there, and i can't be bothered to handle them all right now
[12:15] <pitti> apw: just the _usr_share_apport_apport-gtk.crash one
[12:16] <didrocks> ev: yeah, it's on my schedule :)
[12:16] <apw> pitti, i ran the command you suggested, and have a dialog saying, "The application Report a problem ... has closed unexpectly."  and saying 'leave closed' and 'relaunch'
[12:16] <tkamppeter> pitti, how do I add the new test page to the package? If I put it into debian/local/ I get
[12:16] <didrocks> ev: thanks for the update! Will add the Breaks:/Replaces:
[12:16] <tkamppeter> dpkg-source: info: using source format `3.0 (quilt)'
[12:16] <tkamppeter> dpkg-source: error: unwanted binary file: debian/local/default-testpage.pdf
[12:16] <tkamppeter> dpkg-source: error: detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion).
[12:16] <pitti> tkamppeter: well, it pretty much says what it wants :)
[12:17] <didrocks> ev: no need for a FFe? the whoopsie part was already in precise?
[12:17] <tkamppeter> pitti, now I see.
[12:17] <ev> didrocks: correct; the whoopsie part was already in precise and cjwatson said this would be a UIFe
[12:18] <ev> apw: yes, should be
[12:18] <didrocks> ev: ok, and we will even upload before UIF, so all good! thanks :)
[12:18] <ev> cheers!
[12:18] <ev> I'll sort an upload of whoopsie without the control center stuff now
[12:18] <apw> ev, ok something isn't hnouring that, as most are, but i suspect one which was triggered by me running ubuntu-bug is not
[12:19] <ev> apw: is it 0600? or not group owned by whoopsie?
[12:19] <apw> ev, just got an error trying to submit a bug 'cannont connect to crash database'
[12:20] <apw> ev, its apw:apw 660
[12:20] <apw> -rw-r----- 1 apw apw      32993298 Feb 23 11:58 _usr_share_apport_apport-gtk.1000.crash
[12:20] <ev> huh? /var/crash should be g+s
[12:21] <ev> I take it that it's not?
[12:21] <tkamppeter> pitti, is debian/source/include-binaries a directory for the binaries or a list of the binaries?
[12:21] <apw> drwxrwsrwt 2 root whoopsie 4096 Feb 23 12:17 /var/crash
[12:21] <pitti> tkamppeter: I think a file
[12:21] <apw> ev, yes it is
[12:25] <tkamppeter> pitti, it is working now, it is indeed a file listing the exceptions.
[12:25] <ev> apw: I'm baffled as to how that happened then
[12:26] <apw> ev, its only the default ownership, so i guess somethign must have changed it, in apport
[12:27] <ev> oh, I didn't realize you could ignore it
[12:27]  * ev digs
[12:27] <apw> you can chgrp anything in there you own
[12:27] <apw> so i could go and do it myself, as they are my files
[12:30] <apw> pitti, ok finally got it filed: bug #939466
[12:35] <pitti> apw: thanks; need to wait on retracer
[12:41] <tkamppeter> pitti, I have pushed a new version of cups-filters. Can you upload it to Debian and Ubuntu, it contains the new test page and therefore needs to get uploaded before UI Freeze today.
[12:42] <tkamppeter> pitti, and when you are at it, can you also upl;oad CUPS to Debian and Ubuntu? I have fixed auto-config for PS printers in it.
[12:49] <Q-FUNK> ev: whoopsie seems to be missing the package description.
[12:52] <ev> Q-FUNK: fixing
[12:54] <Q-FUNK> ev: or well, it has the short description, but the long one doesn't appear.
[13:00] <tkamppeter> slangasek, hi
[13:08] <dholbach> ev, nothing interesting in ~/whoopsie.log, but in ~/1 there's http://paste.ubuntu.com/853954/ -- whoopsie doesn't seem to be leaking right now
[13:09] <Riddell> cjwatson, mdz: message in ubuntu-devel-announce for review/approval
[13:09] <ev> dholbach: I think I may have found part of the problem. If it fails to parse a report it will keep trying every time it processes the report queue (every hour or so)
[13:09] <ev> I've fixed that in trunk and will push an upload shortly
[13:10] <dholbach> cool
[13:10] <dholbach> thanks for your work on this ev
[13:10] <ev> thanks for your help in debugging it
[13:10] <dholbach> I just tried not to stand in the way too much ;-)
[13:10] <ev> dholbach: I don't suppose I could convince you to tar up /var/crash and send that my way? I'd be interested to know why it's failing to parse one of those reports, if that's the case.
[13:11] <ev> haha
[13:14] <dholbach> ev, I'll first need to find out how to do it in a way where the other coworking space people don't kill me :)
[13:15] <ev> dholbach: sure :) whenever you can. Doesn't need to be right now
[13:19] <dholbach> ev, ok, I'm uploading it using trickle right now - I'll be walking the dog now and let you know where you can find it later on
[13:21] <ev> dholbach: cheers!
[13:29] <pitti> tkamppeter: yes, can do
[13:30] <kklimonda> hmm, any idea why is cdrom-detect/try-usb=true added to the kernel cmdline when usb disk is being generated using usb-creator-gtk?
[13:30] <mterry> ev, new apport looks nice.  I'd include mpt too, but he's not here
[13:30] <kklimonda> or rather what is checking for this option?
[13:30] <ev> mterry: cheers!
[13:30] <jincreator> pitti: Hi. As result of fontconfig package now have information about fonts-nanum, I think bug #835304 is not invalid now. What do you think about it?
[13:31] <pitti> ev: mterry | pitti, did you do the revamp of the apport dialog?  Looks nice
[13:31] <pitti> ev: FYI :)
[13:32] <ev> :)
[13:32] <xinyi> join #ubuntu
[13:33] <pitti> ev: btw, I now put Package:, ExecutablePath: and Stacktrace: on the top of the details list, so that it's easier to see the affected package
[13:33] <pitti> ev: having "ApportVersion" at the top is not exactly the most interesting thing :)
[13:34] <ev> pitti: brilliant!
[13:34] <ev> heh
[13:34] <pitti> it's not enough yet to alleviate bug 938707 , but an improvement at least
[13:38] <Riddell> ev: ping "Notify Evan Dandrea to remove the disclaimer from Ubiquity's first page "
[13:39] <ev> Riddell: on it
[13:39] <Riddell> elmo: ping "Notify James Troup to remind mirrors to check free disk space "
[13:41] <pitti> tjaalton: https://launchpad.net/ubuntu/+source/mesa/7.11-0ubuntu3.1
[13:41] <pitti> tjaalton: any idea where the armhf build went to?
[13:42] <jibel> pitti, Q-FUNK auto-upgrade testing is running from bzr so a commit is enough or file a bug against u-m, attach the unittest script you want to run and assign it to me.
[13:42] <pitti> tjaalton: argh, unping; picked the wrong one
[13:43] <Q-FUNK> jibel: I have no idea of how to implement the scripts or where they would go.
[13:44] <Q-FUNK> jibel: I was simply asking pitti if LP has any tags for reporting packages that leave obsolete configs in place after an upgrade (as detected using the snippet above).
[13:44] <Q-FUNK> jibel: he recommended talking to you because it could be a good idea to automate such checks.
[13:52] <jibel> Q-FUNK, and he is right, it's a good idea to automate such checks :)
[13:53] <jibel> Q-FUNK, I looked at upgrade-system
[13:53] <jibel> Q-FUNK, the idea is to run $( dpkg-query -W -f='${Conffiles}\n' | grep obsolete | awk {'print $1'} ) post-upgrade
[13:53] <jibel> Q-FUNK, and check that the list is empty ?
[13:54] <Q-FUNK> jibel: essentially, yes. if it's not empty, to auto-file bugs against the packages concerned, indicating which files are concerned.
[13:55] <Q-FUNK> you can see what it does if you try:  sudo FLAUSCH=jah upgrade-system
[13:55] <pitti> infinity, lamont: FTR, buildds back to normal
[13:56] <Q-FUNK> jibel: these days, due to Debian making automated runs of piuparts, there's fewer of these orphan configs than bebore -- but upgrading LTS to LTS+1 leaves a lot of cruft.
[13:59] <Q-FUNK> jibel: currently, on my ubuntu+1 desktop, I only found 3 packages with such obsolete configs. on my LTS+1 host, it's close to 50 packages.
[14:01] <jibel> Q-FUNK, bug auto-filing, we are not here yet, but I can add the test to the daily auto-upgrade tests. That will give a good picture of the status of main and universe.
[14:01] <Q-FUNK> jibel: assuming that you would generate an automated bug report, packages that have such an obsolete config would need to call dpkg-maintscript-helper via debian/*maintscript to move or delete.
[14:04] <pitti> tkamppeter: cups and cups-filters uploaded
[14:08] <jibel> Q-FUNK, I filed bug 939528
[14:09] <Q-FUNK> jibel: ah, auto-upgrade-tester is a part of update-manager?
[14:10] <dholbach> ev, it's in chinstrap:~dholbach
[14:11] <jibel> Q-FUNK, yes, I'm working on separating them, but it will be done post B1.
[14:12] <Q-FUNK> jibel: ok. good to know. :)
[14:14] <ev> dholbach: cheers! I've grabbed it, so feel free to delete.
[14:19] <dholbach> ev, thanks
[14:31] <lenios_> does anybody know how to get the $ARCH in a makefile when building with pbuilder?
[14:32] <lenios_> it looks like it was working until 11.10, but now doesn't with 12.04
[14:34] <geser> are you looking for "dpkg-architecture -qDEB_BUILD_ARCH"?
[14:40] <lenios_> i used to set ARCH in my pbuilderrc
[14:42] <lenios_> or call ARCH=i386 pdebuild --configfile /etc/pbuilderrc
[14:44] <infinity> lamont: You around?  What releases are kapok and cardamon running?
[14:50] <infinity> lamont: And is it possible that they're running a kernel that doesn't grok ext4?
[14:51] <ogra_> infinity, i thought just a missing modprobe or some such
[14:51] <ogra_> infinity, but generally all our panda kernels and even the babbage ones always had ext4
[14:52] <infinity> ogra_: Unless they're also not running udev, a modprobe shouldn't be necessary.
[14:52] <infinity> ogra_: This is x86.
[14:52] <ogra_> well, do they run udev ?
[14:52] <ogra_> oh
[14:52] <ogra_> indeed
[14:52]  * ogra_ slaps foreheadf
[14:54] <infinity> Still, I'm pretty sure ext4 has been builtin on Ubuntu kernels for quite a while, so either they're running ancient releases or custom kernels.
[14:54] <infinity> (Well, maybe not ancient, I don't remember if it was =y or =m in lucid)
[14:54] <ogra_> or mount is broken
[14:55] <infinity> mount being broken seems less likely.
[14:55] <pitti> lucid has it built in, anyway
[14:55] <ogra_> well, as likely as a kernel without ext4
[14:55] <infinity> Not entirely unlikely, but I'm going to stop speculating until I get a response from IS. :P
[14:56] <ogra_> does livecd-rootfs have a versioned dep btw ? i.e. does the new live-build pulled in automatically ?
[14:56] <infinity> The builds apt-get upgrade before they start.
[14:57] <ogra_> k
[14:57] <infinity> Which is obviously happening, or I wouldn't have ext4 errors. :P
[14:57] <ogra_> why ? -f ext4 comes from buildlive, no ?
[14:57] <infinity> Oh, fair point.  All I changed in live-build was a filename.
[14:57] <infinity> Still half asleep here.
[14:58] <infinity> Either way, yes, it's auto-upgraded.
[14:58] <lenios_> geser, oh, DEB_HOST_ARCH looks like what i was looking for
[15:00] <cyphermox> blueyed: poke.
[15:02] <pitti> Riddell: hm, did you do anything to make lightdm-gtk-greeter have no reverse depends any more?
[15:02] <pitti> Riddell: I thought xubuntu, studio, lubuntu, etc. were using it?
[15:02] <pitti> now it's on http://people.canonical.com/~ubuntu-archive/nbs.html
[15:03] <pitti> Riddell: also, there was one libokularcore1 rdepends waiting for koffice removal, but koffice is still in the archive?
[15:03] <pitti> can it be removed now?
[15:04] <Riddell> pitti: have faith, I've taken care
[15:04] <infinity> ogra_: Feh, so they're running hardy. :/
[15:04] <pitti> Riddell: great, thanks
[15:04] <Riddell> pitti: the okular package was a rename from ages ago so that's fine
[15:04] <pitti> Riddell: I was just curious, as I heard there was a package for the greeter on alioth or so
[15:04] <Riddell> pitti: the lightdm one robert moved into a new source package so it's up to xubuntu etc to package, maybe micahg is doing it
[15:05] <ogra_> infinity, LOL
[15:05] <pitti> Riddell: right, I know
[15:05] <pitti> Riddell: I just wonder where all the rdepends went
[15:05] <pitti> xubuntu-desktop and friends Depend: on it
[15:05] <pitti> or NBS is gone haywire and telling lies
[15:05] <pitti> if we remove it now, we'll render them uninstallable
[15:06] <pitti> so we need to take care to not accidentally do it
[15:06] <Riddell> pitti: so we'd best hope micahg is packaging it :)
[15:06] <pitti> Riddell: so you didn't apply any magic?
[15:06] <pitti> then NBS has gone mad somehow
[15:06] <seb128> Riddell, pitti: the packaging is reading in debian
[15:06] <ogra_> infinity, joining the final arm meeting ?
[15:06] <infinity> ogra_: Oh, it's that time.
[15:06] <seb128> http://anonscm.debian.org/viewvc/pkg-xfce/goodies/trunk/lightdm-gtk-greeter/debian/
[15:07] <seb128> Riddell, ^
[15:07] <Riddell> pitti: oh I deleted it, it's up to xubuntu to fix it and I believe that's what is happening
[15:08]  * Riddell deletes koffice for good measure
[15:08] <Riddell> seb128: tell it to micahg :)
[15:08] <pitti> uh; well, let's hope it happens quickly then
[15:08] <pitti> also, it'll get caught in binNEW again
[15:08] <pitti> we usually wait until there are no rdepends
[15:08] <pitti> but oh well, it's done
[15:10] <Riddell> I'm doing New now too, happy to be pinged for anything that's needed for beta
[15:10] <pitti> thanks Riddell
[15:12] <mdeslaur> tedg: are you able to reproduce the xchat-gnome clipboard crash on demand? I can't seem to reproduce it
[15:13] <mdeslaur> tedg: I select text in the chat window, and then click like a mad man, and nothing happens
[15:13]  * tedg checks
[15:14] <mdeslaur> click here --->
[15:14] <mdeslaur> no, here -------->
[15:14] <mdeslaur> :)
[15:15] <tedg> mdeslaur, Well, apparently not... but it does happen quite a bit...
[15:15] <pitti> tkamppeter: did you see that cups-filters FTBFSed on missing fontconfig?
[15:15] <mdeslaur> tedg: ok, thanks
[15:15] <tedg> mdeslaur, I'm not quite sure what the click pattern is.  I wonder if it's a middle click thing....
[15:15] <mdeslaur> tedg: this happens with your touchpad?
[15:15] <tedg> mdeslaur, Yeah
[15:26] <pitti> ev: erk -- I just released and uploaded 1.93, saw your MP too late
[15:26] <pitti> ev: will do a followup upload
[15:26] <ev> no worries
[15:27] <pitti> ev: oh, it was the chown which subverted the sgid flag?
[15:27] <ev> pitti: it was for me, yes
[15:29] <pitti> ev: there's no bug # for that, right?
[15:29]  * pitti is writing the NEWS entry and wondering
[15:29] <ev> oh, I actually didn't check
[15:29] <ev> it was just from conversation in here
[15:29] <pitti> yeah, I guess nobody else noticed yet
[15:29] <pitti> I didn't see one this morning, anyway
[15:29] <ev> :)
[15:30] <pitti> ev: doesn't that affect the Python one, too?
[15:30] <pitti> ah, no, that's written as user
[15:30] <pitti> and thus, sgid should apply
[15:31] <ev> indeed
[15:31] <pitti> ev: btw, you merge trunk instead of pull?
[15:31] <ev> this was the only call to chown I found
[15:31] <pitti> (criss-cross merged)
[15:31] <ev> oh, interesting
[15:31] <ev> I've always done it this way out of habit
[15:31] <ev> I'll give that a bash next go around
[15:31] <pitti> pull basically unifies the history
[15:32] <pitti> it checks that everything is merged, of course
[15:32] <pitti> if not, it'll say "diverged"
[15:32] <pitti> and you know that you have something to be merged still
[15:32] <pitti> but anyway, if "merge" works, it shoudl be fine
[15:34] <ev> cool
[15:35] <Riddell> tjaalton: ping
[15:36] <Riddell> tjaalton: gstreamer-vaapi has a .git directory in it, shall I reject or accept?
[15:36] <tjaalton> Riddell: grr, reject :I
[15:36] <tjaalton> I'll reupload
[15:39] <Riddell> tjaalton: rejected!
[15:41] <lamont> infinity: if it isn't arm/ppc, it's hardy on the buildds
[15:41] <lamont> so.. 2.6.24-$mumble
[15:41] <lamont> prolly somewhere between 27 and 30
[15:44] <infinity> lamont: Yeah, already confirmed by gsa-ng for me. :/
[15:44] <tjaalton> Riddell: reuploaded with a fixed tarball. upstream doesn't provide one so I created it myself but forgot about the .git dir..
[15:44] <Riddell> pesky upstreams
[15:44] <tjaalton> yep.
[15:46] <Riddell> tjaalton: accepted!
[15:46] <tjaalton> Riddell: thanks!
[15:55] <mahmoh> infinity: bug 939240
[15:56] <infinity> mahmoh: Danke.
[15:56] <mahmoh> it has all the details but it appears that "05:14:37 umount("/boot", 0)             = 0" is hanging
[15:57] <ogra_> is /boot using a weird filesystem ?
[15:57] <infinity> mahmoh: Oh, err.  Is /boot an SD?
[15:58] <mahmoh> infinity: SATA ext3 and ext2 both hang, I think the ext4 rootfs also exhibits the same problem
[15:58] <infinity> Okay, so it's just a general "umounting sucks" issue, not actually related to the init sequence, now that I read the bug.
[15:58] <infinity> That should be slightly less awkward to look at, potentially more awkward to fix.
[15:58] <infinity> (And yeah, could be linux-armadaxp-specific, then)
[15:59] <mahmoh> should be, hopefully easier to fix
[16:02] <tjaalton> sigh, "No packages found matching gtk-doc-tools." on the buildd's, gstreamer-vaapi builds fine on sbuild though
[16:03] <tjaalton> though it's listed in build-depends-indep, does that matter?
[16:04] <infinity> tjaalton: Which build is this?
[16:04] <tjaalton> infinity: gstreamer-vaapi, every arch failed
[16:04] <tjaalton> https://launchpadlibrarian.net/93986127/buildlog_ubuntu-precise-amd64.gstreamer-vaapi_0.3.4-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:04] <tkamppeter> pitti, saw it now, strange, as I only added some small patches which should not have added new library dependencies, perhaps your libpoppler-private-dev caused a problem. I only built my changes locally for testing, I did not know about libpoppler-private-dev before I pushed my stuff.
[16:05] <infinity> tjaalton: But yeah, if it's in -indep, that's wrong, if arch-specific builds need it. :P
[16:05] <pitti> tkamppeter: private-dev is empty right now
[16:05] <tjaalton> infinity: ahah, ok. I probably copied it from the upstream debian dir
[16:05] <tjaalton> never used -indep before
[16:06] <pitti> tkamppeter: but yes, it did build in Debian
[16:06] <tkamppeter> pitti, perhaps some APIs got pulled out with the most recent Poppler, but my system is up-to date and it built.
[16:06] <pitti> tkamppeter: so it builds with 0.16, but not with our 0.18
[16:06] <tkamppeter> pitti, on my Precise is 0.18.
[16:06] <pitti> tkamppeter: I guess libpoppler-private-dev is missing a libfontconfig-dev dependency or so
[16:07] <infinity> tjaalton: Though...
[16:07] <infinity> tjaalton: That doesn't explain the i386 failure.
[16:07] <infinity> tjaalton: Still, if doc-tools is needed for the other builds, it's in the wrong field.  But, yeah, i386 is still failing even with it installed.
[16:08] <tkamppeter> pitti, does the dependency on empty libpoppler-private-dev replace ano old dependency?
[16:08] <tjaalton> infinity: ok I'll check that one too
[16:12] <pitti> tkamppeter: not sure; perhaps some other dependency changed in the meantime, I didn't look
[16:22] <sladen> tkamppeter: FTBFS: https://launchpadlibrarian.net/93976747/buildlog_ubuntu-precise-amd64.cups-filters_1.0.2-1_FAILEDTOBUILD.txt.gz
[16:23] <sladen> tkamppeter: checking for FONTCONFIG... configure: error: Package requirements (fontconfig >= 2.0.0) were not met:
[16:29] <cnd> didrocks, have you had a chance to look at xorg-gtest?
[16:30] <doko> Daviey, ruby ping
[16:30] <tkamppeter> pitti, sladen, seems that some package of cups-filters' build dependencies has dropped the dependency on fontconfig.
[16:32] <didrocks> cnd: no sorry, rush of UIF. I plan to do it tomorrow morning in a quieter time
[16:33] <tjaalton> infinity: yeah there was some stupid indep confflags trickery that didn't work, so --enable-gtk-doc wasn't passed on to configure
[16:33] <cnd> didrocks, ok, thanks :)
[16:33] <didrocks> cnd: but no worry, it's on my list :)
[16:34] <infinity> tjaalton: Which explains the i386 failure, and the other failures were just due to the missing build-dep?
[16:34] <larsu> pitti, tkamppeter, I heard cups-filters doesn't build? Can I help?
[16:35] <tjaalton> infinity: yep
[16:35] <infinity> tjaalton: Shiny.
[16:41] <Daviey> doko: ruby pong
[16:42]  * Daviey wonders if a ruby ping differs from a traditional ping
[16:42] <doko> Daviey, it's a ping with context ;)
[16:43] <Daviey> doko: can i give you a java ping? :)
[16:43] <doko> Daviey, I didn't manage to make 1.9 the default for the lts. but would it be possible to get your server applications running using ruby1.9 explicitly? it may make the support easier for the lts
[16:43] <doko> Daviey, are your minecraft games broken? ;-P
[16:43] <Daviey> doko / jamespage: Any idea what introduced bug 939631
[16:43] <Daviey> doko: heh
[16:44] <doko> Daviey, hmm, no
[16:45] <tkamppeter> pitti, sladen, larsu, I committed now a version with explicit build dependency on libfontconfig1-dev,
[16:45] <tkamppeter> pitti, can you upload this to Debian and Ubuntu, thanks.
[16:45] <Daviey> doko: Server flavour doesn't have an specific interest in ruby, there are a few things that are 'interesting' things for server.. but not something we are putting direct work into right now.
[16:46] <Daviey> doko: I really don't think we have the manpower to validate things against 1.9 atm.
[16:47] <Daviey> doko: puppet is probably the primary interest, but i'm nervous about committing to that.
[16:48] <pitti> tkamppeter: to Ubuntu is enough for now, thanks!
[16:50] <doko> Daviey, it maybe would be worth it (maybe jdstrand would like to comment too)
[16:50] <Daviey> lynxman: do you have the capacity to validate puppet against ruby1.9 atm?
[16:51] <lynxman> Daviey: puppet has unit tests so it's quite easy, I'll be glad to help
[16:51] <Daviey> lynxman: that would rock my world.
[16:52] <lynxman> Daviey: no prob, shall we wait for 2.7.11? or is it already in the Precise repo
[16:53] <lynxman> 2.7.10 was marked as a bad release
[16:54] <Daviey> lynxman: precise has .10
[16:54] <lynxman> Daviey: that's why I'm asking :)
[16:54] <infinity> Daviey: Speaking of puppet, do you know if IS's "we can't upgrade to precise because of puppet" issues have been resolved?
[16:54] <Daviey> lynxman: so does Debian, i think we are stuck with .10 unless you know something i don't?
[16:55] <infinity> Daviey: Or is that intractable client/server mismatch issue that just plain can't/won't be solved?
[16:55] <lynxman> Daviey: this thread http://groups.google.com/group/puppet-users/browse_thread/thread/f1e764d3b55cf968/8a65af62664fd06e?show_docid=8a65af62664fd06e&pli=1
[16:55] <lynxman> Daviey: 2.7.10 breaks a good list of regression tests
[16:56] <Daviey> infinity: sorry, i haven't been following that issue.. :(
[16:56] <jdstrand> Daviey, lynxman: we need 2.7.11 for a security update and because upstream has declared 2.7.10 'bad'
[16:56] <seb128> pitti, mdeslaur, slangasek: do you have any opinion on bug #939595 (from design)
[16:57] <seb128> pitti, mdeslaur, slangasek: i.e basically not forcing user to enter a secure password but just warn them
[16:57] <pitti> tjaalton: (CC: Riddell) on armhf we currently have
[16:57] <lynxman> jdstrand: that's why I was asking, saw your emails
[16:57] <pitti> libegl1-mesa: Depends: libwayland0 (= 0.1.0~2-1ubuntu1) but 0.85.0-1ubuntu1 is to be installed
[16:57] <pitti> which causes the mess on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[16:57] <Daviey> lynxman: OK... do you have capacity to look at a new upstream version of puppet, working against ruby1.9 .. discussing it with the DM's? :)
[16:58] <lynxman> Daviey: I do! Can do it tom morning if that's fine
[16:58] <lynxman> Daviey: or late tonight
[16:58] <mdeslaur> seb128: I'll respond
[16:58] <pitti> tjaalton: ah, so the new wayland also requires the new mesa, I see
[16:58] <seb128> mdeslaur, thanks
[16:58] <pitti> and it's building
[16:59] <infinity> Daviey: You might want to talk to some IS folks.  AFAIUI, puppet is the single reason they can't upgrade any individual machines to precise without doing the entire DC at once, or some such.
[16:59] <Daviey> lynxman: okay, it'll need an FFe.. but based on your input, upstream and jdstrand's.. it would seem like a good idea.
[16:59] <lynxman> Daviey: I think it'd be more than recommendable indeed
[16:59] <pitti> seb128: no strong opinion, but as we also offer autologin by default it makes sense for a desktop
[16:59] <jdstrand> does it actually need an FFe? it is both a security update and bug fix. upstream declared it as unsupportable
[16:59] <pitti> seb128: is it really g-c-c which adds obscure there?
[16:59] <lynxman> infinity: I reckon they can't upgrade yet due to something they're using that is kinda broken so they need to change their modules in order to upgrade (from the top of my head)
[16:59] <jdstrand> Daviey: ^
[17:00] <seb128> pitti, no, passwd behaves the same
[17:00] <slangasek> seb128: architecturally speaking, it's non-trivial to allow without making password strength checking useless in other cases
[17:00] <Daviey> jdstrand: well it no doubt introduces features?
[17:00] <slangasek> tkamppeter: 911436> no, 'triaged' means there's enough information for someone to work on it, not that someone is working on it yet
[17:01] <seb128> slangasek, ok, can you comment on the bug saying that and,or subscribe to the bug. Is there any way for a client (i.e g-c-c) to override this security?
[17:01] <jdstrand> Daviey: http://groups.google.com/group/puppet-users/browse_thread/thread/2d5daed2291962c2
[17:02] <jdstrand> Daviey: "The security changes in 2.7.11 address CVEs 2012-1053 and 2012-1054. The maintenance changes are to address regressions in 2.7.10."
[17:02] <Daviey> jdstrand: I sit corrected!
[17:02] <slangasek> seb128: the only way to bypass that is to set a password as root
[17:02] <jdstrand> https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.11
[17:02] <jdstrand> ok, I'll stop supporting myself then :)
[17:02] <slangasek> seb128: mdeslaur seems to have beat me to the bug :)
[17:02] <seb128> slangasek, mdeslaur: ok, thanks
[17:03] <lynxman> jdstrand: Daviey: so you want me to do the unit testing against ruby 1.9 before we get 2.7.11 into the archive or after?
[17:03] <jdstrand> lynxman: well, we need it in the archive regardless
[17:03] <Daviey> lynxman: makes sense to do it concurrently. :)
[17:04] <lynxman> jdstrand: yeah was just wondering the chicken and egg connundrum, its very ruby-esque
[17:04] <jdstrand> lynxman: are you planning to get 2.7.11 into the archive?
[17:04] <lynxman> jdstrand: hmm I could
[17:05] <jdstrand> lynxman: I just meant that whether we use 1.8 or 1.9, we need 2.7.11
[17:05] <lynxman> jdstrand: oh yeah definitely
[17:05] <lynxman> Daviey: I'll also ask the puppet core developers for extra reassurance, afaik puppet was almost 100% ruby 1.9 compatible on 2.7.2 already
[17:06] <jdstrand> lynxman: as for the timing of 2.7.11, I just figured someone would merge 2.7.11 when it hit Debian
[17:06] <jdstrand> lynxman: I'm guessing that will be soonish
[17:06] <seb128> mdeslaur, slangasek: I'm not sure I agree with the wontfix, the rational is raisonnable, there is no reason to force most users to set a complex password, i.e it seems a valid request to have g-c-c only giving you indication on how secure is your password, though I agree that if it's technically difficult to let g-c-c skip that security it might be wontfix for technical reasons
[17:06] <lynxman> jdstrand: yeah I reckon so as well
[17:06] <Daviey> lynxman: Have a conversation with the Debian Maintainers, always a shame to double up on workload.
[17:07] <jamespage> Daviey: I think it is moin that is pulling java into the mythubuntu precise build
[17:07] <lynxman> Daviey: ahoy
[17:07] <Daviey> jamespage: right!  Seems to be the case, but moin isn't in those seeds
[17:07] <mdeslaur> seb128: How about this compromise: we disable the password quality checking, but the default user isn't in the admin group? :)
[17:07] <Daviey> the moin mention in the platform seed has been there since 2009
[17:08] <seb128> mdeslaur, or how to make you box useless? ;-)
[17:08] <seb128> your
[17:08] <mdeslaur> seb128: useless but secure! :)
[17:08] <seb128> lol
[17:08] <seb128> mdeslaur, well I think for an home user it's reasonable to put a weak password
[17:09] <seb128> mdeslaur, like think a netbook your let around for free use (sort of tablet usage)
[17:10] <mdeslaur> seb128: removing the password quality check could be something that ubuntu-tweak could change
[17:11] <seb128> mdeslaur, well, the issue is default install, normal users don't got and install ubuntu-tweak
[17:11] <seb128> got->go
[17:14] <jamespage> Daviey: so is your question why is moin in the seed?
[17:15] <Daviey> jamespage: no, my question is why java is in seeds it wasn't previously.. :)
[17:16] <Daviey> i don't think it's moin related fwiw.
[17:16] <Daviey> i think it just /looks/ like it is.
[17:16] <didrocks> ev: I don't see any .so for whoopsie in activity-log-manager
[17:16] <Daviey> it's the reason, but not the cause, if that makes sense.
[17:16] <didrocks> ev: there is the .ui, the polkit part
[17:16] <tkamppeter> slangasek, bug 911436 causes around 5 new bug reports about CUPS update failures per day, therefore I was asking what the progress with this bug is.
[17:17] <ev> didrocks: indeed, it doesn't build a library for it
[17:17] <didrocks> ev: it's bundled into the a-l-m one?
[17:17] <didrocks> ok :)
[17:17] <ev> as it's being shoved into a tab in the a-l-m page
[17:17] <ev> so it doesn't need to create a library for g-c-c
[17:17] <jamespage> Daviey: I can see a [build]dependency chain from moin to java tho
[17:17] <ev> but it still needs the ui for itself and the dbus/polkit backend to apply the preferences
[17:17] <didrocks> ev: ok, wasn't sure it was or not really bundled, ok, make sense then! :)
[17:18] <pitti> janimo`, ogra_: !!!!!!!
[17:18] <pitti> https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.0-1ubuntu2/+build/3230659
[17:18] <ev> thanks for checking with me
[17:18] <ampelbein_> Can a arch-all package be forced to build on a specific architecture in ubuntu? In this case, openbios-ppc, needs to be built on a ppc arch. Is this what packages-arch-specific is for?
[17:19] <ogra_> pitti, yes ?
[17:19] <jamespage> Daviey: its in that seed for oneiric...
[17:19] <pitti> ogra_: well, it's the first time ever that it built on armhf
[17:19] <tkamppeter> pitti, OK, will upload itr to Ubuntu, we do the next synced upload with 1.0.3 with all the bugs on https://bugs.launchpad.net/bannertopdf fixed by larsu.
[17:19] <pitti> ogra_: it was responsible for 111 uninstallable packages on armhf, which should now be fixed
[17:19] <pitti> tkamppeter: already did
[17:19] <ogra_> pitti, yeah, janimo rocks !!!
[17:19] <ogra_> yippie
[17:20] <pitti> ogra_: and I switched http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html from armel to armhf now, as I understand it's our primary arm arch now?
[17:20] <ogra_> yep, armel is "community supported" now
[17:21] <ogra_> pitti, and armhf has to be supported by ubuntu platform since with monday the ubuntu-arm team is history
[17:22] <ogra_> (with help of the former ubuntu-arm team members indeed)
[17:28] <tkamppeter> pitti, thanks.
[17:28] <pitti> tkamppeter: it built everywhere now
[17:28]  * ogra_ sighs, thats the third xorg lockup today since i upgraded
[17:38] <hakaishi_> Hi, may I ask how to turn off the desktop effects with gnome3? Or how can I set gnome-fallback? Since the login doesn't work for me, I can't choose it there... How else can I set it?
[17:39] <arand> hakaishi_: That's probably a question for #ubuntu rather
[17:41] <hakaishi_> oh.. okay, thank you
[17:43] <hakaishi_> I'd like to mention something that bugs me quit a bit. I reported it here -> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/931565
[17:45] <lynxman> Daviey: by doing some bug hunting looks like 1.9 is still not fully supported (http://projects.puppetlabs.com/projects/puppet/issues?query_id=107) I'll get an answer from upstream in some hours as well
[18:04] <tjaalton> pitti: yeah we'll drop the hard dep since wayland is ~api stable
[18:12] <micahg> Riddell: why would you remove the flavor meta packages this would almost always seem to be the wrong thing to do
[18:24] <micahg> Riddell: can I just upload a new meta now for xubuntu and fix the greeter later tonight?
[18:24] <micahg> I'm really supposed to be working on other things during the day :)
[18:25] <ogra_> micahg, its evening here
[18:25] <ogra_> :)
[18:31] <slangasek> seb128: I rather agree with the wontfixing of that bug; I don't think insecure-by-default is reasonable.  Maybe this should be a topic for UDS so that we can discuss our options in finer detail?
[18:31] <slangasek> bdmurray: is there a bug pattern for bug #911436 that tkamppeter mentions (far) above?  we should probably be blocking those
[18:32] <seb128> slangasek, yes, I'm fine with the current situation for precise, I just think it's a valid request
[18:32] <seb128> slangasek, I don't agree that allowing bypassing the weak password warning is "insecure-by-default" though
[18:32] <seb128> slangasek, there is plenty of users who don't need a password, especially not an hard one
[18:33] <slangasek> then let them configure their system for passwordless autologin
[18:33] <slangasek> the threshold for "hard" passwords is not particularly high
[18:33] <seb128> slangasek, well, we don't offer them that option
[18:33] <slangasek> we don't?
[18:33] <bdmurray> slangasek: yes, I'll make sure it is working
[18:33] <seb128> the installer has autologin, password, or protected
[18:34] <seb128> not passwordless
[18:34] <slangasek> bdmurray: ta
[18:34] <slangasek> seb128: from the installer you can set as weak a password as you want, too, because that's done as root
[18:34] <slangasek> so this seems to only be a problem for users who are somehow concerned about password rotation but not password strength? :)
[18:34] <seb128> slangasek, well, another reason to let g-c-c do the same as the installer
[18:34] <seb128> slangasek, I don't think it's a real problem in practice
[18:35] <seb128> but I got annoyed by it as well in the past and wished the g-c-c dialog would let you click "I know I'm setting an insecure password but that's fine, I can deal with it"
[18:35] <slangasek> well, if you can arrange for g-c-c to invoke passwd as root, you can do that
[18:36] <mdeslaur> hrm, it appears g-c-c fails miserably if it gets a failure on the first try
[18:37] <seb128> slangasek, I think the issue is not worth the effort, I'm fine with the Opinion status ;-)
[18:37] <seb128> I just found the request fair on theory
[18:38] <slangasek> you're cutting a fine line between wontfix and opinion ;)
[18:38] <seb128> slangasek, well the comment mdeslaur added was rather a "we won't do it because we don't like the idea"
[18:38] <seb128> rather than "we won't do it because it's work and we have better things to do"
[18:39]  * slangasek nods
[18:41] <slangasek> jibel, mvo: do you know why https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/30/artifact/lts-main-all-amd64/apt-term.log only shows packages being removed?  This seems to be a log from the second apt pass of the upgrade, where no-longer-needed packages are being removed
[18:42] <slangasek> ah, no mvo
[18:43] <barry> mdke: https://bugs.launchpad.net/ubuntu-docs/+bug/939729
[18:44] <sladen> larsu: tkamppeter: there might be a regression in there.  It's trying to print a testpage that is page size 'iP-B4'
[18:44] <sladen> larsu: presumably the PDF that is going out of the door is oversize, and/or not being cropped/forced to the printer papersize setting
[18:46] <larsu> sladen, sounds like the next bug on my list: https://bugs.launchpad.net/bannertopdf/+bug/921073
[18:46] <sladen> larsu: tkamppeter: or.  perhaps something bigger.  http://localhost:631/printers/Canon-iR-ADV-C5000s-B1-PS-V1.0  shows "PDF files is damanged - attempting to reconstruct xref table"
[18:47] <larsu> sladen, okay that sounds like a different thing. I have to go off now, I'll look into it tomorrow. Which PPD are you using for that printer?
[18:48] <sladen> larsu: "Generic PostScript Printer Foomatic/Postscript (recommended) (color, 2-sided printing)"
[18:48] <larsu> sladen, thanks. See you tomorrow!
[18:57] <bryceh> @pilot in
[18:57] <slangasek> jibel: ahwell, tried to post to ubuntu-qa@lists and I'm in the mod queue, hopefully someone can approve me :)
[19:02] <bdmurray> slangasek: is there some way I could recreate that bug?  there are some bugs that were reported matching the pattern and I'd like to sort out why
[19:02] <slangasek> bdmurray: if you dpkg --unpack the new version of the package providing the conffiles in question, without dpkg --configure'ing it, that should let you reproduce it
[19:23] <apw> slangasek, which package does one file a bug aginst for the 'pretty stufff' one sees during install
[19:25] <mr_pouit> xubuntu-default-settings_12.04.7_all.deb (19.1 KiB) NEW <<< Riddell: I don't know why you removed the package, but that's really messed up
[19:27] <lamefun2> does Software Center implement AppStream?
[19:28] <ogra_> apw, ubiquity-slideshow-ubuntu ?
[19:29] <apw> ogra_, sounds plausible ... title still says 11.10
[19:29] <ogra_> the other option would be ubiquity itself i guess
[19:33] <stgraber> apw: I think I saw at least 150 people report that bug ;)
[19:33] <stgraber> apw: so feel free to click on "affects me too" but I guess we're waiting on a completely new slideshow so it's not worth fixing the current one really
[19:34] <stgraber> apw: ev would know the details
[19:35] <apw> stgraber, heh nope as long as its there, i wish the duplicate detection ever found anything
[19:35] <stgraber> apw: most people reported the issue against ubiquity instead of the slideshow
[19:36] <apw> yeah, but you'd think they'd all find the duplicate ... but hey
[19:36] <ogra_> if you use ubuntu-bug it does that for you :)
[19:36] <stgraber> https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/899503 is the master bug I believe
[19:36] <apw> ogra_, in theory, though most of the bugs i filed this week had duplicates it couldn't point me to
[19:37] <ogra_> wow
[19:37] <apw> perhaps my use of english is just toooo odd to match
[19:37] <ogra_> well, i'm probably spoiled by dealing with arm ... where we have only 1% of the open bugs
[19:37] <ogra_> or 0.1%
[19:37] <ogra_> or so
[19:38] <stgraber> ogra_: I can give you half of the ubiquity ones, then you'll have plenty to go mark as dupe and test apport on ;)
[19:38] <ogra_> stgraber, lets talk about that next week :)
[19:38] <stgraber> ogra_: ;)
[19:38] <ogra_> today and tomorrow i'm teamless ... from monday on we're teammates :)
[19:41] <infinity> Dear chrimium, paths like these really inspire confidence:   CXX(host) out/Release/obj.host/protobuf_full_do_not_use/third_party/protobuf/src/google/protobuf/generated_message_reflection.o
[19:41] <infinity> chromium, too.
[20:11] <cnd> where's the release notes so I can add something about clickpads?
[20:11] <cnd> bryceh ^^?
[20:15] <bdmurray> cnd: hard to say https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
[20:16] <jbicha> barry: can you try rebuilding ubuntu-docs? it should build now that itstool has been updated to not fail on translation errors
[20:23] <barry> jbicha: will do, thanks
[20:30] <sveinse> On a Natty system in an upstart service, do I need to use su to be able to run the service as a non-privileged user. Are there other ways?
[20:30] <sveinse> The app does not support setuid(), so it need to be demoted prior to its execution
[20:32] <bryceh> skaet, ^^ see cnd's q about the release notes for beta1
[20:36] <barry> jbicha: yay!  ubuntu-docs rebuilt successfully
[20:36] <skaet> bryceh, cnd - just put the comments you want in https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview itself right now.   I'll be populating the template into it tomorrow, and will carry make sure that any comments added to the wiki page are included.
[20:38] <jbicha> barry: thanks, I probably should have found someone to try rebuilding it sooner
[20:38] <barry> jbicha: no worries at all, thanks for letting me know
[20:42] <cnd> skaet, bryceh, thanks!
[20:42] <bryceh> skaet, thanks
[20:57] <bryceh> @pilot out
[21:03] <slangasek> sveinse: you should use start-stop-daemon, not su; su starts a PAM session, which you don't want for a system service
[21:26] <slangasek> broder: I haven't seen any new SRU uploads for bug #858122, are you still working on that?
[21:26] <broder> slangasek: yeah, real work just got in the way. i think i can get something uploaded today
[21:27] <slangasek> broder: ok, cheers :)
[21:42] <sveinse> slangasek: On my system it seems start-stop-daemon is associated with /etc/init.d and not /etc/init. So using start-stop-daemon from an upstart script is not frowed upon?
[21:43] <slangasek> sveinse: start-stop-daemon is part of dpkg; you'll find much more use of it in /etc/init.d than in /etc/init, because many of the things it does are not needed with upstart.  But uid switching is one use case where it's still the right tool, at least up until upstart 1.4.
[21:44] <sveinse> yes. thanks
[21:44] <slangasek> in contrast, su is always wrong in an upstart system job :)
[21:47] <micahg> does someone want to tackle bug 939842, this is the second one I saw for it
[21:48]  * slangasek blinks
[21:48]  * micahg is also confused by it, but didn't look into it
[21:48] <slangasek> kind of a gratuitous collision
[21:48] <broder> didn't ev say yesterday that he was rolling whoopsie into the activity log?
[21:49] <slangasek> I don't know
[21:49] <seb128> he said he would roll the preference ui there
[21:49] <seb128> but that's only part of whoopsie I think
[21:49] <seb128> it's maybe missing a conflicts,replace
[21:49] <slangasek> breaks/replace
[21:49] <seb128> whoopsie-daisy (0.1.11) precise; urgency=low
[21:50] <slangasek> but yeah
[21:50] <seb128>   * Drop the GNOME Control Center page for controlling crash reporting.
[21:50] <seb128>     This has been moved into the activity-log-manager package and these
[21:50] <seb128>  
[21:50] <seb128> seems so
[21:50] <slangasek> mmk
[21:50] <slangasek> seb128: shall I upload?
[21:50] <seb128> slangasek, feel free
[21:51] <slangasek> Breaks: whoopsie (<< 0.1.10)
[21:51] <slangasek> offbyone
[21:51] <seb128> indeed ;-)
[21:56] <slangasek> seb128, micahg: uploaded
[21:57] <micahg> thanks
[21:58] <bdrung> cyphermox: re bug #869635, i have not enough time to digg out the patches. i am happy to test patches if they are easily installable.
[21:59] <cyphermox> bdrung: well, really it's patches to NM, wpasupplicant and isc-dhcp, it all need to land to notice much changes
[21:59] <cyphermox> bdrung: I'll see if I can put all this in a PPA, but complexity seems kind of high for a SRU
[21:59] <seb128> slangasek, thanks
[22:01] <micahg> anyone know offhand where the proper place to set CHROOT_MOUNT_LOCATION for schroot is?
[22:02] <slangasek> I'm surprised you would want to set it
[22:02] <slangasek> what's wrong with the provided default?
[22:03] <micahg> slangasek: not enough space on the partition
[22:03] <slangasek> not enough space to *mount*?
[22:03] <slangasek> that doesn't make sense
[22:04] <slangasek> what is it you're actually trying to change :)
[22:04] <slangasek> CHROOT_MOUNT_LOCATION is only the mount point
[22:04] <micahg> oh, where the chroot is being used
[22:04] <micahg> ah, yeah, that's not right then
[22:05] <slangasek> is this a type=directory chroot?
[22:05] <slangasek> you probably need to fiddle with /etc/schroot/schroot.conf, I think
[22:05] <micahg> ok, I think I know what I messed up, thanks
[22:16] <lamont> dpkg: serious warning: files list file for package `libmount1' missing, assuming package has no files currently installed.
[22:16] <lamont> what does that mean? ^^ slangasek ?
[22:17] <slangasek> lamont: er, are you mixing multiarch and non-multiarch dpkg?
[22:17] <lamont> does it mean that I needed to do more than just remove /etc/dpkg/dpkg.cfg.d/multiarch to disable multiarch?
[22:17] <lamont> oh.  yeah maybe
[22:18] <slangasek> it means the version of dpkg you're running doesn't *see* /var/lib/dpkg/info/libmount1:$arch.list because it doesn't have multiarch support
[22:18] <slangasek> there's no supported downgrade path there
[22:18] <slangasek> (actually, I think there technically is a supported downgrade path, but I suspect you've actually done a cross-grade)
[22:19] <slangasek> you can manually move the files around in /var/lib/dpkg/info if you need to
[22:19] <lamont> slangasek: worse.  I'm running dpkg outside of the chroot.  thank you for diagnosing my pain
[22:19] <slangasek> :)
[22:19] <lamont> I shall now go find a corner to bang against
[22:23] <Daviey> infinity: Do you plan to fix bug 759545? :)
[22:25] <SpamapS> Shouldn't the channel topic say Beta Freeze in effect?
[22:25] <Laney> yes, and luckily it isn't locked so anyone can do it
[22:25] <Laney> ;-)
[22:26] <slangasek> words, words
[22:27] <Laney> do-ocracy
[22:28] <slangasek> :P
[23:49] <doko> slangasek, about but 927423, is this seen for openjdk-6 as well?
[23:49] <doko> bug 927423
[23:55] <slangasek> doko: it hasn't been reported for -6, so I don't know
[23:55] <slangasek> I don't see it here on my continuously-upgraded system
[23:56] <slangasek> nor in a clean chroot with -6
[23:56] <doko> slangasek, just to confirm, you don't see it on 7 either?
[23:57] <slangasek> I'm not using -7 and haven't tested... I happened to have a chroot around with -6 installed
[23:58] <doko> ok