[00:06] <robert_ancell> StevenK, can you sync glib-networking and libsoup2.4 from debian experimental?  Do you need bugs (we have no Ubuntu changes, we just need to keep syncing until stable release)
[00:08] <StevenK> robert_ancell: Again? :-)
[00:09] <robert_ancell> StevenK, yeah, GNOME keeps making releases!
[00:09] <StevenK> Bad!
[00:09] <robert_ancell> they have a schedule and everything
[00:30] <cnd`> Riddell, are you on?
[00:30] <cnd`> I think a net split has screwed things up on me
[01:18] <NCommander> @pilot out
[03:03] <bjf> i'm thinking now is not a good time to get today's updates: an apt-get dist-upgrade says that "The following packages will be REMOVED: ubuntu-desktop"
[04:23] <broder> jcastro: i don't need to worry if i submitted my uds sponsorship app before jono's post, do i?
[05:14] <micahg> @pilot in
[06:05] <micahg> can we upload from a UDD branch without an upstream tag?
[07:23] <janimo> doko_, him what exactly should I check after eglibc build finishes?
[07:23] <doko_> janimo: just installation and desktop start, I'll look at the test results too
[07:23] <pitti> kees: argh, then what I have seen must have been the .91 result
[07:24] <janimo> doko_, for the packages listed in that PPA?
[07:24] <doko_> janimo: just eglibc
[07:25] <janimo> ahuman, ok
[07:25] <janimo> ahuman, ok
[07:25]  * janimo hits xchat autocompletion
[07:32] <dholbach> good morning
[07:32] <RAOF> Anyone have touchpad problems since the most recent Xserver/synaptics upgrade?
[07:33] <RAOF> If so, we want you!
[07:34] <htorque_> RAOF, http://ubuntuforums.org/showthread.php?t=1694007
[07:35] <bryce_> booyah
[07:35] <bryce_> htorque_, awesome
[07:36] <RAOF> Bah.  They haven't tried rolling back to the previous synaptics. :)
[07:36] <htorque_> just doing updates, maybe i'm hit too
[07:40] <RAOF> That would be helpful; I don't have access to any systems which are broken.
[07:42] <htorque_> RAOF, :( touchpad's working fine here
[07:42] <bryce_> RAOF, can you attach a downgrade script on bug #724051?
[07:42] <bryce_> RAOF, then I guess reassign the bug to cnd - will you be around when he gets up?
[07:43] <RAOF> I can be around, yes.
[07:43] <bryce_> alright, I'll check in on things in my morning
[07:44] <RAOF> I'll do so.
[07:53] <didrocks> good morning
[07:54] <RAOF> Hey didrocks.  How's your touchpad? :)
[07:55] <didrocks> RAOF: hum, alive, why? ;)
[07:56] <RAOF> Oh, I'm just looking for someone who can reproduce bug #724051 :)
[07:56] <RAOF> It doesn't affect any of the hardware any of us X maintainers have access too.
[07:56] <didrocks> RAOF: not sure I'm on that version because of nvidia :)
[07:56] <RAOF> Man up and install nouveau! :P
[07:57] <didrocks> RAOF: I prefer to keep what we install to our users :)
[07:57] <didrocks> and not triggers new bugs
[07:58] <RAOF> Eh.  Supported 3D drivers are for the weak!
[08:02] <didrocks> ;)
[08:06] <pitti> apw: yes, apparently language-selector was gratuitously renamed to l-s-gnome in 0.14, and the seeds weren't updated, and there is no transitional package iether
[08:07]  * pitti cleans up behind that
[08:09] <pitti> Riddell: ^ (that sponsored l-s was pretty broken..)
[08:21] <micahg> @pilot out
[08:24] <cdbs> micahg: :o
[08:24] <cdbs> micahg: nice job!
[08:50] <apw> pitti, thanks for hoovering up
[08:53] <jamespage> doko_, asac, didrocks: do any of you have time to look at a long standing MIR for me?
[08:54] <didrocks> jamespage: not from me, sorry :/ I finished a last MIR round yesterday but I won't be available at all today for that. Maybe ask mterry when he's here
[08:58] <jamespage> didrocks: I'll pester mterry when he appears then unless doko_ or asac can help me out :-)
[09:26] <tkamppeter> pitti, hi
[09:28] <pitti> hey tkamppeter, how are you?
[09:30] <tkamppeter> pitti, fine. Did you solve the problem of the automatic printer driver download not working with proxies completely?
[09:36] <pitti> tkamppeter: I think so; I responded to the mail with some further questions, but didn't get a response
[09:36]  * pitti digs out the old mail
[09:37] <tkamppeter> pitti, I have digged it out, too. Yuji Saito from Avasys never responded.
[09:38] <tkamppeter> pitti, I have sent a reminder now.
[10:03] <mdz> seb128, my nautilus crasher bug 724202 is retraced now, and the stack has image_notify_cb rather than theme_changed_cb as in bug 721915. are you sure it's the same?
[10:06] <didrocks> seb128: pitti: I think that we should rename the compiz-fusion package to compiz as upstream has this name since 0.9. Is there a process for blacklisting sync from debian as they still have the old source package name?
[10:06] <seb128> mdz, no, seems different, the other bug you pointed was a duplicate
[10:06] <mdz> oh
[10:06] <pitti> didrocks: yes, add it to /srv/launchpad.net/dak/sync-blacklist.txt
[10:07] <pitti> didrocks: that is a bzr dir, so please commit the change as well
[10:07] <seb128> mdz, I wish the retracers were working but gdb 6.8 produce broken stacktrace and gdb 7.2 is broken in the fakechroot environment
[10:07] <didrocks> pitti: excellent, thanks :)
[10:07] <seb128> didrocks, see 5.2 on https://wiki.ubuntu.com/ArchiveAdministration
[10:07] <mdz> seb128, also, the "usr_lib_nautilus" info from the apport hook is hard to read because there's no whitespace between the items. would you like a trivial patch for that?
[10:07] <mdz> e.g. usr_lib_nautilus: nautilus 1:2.32.2.1-0ubuntu6ubuntuone-client-gnome 1.5.4-0ubuntu1ubuntuone-client-gnome 1.5.4-0ubuntu1file-roller 2.32.1-0ubuntu3evince 2.32.0-0ubuntu10seahorse-plugins 2.30.1-3ubuntu2brasero 2.32.1-0ubuntu2deja-dup 17.90-0ubuntu3ubuntuone-client-gnome 1.5.4-0ubuntu1deja-dup 17.90-0ubuntu3deja-dup 17.90-0ubuntu3gnome-disk-utility 2.32.1-0ubuntu4nautilus-share 0.7.2-14ubuntu1totem 2.32.0-0ubuntu9nautilus-sendto 2.32.0-0ubuntu1quick
[10:07] <mdz> ly-ubuntu-template 11.03.1-0ubuntu2
[10:07] <mdz> I think putting newlines in there would be good
[10:08] <didrocks> seb128: yeah, I read this, I was thinking about "official process" like sending an email or opening a bug :)
[10:09] <pitti> didrocks: I don't quite understand -- our compiz source package is already called compiz, not compiz-fusion?
[10:09] <seb128> mdz, that would be better indeed, I think they used to have space or new lines, I'm wondering if anything changed from the apport side, any patch would be welcome ;-)
[10:09] <didrocks> pitti: the main and other plugins
[10:09] <didrocks> pitti: those are multiple source packages
[10:10] <didrocks> pitti: compiz-fusion-plugins-main for instance
[10:10] <seb128> mdz, do you still have the .crash for this nautilus crash?
[10:13] <seb128> mdz, #526743 has http://launchpadlibrarian.net/39673544/usr_lib_nautilus.txt
[10:13] <mdz> seb128, yes I do
[10:13] <seb128> mdz, i.e the list used to be a file and not inlined, not sure what changed
[10:13] <mdz> seb128, apport automatically inlines it if it is <5 lines or so
[10:14] <seb128> mdz, well, the source_nautilus.py didn't change and it used to have new lines, anyway that's a detail
[10:15] <mdz> seb128, that's very weird, looking at the hook I do not see how it could have newlines
[10:15] <mdz> if it did, it would probably be a bug in hookutils.package_versions
[10:15] <siretart> do we have plans to remove qt3 from natty?
[10:15] <seb128> mdz, can you install libdbusmenu-gtk3-dbgsym libdbusmenu-glib3-dbgsym and get a stacktrace from using gdb on the crashdump or use apport-retrace locally?
[10:15] <seb128> mdz, right
[10:16] <bdrung> raphink: re http://www.raphink.info/2011/02/version-number-suggests-ubuntu-changes.html - the correct way to deal with it is to run update-maintainer once you modified the changelog
[10:16] <mdz> seb128, I can apport-retrace locally, sure
[10:16] <siretart> I'm getting bugged about a package that uses qt3, which is supposed to be removed from unstable 'in the next 3 months'
[10:16] <seb128> mdz, the retracers are screwed, they still run gdb 6.8 because 7.2 is borked under fakechroot or something and 6.8 has issues in natty now
[10:16] <seb128> pitti tried to debug it without success
[10:16] <pitti> to be precise, gdb 7.2 was just as broken locally with core dumps
[10:16] <seb128> you picked a broken example
[10:16] <pitti> none of the three bugs I tried it with had any difference in the retracer chroot vs. local gdb 7.2
[10:17] <pitti> seb128: maybe, I could have been unlucky
[10:17] <seb128> I can give you way to try easily on a running process
[10:17] <seb128> 6.8 doesn't work here
[10:17] <pitti> I checked strace on 7.2 in the retracer chroots, there were no obvious errors which looked like being fakechroot bugs
[10:17] <seb128> where 7.2 does
[10:17] <mdz> why does apport-retrace give me so many warnings about unavailable -dbg and -dbgsym packages? they should be available
[10:17] <pitti> seb128: I didn't try that, just gdb program core
[10:18] <pitti> mdz: the -dbg ones are bad warnings and fixed in trunk; -dbgsym> do you have ddebs.u.c. apt source?
[10:18] <seb128> pitti, let me see if we have some apport-failed-retracing bugs with an i386 dump on launchpad today
[10:18] <seb128> so I can try that as well
[10:21] <mdz> dpkg: error processing /var/cache/apt/archives/nautilus-dbg_1%3a2.32.2.1-0ubuntu6_amd64.deb (--unpack):
[10:21] <mdz>  trying to overwrite '/usr/lib/debug/usr/lib/libnautilus-extension.so.1.2.0', which is also in package libnautilus-extension1-dbgsym 1:2.32.2.1-0ubuntu6
[10:22] <seb128> doh
[10:22] <seb128> that could explain broke retracings as well
[10:22] <seb128> pitti, is installing the -dbg a new thing?
[10:22] <pitti> not really, they use -u --no-pkg
[10:23] <pitti> seb128: adding -dbg is a relatively new thing, it was contributed by someone who said it'd improve things
[10:23] <pitti> mdz: for local retraces you might try removing line 426 in /usr/lib/python2.7/dist-packages/apport/packaging_impl.py
[10:23] <pitti> i. e.
[10:23] <pitti>                     dependency_versions[pkg+'-dbg'] = dependency_versions[pkg]
[10:24] <raphink> bdrung, like I said, the maintainer is a canonical employee
[10:24] <raphink> bdrung, so I'm not sure updating the maintainer is the best option
[10:24] <bdrung> raphink: that's not a reason to not change the maintainer
[10:25] <pitti> brb
[10:27] <varunthacker> has the ideas list for GSOC 2011 from Ubuntu been released yet?
[10:27] <pitti> seb128: just to make sure we could of course remove -dbg package installation from the retracers as well
[10:28] <pitti> seb128: (sorry, currently working on somethign else)
[10:28] <seb128> pitti, well it seems likely the crash mdz just had will break the installation and the retracing
[10:28] <seb128> not sure what we win from using the dbg when everything has a dbgsym
[10:29] <mdz> seb128, I have a patch for the apport hook for you. email, bug report or bzr?
[10:29] <pitti> seb128: it was added becuase a lot of dbgsym are missing
[10:29] <seb128> mdz, either work, what is easier for you
[10:29] <pitti> seb128: it's slightly better in trunk now
[10:29] <seb128> mdz, or just commit and push if you worked on a checkou
[10:29] <seb128> checkout
[10:30] <seb128> pitti, well it seems obviously broken if it install conflicting dbg and dbgsym binaries, I would turn it off until someone debug it
[10:30] <mdz> seb128, emailed
[10:30] <seb128> mdz, thanks
[10:30] <mdz> there was also a weird issue where attach_gconf was called but not imported
[10:31] <mdz> something else must have imported it, because it seemed to work
[10:32] <mdz> pitti, sorry, missed your earlier question: yes, I do have the ddebs source
[10:32] <mdz> deb http://ddebs.ubuntu.com/ natty main restricted universe multiverse
[10:32] <raphink> bdrung, nxvl is still the official maintainer (unless you want to change that nxvl )
[10:33] <mdz> but I get e.g. WARNING: package libxcb1-dbgsym not available
[10:33] <raphink> bdrung, afaik, the Maintainer field is not supposed to be changed at every upload
[10:33] <mdz> pitti, and removing line 426 helped a lot, thanks
[10:34] <bdrung> raphink: but on every merge
[10:34] <raphink> it's not a merge
[10:34] <mdz> seb128, I have a gdb session for my nautilus crash now
[10:34] <pitti> mdz: that's actually correct, libxcb1-dbgsym is missing from http://ddebs.ubuntu.com/pool/main/libx/libxcb/
[10:34] <pitti> (meh - want soyuz ddeb support enabled..)
[10:35] <seb128> pitti, it's not?
[10:35] <seb128> http://ddebs.ubuntu.com/pool/main/libx/libxcb/libxcb1-dbgsym_1.5-2_amd64.ddeb
[10:35] <mdz> seb128, backtrace in http://paste.ubuntu.com/571641/
[10:35] <pitti> seb128: that yes, but 1.7-2 is current
[10:35] <seb128> oh right
[10:35] <pitti> the udeb dbgsym made it for some strange reason
[10:36] <seb128> mdz, hum, it's not better than the retracer one
[10:38] <mdz> seb128, stack frame #2 has the same address as the data= parameter to the callback
[10:38] <mdz> that doesn't seem right
[10:38] <mdz> #1  0x00007f16efdcba9e in image_notify_cb (widget=0x2718810,
[10:38] <mdz>     pspec=<value optimised out>, data=0x2026120)
[10:38] <mdz> #2  0x0000000002026120 in ?? ()
[10:39] <seb128> indeed
[10:39] <mdz> I'm not surprised it can't find any debug symbols for the stack :-)
[10:40] <mdz> I don't know what's wrong with #4 though, that one looks like a shared library
[10:40] <seb128> mdz, thanks for trying locally, so it's a different issue from the retracer one
[10:40] <seb128> mdz, the ProcMaps has no mapping for it though
[10:40] <seb128> "7f16e0000000-7f16e02d9000 rw-p 00000000 00:00 0
[10:40] <seb128> 7f16e02d9000-7f16e4000000 ---p 00000000 00:00 0 "
[10:41] <mdz> weird
[10:41] <pitti> seb128: indeed gdb 7.2 works just fine if I run it against a "synthetic" core file in the retracer chroot; so perhaps 7.2 is more sensitive to missing dbg symbols than 6.8, so that it produces much worse results on incomplete dbgsyms?
[10:42] <seb128> pitti, could be
[10:42] <seb128> should we just upgrade the version in the retracer and see how it goes?
[10:42] <pitti> we could, sure
[10:43] <pitti> seb128: FTR, I'm commenting out the pinning in /etc/apt/preferences
[10:43] <seb128> pitti, ok thanks
[10:44] <pitti> it'll get even worse, though
[10:45] <seb128> pitti, why?
[10:45] <pitti> as I said, all retraces I tried got worse with 7.2
[10:46] <pitti> but let's try this for a few days and review how they look nw
[10:46] <pitti> now
[10:50] <seb128> pitti, you can take https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/719156 as an i386 example
[10:50] <seb128> pitti, gdb on the dump locally produce a better stacktrace
[10:50] <pitti> ah, good; trying
[10:51] <seb128> pitti, http://paste.ubuntu.com/571646/
[10:51] <seb128> pitti, is what I get on my natty box with the dump from this bug
[10:51]  * pitti runs that in the retracer
[10:52] <seb128> pitti, compared to http://launchpadlibrarian.net/64377347/Stacktrace.txt
[10:52] <seb128> which is what the retracer got
[10:56] <pitti> looks better now
[10:57] <pitti> still a lot of "No symbol table info available.", but at least I get a similar stack to your's
[10:59] <pitti> seb128: ^ ok, so let's run with that for a bit and cross fingers :)
[11:05] <seb128> pitti, ok!
[11:05] <seb128> pitti, do you need to keep the bug as an example or can I retag it need-i386-retrace?
[11:06] <pitti> seb128: you can re-tag it
[11:06] <pitti> seb128: in fact, let's do that and see what the fully automatic mode makes of it
[11:06] <seb128> let's see how it goes
[11:06] <seb128> pitti, right
[11:06] <seb128> tagged
[11:06] <seb128> pitti, the retracers are on?
[11:06] <seb128> pitti, next cronjob is in 1 minute iirc
[11:09] <pitti> yes
[11:10] <PetrHH> Hello
[11:11] <PetrHH> I'd like to release my app as version 1.0.0 alpha1
[11:11] <PetrHH> and create my own repository
[11:12] <PetrHH> How apt recognize new version of my app, after I relase 1.0.0 alpha 2?
[11:13] <PetrHH> Yes, I'll put version in changes file but I'm afraid if it will work.
[11:13] <raphink> PetrHH, apt bases itself on version number
[11:13] <raphink> you can use dpkg --compare-versions $v1 lt $v2 && echo y || echo n
[11:13] <raphink> to see which version dpkg/apt consider higher
[11:14] <raphink> PetrHH, as far as versionning an alpha1 program, you sould use 1.0.0~alpha1 as the version, because ~ will make sure that 1.0.0~alpha1 come before 1.0.0
[11:14] <raphink> so the package will be upgraded when 1.0.0 is out
[11:15] <PetrHH> raphink, Thank you for explanation
[11:15] <PetrHH> and will be upgrade also after I release alpha2 or beta1?
[11:16] <raphink> yes PetrHH
[11:16] <PetrHH> Great! Thanks a lot.
[11:16] <raphink> 1.0.0~alpha1 < 1.0.0~alpha2 < 1.0.0~beta1 < 1.0.0~rc1 < 1.0.0~rc2 < 1.0.0
[11:17] <raphink> thanks to the alphabetical order in which a < b < r
[11:17] <PetrHH> it is great
[11:17] <PetrHH> so I'll use ~
[11:17] <raphink> yes
[11:17] <PetrHH> Do you know any good how to create own Ubuntu repository?
[11:18] <raphink> and the first package version will be 1.0.0~alpha1-0ubuntu1
[11:18] <raphink> if you use a PPA and you plan to get your package in Ubuntu one day, the version will be something like
[11:18] <raphink> 1.0.0~alpha1-0ubuntu1~ppa1
[11:18] <raphink> -0ubuntu indicates that it's the first version in Ubuntu, not based on a Debian version (hence the -0)
[11:19] <raphink> and ~ppa1 makes it a private PPA version that comes before the official one, so if ever your package ends up in Ubuntu officially, the official version will replace the PPA one
[11:20] <PetrHH> I don't know how to use ppa. I'm already registered but my program needs CVS version of IDE to be build. So I must wait till new version will be released and added to Ubuntu repository. Because of this, I'd like to create own repo, first.
[11:20] <raphink> a PPA is a personal repository, that's what you want I think
[11:20] <raphink> if you have an account on Launchpad, just go to your page and activate your PPA
[11:20] <raphink> it's much (much) easier than setting up your own local repository
[11:21] <raphink> https://help.launchpad.net/Packaging/PPA
[11:25] <PetrHH> Can I use packages from external repository?
[11:26] <raphink> what kind of external repositories?
[11:26] <PetrHH> My development enviroment is there
[11:26] <PetrHH> SVN version of it
[11:26] <raphink> PPAs can depend on official repositories as well as other PPAs
[11:28] <PetrHH> great!
[11:28] <PetrHH> hopefully it is also in ppa :-)
[11:28] <mdz> pitti, are you going to remove the -dbg thing or keep it?
[11:29] <pitti> mdz: it's already much better in trunk
[11:29] <mdz> ah
[11:29] <pitti> mdz: in the retracer chroots it increases the chance of getting debug symbols, as long as ddebs.u.c. i still separate and unreliable, so I'd actually like to keep it
[11:29] <pitti> mdz: I could only enable it if --no-pkg is given, though
[11:29] <pitti> that should DTRT on local retraces
[11:30] <ricotz> who is the current friendly archive-admin for NEW package reviews?
[11:30] <mdz> pitti, --no-pkg isn't on the man page; does that just unpack the debs without dpkg?
[11:30] <pitti> mdz: yes
[11:30] <ogra> ricotz, look at the wiki
[11:30] <pitti> mdz: it's actually kind of deliberate
[11:30] <mdz> heh
[11:30] <pitti> mdz: you shoudl never ever use that option on a real system
[11:31] <pitti> it's going to mess up everything
[11:31] <pitti> mdz:  --help has it
[11:32] <pitti> mdz: committed to trunk
[11:32] <ricotz> ogra, thanks, which specific page would that be?
[11:33] <mdz> pitti, if it only unpacks things in /usr/lib/debug, that doesn't sound so bad
[11:33] <pitti> mdz: no, that applies to all packages
[11:33] <mdz> oh
[11:34] <pitti> mdz: I get too much breakage with using dpkg in fakechroots, and it's also taking too much time
[11:34] <ogra> ricotz, ArchiveAdministration
[11:34] <mdz> pitti, even with --force-unsafe-io?
[11:34] <pitti> and as the entire chroot is just wiped after retracing, I don't care about the packaging system
[11:34] <pitti> mdz: it's due to all the maintainer scripts, preinsts, etc., not so much due to I/O (which is slow either way)
[11:35] <cjwatson> pitti: could you please push the final commit(s) in udev 166-0ubuntu1?
[11:35] <mdz> ah, right
[11:35] <mdz> I keep forgetting that the retracer has to install regular packages as well, not only the -dbgsyms
[11:35] <ricotz> ogra, ty
[11:35] <pitti> cjwatson: done, sorry
[11:35] <cjwatson> thanks.  it's broken d-i and I wanted to investigate
[11:35] <PetrHH> raphink, So it is not. I must wait till Carlos Laviola update his ppa to new version and developers release it. Two dayes a go, the created brach in svn for new release but still no official release4 info on their website.
[11:36] <Riddell> janimo: you fixed the python-qt on ARM issue?!
[11:36] <pitti> cjwatson: you mean the last upload? 165-0ubuntu2 still worked?
[11:36] <cjwatson> not certain
[11:36] <cjwatson> think so though
[11:36] <pitti> interesting, the diff is tiny
[11:36] <cjwatson> I think I know what it is
[11:37] <janimo> Riddell, with the new uploaded package it works locally.
[11:37] <cjwatson> a bunch of the _id tools moved to be guarded by --enable-extras
[11:37] <janimo> Riddell, unfortunatly it does not build on buildd and I am not sure why
[11:37] <cjwatson> I'll figure it out and fix it up
[11:37] <pitti> cjwatson: ah, we do need the extras in the udev?
[11:37] <pitti> ok, thanks
[11:37] <janimo> Riddell, http://launchpadlibrarian.net/65061885/buildlog_ubuntu-natty-armel.python-qt4_4.8.3-0ubuntu3_FAILEDTOBUILD.txt.gz
[11:38] <janimo> Riddell, the pyqt4 issue was fixed a while ago but the fix dropped recently hence the current FTBFS list
[11:38] <cjwatson> pitti: yes, some of them but not all
[11:41] <pitti> seb128: arh, lp borkage in i386 retracer again
[11:41] <seb128> pitti, :-(
[11:41] <seb128> pitti, like the same issue than the other day?
[11:41] <pitti> yes
[11:41]  * pitti cleans cache and restarts
[11:41] <seb128> how did you solve it the other day? cleaned .launchpadlib?
[11:41] <pitti> right
[11:41] <seb128> why would the cache breaks it this way...?
[11:42] <pitti> ERROR: connecting to Launchpad failed: ValueError
[11:42] <pitti> awesome
[11:42] <pitti> that seems to be the new launchpadlib now
[11:45] <cjwatson> pitti: (d-i has been broken for other reasons for a bit, hence me only noticing this now)
[11:45] <cjwatson> gosh, over a week ...
[11:48] <pitti> seb128: ah, this gets a "504: Gateway Time-out" now with the new launchpadlib; I guess this is talking to a new server now and needs un-firewalling
[11:49] <pitti> seb128: this stuff all seems to have conspired against us.. :(
[11:50] <pitti> bah, works under strace, I guess it really was transient
[11:58] <pitti> seb128: above crash got retraced, see http://launchpadlibrarian.net/65063086/Stacktrace.txt
[12:01] <Riddell> janimo: hmm, some general qt issue there it looks like, I'll investigate
[12:05] <janimo> Riddell, it is strange as it seems to me those package versions are installable on natty/arm
[12:12] <elmo> what does stuff in brackets in a seed mean?
[12:12] <elmo> and if something is in brackets on http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.natty/desktop - can I assume it's on the natty (ubuntu) live CD?
[12:18] <cjwatson> elmo: germinate(1) should document all the syntax
[12:18] <cjwatson> elmo: if you mean (), that turns into Recommends in metapackages
[12:19] <seb128> pitti, quite better :-)
[12:19] <cjwatson> you can assume that it's intended to be on the live CD, but not that it actually is - you need to check the .manifest and .list files on cdimage for that
[12:19] <cjwatson> pitti: so remind me how I build a working udev source package out of bzr?  it's complaining about stuff under test/ - I've hit this in the past but forget how I handled it
[12:20] <elmo> cjwatson: ah, thanks I was reading SeedManagement on the wiki - didn't think to RTFM
[12:20] <pitti> cjwatson: dpkg-buildpackage -S works
[12:21] <pitti> cjwatson: it seems that debuild -S ignores the tar-ignore options in debian/source/options
[12:21] <pitti> cjwatson: (or diff-ignore)
[12:21] <elmo> what the heck is amd64+mac ?
[12:23] <cjwatson> pitti: ah, thanks
[12:23] <cjwatson> elmo: the amd64 CD built without UEFI support so that Macs can boot it
[12:23] <cjwatson> (and some other machines - it's a slight misnomer)
[12:24] <elmo> ah
[12:31] <Riddell> janimo: the qt install issue is just waiting for this to compile on arm https://launchpad.net/ubuntu/+source/libx11
[12:32] <ricotz> Riddell, hello :), could you accept the libbluray binaries?
[12:34] <Riddell> ricotz: is there a pressing need?
[12:36] <ricotz> Riddell, i was hoping siretart wants to update mplayer to use
[12:36] <janimo> Riddell, if so the buildd errors are surely misleading.
[12:37] <Riddell> janimo: soyuz being confused by build-depend issues isn't rare :)
[12:38] <janimo> Riddell, good to know. First time I see this though :)
[12:38] <ricotz> Riddell, and since you have the insights after reviewing it, might be useful you would also do this
[12:38] <zyga> hi, where can I find some documentation about the purpose of debian/package.doc-base?
[12:41] <cjwatson> zyga: man dh_installdocs
[12:41] <cjwatson> and man install-docs
[12:41] <zyga> cjwatson, I read the first one, I'm still not familiar with what doc-base is
[12:42] <zyga> cjwatson, is it some debian global documentation registry?
[12:42] <mdz> pitti, I committed a couple of tiny improvements to hookutils in apport trunk; should I be documenting things like that in NEWS?
[12:42] <cjwatson> zyga: yes, pretty much
[12:42] <pitti> mdz: I usually do that along with the actual patch, and then have a script "newscommit" which works like debcommit for NEWS
[12:42] <cjwatson> apt-cache show doc-base
[12:42] <zyga> cjwatson, how does one use it in practice?
[12:42] <mdz> pitti, oh, neat
[12:43] <pitti> mdz: http://people.canonical.com/~pitti/scripts/newscommit FYI
[12:43] <cjwatson> zyga: it doesn't sound like you've read the doc-base documentation - could you do that, and then come back if it's still unclear?
[12:43] <zyga> sure, let me find it
[12:43] <pitti> mdz: as long as you use standard (LP: #xxxx) syntax, it also tags the bugs appropriately
[12:44] <mdz> I see
[12:49] <rniamo> hi, under natty i have segfault with gnome : http://pastebin.com/3Nt2v0Ee
[12:50] <seb128> rniamo, try getting a stacktrace https://wiki.ubuntu.com/Backtrace
[12:52] <rniamo> seb128: how can i do to debug, it is gdm
[12:52] <seb128> rniamo, what is gdm? the log you copied is a gnome-panel crash
[12:53] <zyga> cjwatson, okay I think I got it now, thanks
[12:54] <rniamo> seb128: in fact when i start each time i open a gnome window it crash
[12:54] <zyga> cjwatson, how can I check that the documentation is properly registered with doc-base? yelp did not manage to find my package
[12:55] <rniamo> here is the stacktrace i can have: http://pastebin.com/uYMvgBRg
[12:57]  * ogra glares at a buildlog
[12:57] <ogra> geeez, world is broken !
[12:57] <cjwatson> zyga: you can use 'install-docs -s <document-id>'
[12:57] <rniamo> seb128: http://pastebin.com/uYMvgBRg i had this
[12:57] <ogra> is there something wrong on a very low level ? or am i insane ?
[12:58] <zyga> cjwatson, so it shows some output, should that convince me that everything is okay?
[12:58] <seb128> rniamo, seems similar to bug https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/710678
[13:00] <rniamo> seb128: yes i can't access this page even being loggued
[13:01] <seb128> rniamo, try again
[13:02] <cjwatson> zyga: probably.  you could try dwww or something
[13:03] <rniamo> seb128: it seems to work, thanks
[13:06] <mdeslaur> @pilot in
[13:12] <zyga> how can I test that my package will build on lucid + maverick + natty using pbuilder? do I need to sudo pbuilder --create --distribution=$foo and then sudo pbuilder --build *.dsc ?
[13:13] <raphink> zyga, you can use pbuilder-dist with multiple configurations
[13:13] <raphink> that will work as a wrapper so you can have several pbuilders on the same machine and run each of them on the source
[13:14] <raphink> see man pbuilder-dist
[13:14] <mterry> doko_, what's the story with twm then?  You don't like pulling in all of metacity's dependencies?
[13:15] <zyga> raphink, how can I purge existing pbuilder data safely?
[13:15] <zyga> pbuilder --clean?
[13:15] <raphink> zyga, pbuilder clean
[13:15] <zyga> thanks
[13:16] <doko_> mterry: it's sometimes broken, and pulls the whole world with libcanberra
[13:23] <mdz> pitti, I'm still surprised how many package hooks don't use the convenience functions in hookutils, and reimplement things like checking the versions of related packages, even attaching files and running commands
[13:24] <mdz> there is also some good stuff in package hooks which should be factored out into hookutils
[13:25] <ogra> someone should blog about it ;)
[13:25] <ogra> (no, i'm not volunteering :) )
[13:26] <mdz> I just noticed that the example in https://wiki.ubuntu.com/Apport/DeveloperHowTo didn't use hookutils, so I fixed that
[13:27] <cnd> cdbs, are you still around?
[13:27] <cnd> I'm wanting to tackle the trackpad bug
[13:28] <raphink> ogra, a blog entry on hooks would be great
[13:32] <mdz> raphink, I don't know what there is to blog about which isn't already in https://wiki.ubuntu.com/MeetingLogs/devweek0909/ApportPkgHooks and DeveloperHowTo
[13:32] <raphink> maybe just a blog post to let people know that this page exists :-)
[13:35] <mdz> JFo, is https://bugs.launchpad.net/ubuntu/+source/apport/+bug/614421 fixed/obsolete?
[13:36] <mdz> raphink, sounds more like a dent :-)
[13:38] <raphink> mdz dents are probably read by less people than planet
[13:38] <mdz> raphink, perhaps so
[13:40] <raphink> ;)
[13:55] <jamespage> mterry: any chance you could review bug 676904 for me? As FF is nearly here I'd like to get it sorted one way or the other.
[13:56] <mterry> jamespage, yeah, I'm in the middle of it
[13:56] <jamespage> mterry: just noticed - thanks!
[14:04] <zyga> how can I emulate a PPA environment with pbuilder, I want to build a package that depends on a more recent version of a package (than available in ubuntu) that I keep in my ppa. I'd like to test this setup before actually uploading to a ppa
[14:07] <cody-somerville> zyga, You can create a pbuilder chroot that has your PPA in the sources.list.
[14:10] <m4n1sh> zyga: login to your chroot image
[14:10] <zyga> cody-somerville, is there some --option for that or just do that manually?
[14:12] <m4n1sh> pbuilder --login --save-after-exec
[14:12] <m4n1sh> OR
[14:12] <m4n1sh> pbuilder --login --save-after-login
[14:12] <siretart> Riddell: do we have plans to remove qt3 from natty? I'm being bugged about a package that uses qt3, which is supposed to be removed from unstable 'in the next 3 months'
[14:12] <cdbs> cnd: back
[14:13] <Riddell> siretart: Qt 3 is part of LSB, so I think it depends if we care about LSB
[14:13] <cdbs> cnd: I did a half-revert upload to my PPA as a test, which used the new ABI for building, and except for that, it was the same as -0ubuntu3
[14:13] <cnd> cdbs, can you perform the steps I just posted to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/724051
[14:13] <siretart> Riddell: do you have a reference at hand?
[14:14] <Riddell> siretart: reference to what?
[14:15] <siretart> to 'Qt 3 is part of LSB'
[14:15] <Riddell> google for LSB?
[14:15] <cdbs> cnd: okay, doing
[14:15] <siretart> thanks
[14:15] <cnd> Riddell, hey, did you get my email?
[14:16] <Riddell> cnd: yep, qt didn't compile with the libxi from the PPA last night but it seems to be compiling fine with the libxi in the archive now so I'll upload that once it's done here
[14:16] <cnd> Riddell, great!
[14:16] <cnd> thanks!
[14:16] <cnd> thanks cdbs!
[14:26] <cdbs> cnd: followed, mailed to bug (will take some time for comment and attachments to come up in LP as I posted through email)
[14:27] <cnd> cdbs, thanks!
[14:31] <cnd> cdbs, I can reproduce the issue now, thanks!
[14:44] <vila> james_w`: thanks for the reviews ! The code is now running on jubany
[14:45] <vila> james_w`: there are a bunch of outstanding jobs due to a os.environ difference between my test env and jubany which led to massive failures on first restart. Fixed now.
[14:45] <james_w`> vila, great, thanks for the branches
[14:45] <james_w`> and the tests!
[14:46] <vila> james_w`: my pleasure, just mentioning the new deployment so if you see something unusual you had the right context
[14:46] <james_w`> thanks
[14:48] <vila> james_w`: hmm, I wonder if the bad restart caused all previous failures to be overridden...
[15:00] <hrw> morning
[15:06] <mdz> jhunt, any guesses what could cause bug 710983?
[15:07] <mdz> (upstart related)
[15:08] <kklimonda> pitti: did tor get an SRU exception?
[15:08] <pitti> kklimonda: oh, is that back in teh archive?
[15:09] <pitti> so it is
[15:09] <pitti> in dapper, hardy, and natty
[15:09] <pitti> seems we didn't remove it hard enough then
[15:09] <pitti> kklimonda: it did get an SRU exception back then, when someone said he'd take care of updates and testing
[15:10] <kklimonda> I think it was removed after hardy
[15:11] <jhunt> mdz: this is a duplicate of bug 707971 (I've just marked it as such).
[15:13] <kklimonda> pitti: ah, I guess I've asked the wrong question then, I do remember the original discussion about it but it was some time since then.
[15:14] <kklimonda> pitti: afair there were two issues - lack of manpower dedicated to tor, and the issue of how trusted our uploads are? my memory is getting fuzy here, but I remember talking about keys, and getting the debian maintainer on board.
[15:15] <mdz> jhunt, oh, thanks
[15:15] <pitti> kklimonda: mainly because tor releases constantly need to be kept up to date in stable releases, even across major versions
[15:16] <pitti> kklimonda: and as there is nobody who looks after that, we felt that it's better to not ship it at all
[15:16] <pitti> I'm not sure how it landed back in natty
[15:16] <cjwatson> somebody promised to do it
[15:16] <kklimonda> ah, I've found the bug: bug 689188
[15:17] <kklimonda> also bug 697407 - so something is happening. :)
[15:18] <cnd> hi all, we've broken some synaptics trackpads: https://bugs.launchpad.net/ubuntu/+source/utouch-frame/+bug/724051
[15:18] <cnd> we're looking for a sponsor to upload a fix
[15:18] <cnd> need a core-dev
[15:18] <kklimonda> Jacob is apparently a core developer of tor
[15:19] <kklimonda> but he doesn't have upload rights to tor in Ubuntu, so we still need either developer interested in tor, or someone who can help Jacob get PPU for tor.
[15:24] <apw> i assume we are aware that unity is in a heap _again_
[15:31] <didrocks> apw: downgrade gsettings-desktop-schemas, the new version add a Breaks:
[15:32] <rydberg> hi, a tiny tiny bugfix to a huge huge problem we managed to introduce yesterday: https://bugs.launchpad.net/ubuntu/+source/utouch-frame/+bug/724051
[15:33] <mdz> cjwatson, is bug 712677 by design? (apport dialog not being triggered during "install Ubuntu" session)
[15:34] <mdz> jhunt, is bug 723670 a dupe of that one as well?
[15:35] <apw> didrocks, i assume that'll stop anyone who is still ok from getting fooked ?
[15:36] <didrocks> apw: the breaks: will avoid apt-get upgrade yeah
[15:37] <apw> didrocks, will downgrade and see if that resolves me
[15:37] <apw> i hate unity
[15:37] <didrocks> apw: keep me updated
[15:37] <didrocks> that really help the conversation, but I have more than 15 packages still to upload, so I won't raise it…
[15:37] <cjwatson> mdz: ev would know for sure, but I don't believe it is.  that would be a ubiquity bug
[15:38] <ev> definitely not by design
[15:44] <jhunt> mdz: yes, I think it is (the description text is possibly misleading).
[15:45] <apw> didrocks, as you can probablaly tell from the delay its not much better after the downgrade
[15:45] <apw> didrocks, i had a blank screen on login with about a dozen crash things
[15:45] <apw> didrocks, i had unity and compiz still alive, but had to unity --reset on VT1 to get anythihng working
[15:46] <apw> didrocks, and i now have doubled indicators
[15:46]  * apw calls that fali
[15:46] <didrocks> apw: I'm not sure about the indicator, ask tedg
[15:47] <didrocks> apw: weird that you had to reset to get unity working though, as you just downgraded an unrelated package
[15:47] <apw> at least i have indicators now after the --reset
[15:47]  * apw will try a afull reboot ... like it was windows
[15:47] <cnd> cody-somerville, is the process for creating a new package set documented somewhere?
[15:48] <cnd> I'm interested in creating one for the utouch packages
[15:51] <apw> didrocks, seems like applyiing the 7Rs to it seemed to work, must be some other interaction with the glib downgrade which survived logout
[15:52] <didrocks> apw: maybe some gsettings, right
[15:53] <cody-somerville> cnd, I believe the lp API is used to manage them. However, I think you'll need a member of the TB to set it up.
[15:53] <cody-somerville> cnd, with approval from the DMB
[15:54] <apw> didrocks, unity seems to hate me
[15:55] <cnd> cody-somerville, that's the technical "how to create a package set", but I need to know what the process is for asking the DMB or TB :)
[15:55] <cnd> do I add it to the agenda myself?
[15:55] <cnd> make a wiki application page?
[15:55] <cody-somerville> cnd, Ah. Yes.
[15:55] <didrocks> apw: well, the changes will be way less draster after today's upload, so it should be better
[15:55] <cody-somerville> cnd, And yes (doesn't need to be anything too formal, just describing what you want).
[15:56] <cnd> cody-somerville, to be sure I understood you right, I should make a wiki page for the application, and I should add it to the agenda?
[15:56] <cody-somerville> cnd, Aye.
[15:56] <apw> didrocks, heh heres hoping
[15:56] <cnd> cody-somerville, ok, thanks!
[16:05] <mdz> mvo, around?
[16:06] <mvo> hey mdz
[16:06] <mvo> yes
[16:06] <mdz> mvo, I'm wondering whether it's more correct to fix bug 573594 (and others like it) in apt or in package_hook
[16:06] <mdz> currently we check for some cases in each place
[16:06] <mdz> it actually seems like what we want is a global bugpattern
[16:07] <mdz> which would be much easier to maintain than all of this code
[16:07] <mvo> mdz: indeed, the package_hook has various advantages, its more logical to put it there than in apt and its also python so the string parsing/maniplution is easier
[16:08] <rydberg> anyone wants to sponsor a one-liner with great bug heat? https://bugs.launchpad.net/ubuntu/+source/utouch-frame/+bug/724051
[16:08] <mdz> mvo, the advantage of doing it in apt is that it can look up the translated string
[16:08] <mdz> and it doesn't bother the user with a useless crash report
[16:08] <mvo> mdz: we should be able do that with dgettext("apt", msg)  too
[16:09] <mvo> mdz: but yeah, the bothering the user is a problem
[16:09] <mdz> mvo, ah yes, true
[16:09] <mdz> harder in a bugpattern :-)
[16:09] <mvo> mdz: this is the advantage of the bugpattern, right? that will filter it out before it reaches the user?
[16:09] <mvo> mdz: indeed :)
[16:09] <mdz> mvo, no, the bugpattern is actually the latest check
[16:10] <mdz> apt → package_hook → apport → bugpatterns
[16:10] <kklimonda> pitti: if tor already has an SRU exception, would it be possible to update hardy package to the current stable, as per upstream request? I'm pretty sure anyone interested in tor at this point is already using it from the upstream repository, this update would help us assess the amount of work future updates would take. I can work on that, as I use tor semi-regulary (whenever I put my tin-foil tat
[16:10] <kklimonda>  on).
[16:10] <mdz> the experience for the user should be pretty much the same for package_hook and a bugpattern
[16:11] <mdz> sorry, I actually meant general-hooks/ubuntu.py, not package_hook
[16:11] <pitti> kklimonda: not only possible, but desirable; actually doing that was part of the deal from the start :)
[16:11] <mvo> mdz: what about adding a apport_apt_filter? so that apt calls a external filter before passing it on to apport?
[16:12] <kklimonda> pitti: the only problem I see right now is that tor's developers advise users not to use packages that were not signed by people who are mentioned on https://www.torproject.org/docs/verifying-signatures.html.en - debian maintainer is on this list, but no one from Ubuntu is.. and this is one of the issues mentioned in the bug 413657
[16:12] <mdz> mvo, I'd probably suggest adding that functionality to apport instead, so that other packages can benefit
[16:13] <mdz> the "silently throw away this crash report" feature
[16:13] <mvo> mdz: sounds good, a generic pre-report filter
[16:13] <mdz> mvo, then we could add a bugpattern scan to general-hooks/ubuntu.py
[16:13] <mdz> if we wanted to
[16:14]  * mvo nods
[16:14] <mdz> pitti, what would you think of having a global bugpattern list in addition to the per-package ones?
[16:15] <pitti> mdz: sounds fine to me; shouldn't be too hard to implement
[16:15] <pitti> mdz: in fact, we could also only use a global list
[16:16] <pitti> when I started this, I wasn't sure how big our list would actually get, and wanted to minimize XML parsing
[16:16] <pitti> but it turns out that we don't actually have hundreds of entries, and a lot of them are necessary only temporarily
[16:16] <pitti> so the rules could additionally match on "Package" and all be in one file
[16:16] <pitti> (and we should remove the ones whose bugs were fixed long ago)
[16:17] <mdz> pitti, 273 by my count ;-)
[16:17] <pitti> mdz: right, bug I suppose 250 can be dropped now :)
[16:18] <mdz> if the package match is always listed first, it should be very inexpensive
[16:19] <pitti> we need to keep the per-package ones around (on people) for stables, but they aren't that relevant (mostly for packagage upgrade failures, not so much for crashes)
[16:19] <Chipzz> kklimonda: I fail to see your issue?
[16:19] <Chipzz> kklimonda: I quote from the page: "To verify the signature of the package you downloaded, you will need to download the ".asc" file as well."
[16:20] <Chipzz> but that assumes you *download* something from their site, which you don't since you're installing with apt?
[16:20] <kklimonda> Chipzz: what I mean is that neither source nor binary package in Ubuntu is going to be signed by one of the keys listed on this website.
[16:21] <Chipzz> kklimonda: and what I'm saying is that matters exactly zarroo
[16:21] <Chipzz> since the packages are signed by the ubuntu archive keyring
[16:21] <Chipzz> or rather
[16:22] <Chipzz> they have their checksum in a file which is signed
[16:22] <Chipzz> ...
[16:22] <ScottK> kklimonda: I think the final resolution on TOR was that ubuntu-archive signature was good enough.
[16:22] <ScottK> We'd need them to update their web site to say so though.
[16:23] <highvoltage> if there's an archive admin on duty today, it would be really nice if they could look at the 4 schooltool packages in NEW, they have FFe's filed already and are in good shape and shouldn't take too much time
[16:26] <kklimonda> Chipzz: what I'm saying is that it matters to people who use tor, that the signature on the package isn't listed on the page. At least that has been one of concerns that were raised during the discussion. I haven't seen the part of the discussion when it has been decided that the ubuntu-archive key is enough, if it is then it's great - we just have to make them update their website . )
[16:27] <Chipzz> kklimonda: for one, your comment seems to be misleading
[16:27] <Chipzz> https://bugs.launchpad.net/ubuntu/+source/tor/+bug/413657/comments/4
[16:28] <Chipzz> you talk about signed packages
[16:28] <Chipzz> which is incorrect
[16:28] <kklimonda> Chipzz: it's not mine :)
[16:28] <Chipzz> Oh I was assuming that comment was yours
[16:29] <Chipzz> but you make the same mistake
[16:29] <Chipzz> I can't see how the signature on the *package* matters
[16:29] <Chipzz> the package would be the .deb you download and extract, and which is signed by the ubuntu archive. But this .deb is cleaned out when you do apt-get clean, so it matters not
[16:30] <ScottK> highvoltage: As long as they are uploaded before FF, they don't have to be accepted by FF to get in.
[16:30] <Chipzz> what I *can* see mattering is the signature of the *executable*
[16:30] <Chipzz> which is a different thing altogether
[16:31] <kklimonda> Chipzz: by signature on package, I mean signature confirming that the downloaded package has been uploaded by someone trusted.
[16:31] <kklimonda> Chipzz: it obviously doesn't mean the executable hasn't been tampered with.
[16:31] <cjwatson> Chipzz: .debs are not signed directly by the Ubuntu archive
[16:32] <cjwatson> the signature on .debs is via the Packages and Release files
[16:32] <Chipzz> cjwatson: that's what I said above:
[16:32] <kklimonda> (but the source packages are signed, and they can be downloaded, and verified)
[16:32] <Chipzz> 17:21 < Chipzz> or rather
[16:32] <Chipzz> 17:22 < Chipzz> they have their checksum in a file which is signed
[16:32] <GunnarHj> doko_: Hi Matthias, any chance that you can help fixing bug 710151?
[16:32] <cjwatson> fair enough.  you didn't say it very clearly just now. :)
[16:33] <Chipzz> cjwatson: I was "shortening" it for the sake of the discussion
[16:33] <Chipzz> cjwatson: I could have repeated that, but than I might just as well have used the complete terminology in the first place ;)
[16:34] <cjwatson> I think just saying "indirectly signed" would be good in future to avoid confusion
[16:34] <cjwatson> since there *is* a technology for signing .debs directly, it's just not generally used by distributions because signing the archive is more convenient
[16:34] <highvoltage> cjwatson: who should I give a poke to let them know that live USB disks doesn't add the repositories on the disks when booting? (LP: #723357)
[16:34] <Chipzz> kklimonda: and what I mean is that "it matters to people who use tor, that the signature on the package isn't listed on the page" is completely irrelevant
[16:35] <cjwatson> highvoltage: I don't know
[16:35] <Chipzz> kklimonda: since apt-get does the downloading and verifying FOR you
[16:35] <cjwatson> highvoltage: I mean I suppose me, but you've already poked me
[16:35] <kklimonda> Chipzz: but there is nothing preventing someone from tampering with tor before uploading it to archive.
[16:35] <Chipzz> kklimonda: ideally, users do not even look at the .deb
[16:35] <cjwatson> and I'm not sure I'm going to have time to investigate it
[16:36] <Chipzz> kklimonda: yes there is.
[16:36] <highvoltage> cjwatson: yeah stgraber said I should poke you, but I think you already have too much stuff to do
[16:36] <Chipzz> kklimonda: ppl are supposed to be trustworthy before they can upload
[16:37] <Chipzz> kklimonda: in debian you have a keyring, the NM process, and lots of other measures to assure that
[16:37] <kklimonda> Chipzz: "are supposed to be" being a key - but we don't check if people are who they say they are before giving them upload rights. I know the argument is academic one, but people who use tor are not exactly people who thrust others easily.
[16:38] <Chipzz> kklimonda: in ubuntu you have similar infrastructure/rules to achieve sth similar
[16:38] <Chipzz> kklimonda: well when you start using that argument, I stop this discussion
[16:38] <Chipzz> because by that reasoning every package in ubuntu is untrustable
[16:38] <kklimonda> Chipzz: I don't even think it is the issue, but I don't know if it has been addressed.
[16:38] <ScottK> Chipzz: One major difference is that in Ubuntu there's no process tie the uploader to a real identity.
[16:38] <cjwatson> the entire purpose of tor is to be ultra-paranoid and to trust virtually nobody
[16:39] <cjwatson> it's hardly surprising that many of its users might have stronger trust requirements than we provide
[16:39] <Chipzz> and if you assume that every package is untrustable, you might as well format your harddisk
[16:40] <cjwatson> but indeed, Ubuntu doesn't require web-of-trust before upload rights
[16:40] <Chipzz> isn't that an inherent problem with ubuntu then?
[16:40] <cjwatson> so "in ubuntu you have similar infrastructure/rules" does gloss over quite a bit
[16:40] <cjwatson> arguably; of course there are reasons for it
[16:41] <maco> i know one person who wouldnt be a motu if keysigning was required. she lives on the opposite side of russia from the DDs
[16:43] <Chipzz> one solution would be to upload tor to main/restricted then, since the number of ppl who can upload to main is much smaller, and the ppl who can upload can be trusted
[16:43] <Chipzz> but, that of course creates another set of problems
[16:43] <Chipzz> like someone with main upload rights having to maintain (or at least upload) the package
[16:43] <ScottK> It could also be in an exclusive packageset that only select people could upload.
[16:44] <kklimonda> the best solution would be to work with Jacob, who has said that he's interested in maintaining tor for Ubuntu, to get PPU rights.
[16:44] <mdz> pitti, the apport unit tests are blowing up on me because there's a /bin/cat process running (child of zeitgeist-daemon)
[16:44] <cjwatson> I don't think we'd be willing to support it in main
[16:44] <Chipzz> ScottK: that's possible?
[16:44] <ScottK> Sure.
[16:44] <kklimonda> or even what ScottK has said
[16:44] <cjwatson> it's theoretically possible
[16:44] <ScottK> I think so.
[16:44] <cjwatson> it's never been ussed
[16:44] <Chipzz> I guess I'm not up-to-speed with launchpad features
[16:44] <cjwatson> *used
[16:44] <cjwatson> and it does present its own problems
[16:44] <ScottK> cjwatson's the expert though.
[16:44] <pitti> mdz: yeah, I sometimes have that as well, and just killall cat
[16:45] <maco> pitti: how cruel! :P
[16:45] <pitti> I know, it's an useless use of cat!
[16:45] <mdz> pitti, I wonder if it does anything important
[16:45] <mdz> I don't see an invocation of cat in the zeitgeist source
[16:45] <pitti> mdz: it doesn't always exist, I wonder if it's a leaked process somehow
[16:46] <Chipzz> pitti: no, it's a usefull use of cat, since now you can kill (the) cat to fix it ;)
[16:46] <pitti> heh
[16:46] <mdz> this is one of those days where you need to enforce a stack size limit
[16:46] <mdz> if you keep looking for the next bug, you never get to the bottom
[16:46] <mdz> s/you/I/g
[16:48] <cjwatson> a system I use once developed a one-bit error in /bin/cat
[16:48] <cjwatson> it's amazing how much stuff kept on working anyway
[16:48] <SpamapS> anybody having iphone tethering working in natty? I'm told it works fine in maverick but my natty box just refuses to work. :-/
[16:48] <cjwatson> e.g. the entire news server and clients continued to work fine
[16:49] <ion> cjwatson: We really need a checksumming filesystem à la btrfs, zfs.
[16:49] <mdz> cjwatson, I bet an awful lot of stuff goes wrong if you try to boot :-)
[16:49] <cjwatson> probably ...
[16:49] <cjwatson> that box isn't rebooted often :)
[16:50] <ion> I wonder if one can already trust btrfs with her data?
[16:50] <mdz> pitti, I killed it, and now it's a zombie and the test suite still fails :-)
[16:50] <mdz> have to kill the whole of zeitgeist
[16:50] <pitti> mdz: it's a cat, you need to kill it 9 times :)
[16:50] <ion> haha
[16:50] <mdz> pitti, I did!
[16:50] <cjwatson> of course checksumming filesystems have their own problems; they mean that we need to use a different approach instead of /boot/grub/grubenv
[16:51] <mdz> isn't that what kill -9 does?
[16:51] <ion> cat should be patched to count the number of SIGTERMs and die on the ninth one.
[16:51] <ion> mdz: :-D
[16:51] <cjwatson> (we don't really want to implement writing to the checksum tree in the boot loader)
[16:51] <pitti> mdz: good point! but you also need --disable-schroedinger, otherwise it's still alive if you don't run ps aux and look at it
[16:51] <ari-tczew> @pilot in
[16:52]  * ari-tczew gets syncs for universe.
[16:52] <Chipzz> pitti: you'ld say killing it with kill -9 would be equivalent to killing it 9 times :)
[16:53] <ion> cjwatson: Perhaps a filesystem could support an ioctl (or something) to create files saying “no checksum for the data, please – i don’t care about potential corruption here”.
[16:54] <cjwatson> we're going to use the reserved boot loader area in btrfs instead
[16:54] <mdz> pitti, I used ps to look, and the result was indeterminate (the zombie is neither alive nor dead)
[16:54] <cjwatson> it leaves 64KB at the start
[16:54] <ion> cjwatson: Ah
[16:55] <kklimonda> at what hour does freeze start?
[16:55] <cjwatson> 1800 UTC
[16:55] <ari-tczew> so about hours left
[16:55] <ari-tczew> hour*
[16:57] <cjwatson> 19:12 <skaet_> all, just to be clear feature freeze will be at 1800 UTC Feb 24th for Natty,  after that please follow the https://wiki.ubuntu.com/FreezeExceptionProcess if something needs to get uploaded.
[16:58] <pitti> mdz: FYI, you can catch multiple exceptions with "except (IOError, ValueError):
[16:58] <mdz> pitti, ah, thanks. shall I fix that or have you done it already?
[16:58] <cjwatson> pitti: could you please review bug 721622?  you removed the package
[16:59] <pitti> mdz: haven't touched any code, just noticed your question fly by in the MP
[16:59] <pitti> cjwatson: looking
[16:59] <mdz> pitti, I thought specifying a tuple to except would invoke the old "<type>, <variable>" style
[17:00] <pitti> mdz: no, "excecpt (E1, E2, E3) as e:" works fine even in Python 3
[17:00] <pitti> mdz: comma doesn't work any more, right (it's "as" now)
[17:02] <pitti> cjwatson: can I close it as wontfix?
[17:03] <cjwatson> pitti: up to you
[17:03] <mdz> pitti, fixed and pushed
[17:03] <pitti> will do that then with a coment
[17:04] <cjwatson> I'm just working through the sync queue and noticed that that one seemed off
[17:04] <cjwatson> odd
[17:04] <mdeslaur> @pilot out
[17:06] <bdrung> cjwatson: all xul extension were removed (too high maintaince cost)
[17:08] <cjwatson> bdrung: I know
[17:08] <cjwatson> that's why it struck me as odd, so I asked pitti because he did the removal
[17:08] <cjwatson> in this case
[17:09] <micahg> cjwatson: we didn't publicize it, so people might still think they can request them :)
[17:09] <pitti> cjwatson: just to ensure that I'm not missing anything -- in https://merges.ubuntu.com/a/avahi/avahi_0.6.28-2ubuntu2.patch we can really drop our delta in the init.d scripts, as we use upstart anyway, right?
[17:09] <pitti> cjwatson: (asking you because you did the last merge)
[17:10] <cjwatson> pitti: I guess so, though those diffs ought to go to Debian
[17:12] <vila> james_w`: weird, it seems that too many packages were requeued, but on the other hand I see a fair number of successful imports...
[17:12] <vila> james_w`: are they false positives ?
[17:13] <tseliot> cjwatson: if I wanted to blacklist all ati cards (so as to unset gfxpayload=keep) I should use this expression, right? v00001002d*sv*sd*bc03sc*i*
[17:14] <cjwatson> that looks plausible though I haven't checked the details
[17:14] <cjwatson> that's only in the fglrx packaging, right?
[17:14] <tseliot> cjwatson: yep
[17:14] <james_w`> vila, hmm, yeah, looks like everything got requeued?
[17:15] <vila> james_w`: not everything, but ~5000
[17:15] <james_w`> vila, well, everything that had failed
[17:15] <vila> ha, depends on what failure wre' re talking about :-/ There was ~500 packages with known failures
[17:17] <james_w`> right, but there are only a few with known failures now, which is why I think that
[17:18] <vila> james_w`: AIUI, running import_package.py for a successfully imported package is harmless right ?
[17:18] <james_w`> vila, yeah
[17:18] <vila> james_w`: so I'm only concerned about the newly created branches here
[17:18] <vila> james_w`: either we failed to trigger an import earlier or we are creating bogus branches
[17:19] <pitti> ev: saw your ubiquity upload, did the jockey --no-dbus thing work for you then?
[17:19] <vila> james_w`: I suspect the former but why would that be the case ?
[17:19] <james_w`> vila, do you have an example?
[17:19] <james_w`> I'm not sure what you are referring to with "newly created branches"
[17:20] <vila> james_w`: the ones mentioned in the log with a leading:  INFO - Success
[17:20] <vila> james_w`: avscan a couple of minutes ago
[17:22] <vila> james_w`: or https://code.launchpad.net/+recently-registered-branches for a more accurate source
[17:23] <pitti> mdz: I guess the displayed fiff at https://code.launchpad.net/~mdz/apport/504340-kernel-threads/+merge/51149 is outdated now? (werid, usually LP shows a "updating diff.." yellow box)
[17:23] <james_w`> vila, yeah, looks to me like all failures were requeued, and we are just seeing some failures that were fixed
[17:24] <james_w`> vila, so they are now importing ok
[17:24] <mdz> pitti, latest revno is 1858
[17:24] <james_w`> vila, it's a shame we don't have historical information on failures though
[17:24] <vila> james_w`: cool, thanks for confirming :)
[17:24] <james_w`> well, we do to some extent, one second
[17:24] <pitti> mdz: right, it got that, but it still shows the open() outside of the try:
[17:24] <vila> james_w`: a bit can be extracted from the logs, but may be the db has more ?
[17:25] <mdz> pitti, it also doesn't show the test
[17:25] <james_w`> the db doesn't
[17:25] <james_w`> AssertionError: Can't find the needed upstream part for version 3.2.2-openssl-1build1~feisty1
[17:25] <james_w`> that was avscan
[17:25] <james_w`> so we fixed that error at some point
[17:25] <mdz> pitti, it's missing all 3 subsequent revs
[17:25] <mdz> pitti, do I need to tell LP to update the merge proposal manually somehow?
[17:25] <vila> james_w`: from the explanations file ?
[17:26] <bdrung> cjwatson: ~7 new sync requests were acked
[17:26] <vila> no
[17:26] <pitti> mdz: no, it should notice by itself
[17:26] <james_w`> vila, from logs/avscan
[17:26] <pitti> mdz: *shrug*, I'll just merge locally and check the diff
[17:26] <vila> james_w`: !
[17:27] <mdz> I can't believe that https://code.launchpad.net/~mdz/apport/504340-kernel-threads doesn't offer a link to show (and download) a diff...
[17:28] <cjwatson> bdrung: cutting it fine? :)
[17:28] <pitti> mdz: it does, at the top of the displayed diff
[17:28] <pitti> -> Download diff  [x] Show line numbers
[17:28] <pitti> mdz: ^
[17:28] <james_w`> vila, do you know what causes: AssertionError: repository.user_url 'bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gtk-vnc/natty-201102220618/' does not match URL from server response ('bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gtk-vnc/natty/' + '') ?
[17:29] <cjwatson> mdz: it's in the merge proposal, link text "Ready for review"
[17:29] <pitti> mdz: anyway, looks fine now, thanks! Please go ahead and merge into trunk
[17:29] <pitti> mdz: (updated MP)
[17:29] <bdrung> cjwatson: yes. :)
[17:30] <pitti> Keybuk: hello, how are you?
[17:30] <mdz> pitti, cjwatson, I was pointing to the page for the branch itself
[17:30] <cjwatson> bdrung: amazingly quick turnaround on bug 721995 ...
[17:30] <pitti> Keybuk: what was the reason again why we moved dbus-daemon from /usr into / ?
[17:30] <pitti> mdz: ah
[17:30] <mdz> LP knows it has a parent branch elsewhere in LP, so a diff seems like a natural thing to want, e.g. if someone from upstream comes by looking for it
[17:30] <bdrung> cjwatson: i checked https://bugs.launchpad.net/~ubuntu-sponsors for remaining syncs ;)
[17:31] <pitti> Keybuk: it's quite a large delta to Debian, keeps breaking stuff at every merge, and as it needs /usr/share/dbus-1/ anyway
[17:31] <pitti> ... it won't work without /usr
[17:32] <mdz> pitti, done
[17:32] <Keybuk> pitti: hey, not too bad thanks, you?
[17:32] <Keybuk> pitti: because Upstart depends on dbus?
[17:32] <pitti> Keybuk: pretty good, thanks!
[17:32] <Keybuk> I mean, you can make /sbin/init a symlink to /usr/sbin/init if you like ;-)
[17:32] <Keybuk> but GOOD LUCK WITH THAT :p
[17:32] <Keybuk> plus mountall depends on dbus, and mountall mounts /usr
[17:33] <Keybuk> a better question is why Debian hasn't moved D-Bus to /
[17:33] <Keybuk> since that's the recommended practice upstream
[17:33] <pitti> Keybuk: mbiebl says that it won't work without /usr/share/dbus-1/interfaces/ anyway, so he kept it in /usr
[17:33] <Keybuk> and would then match Ubuntu, Fedora, SuSE, etc.
[17:33] <Keybuk> it works just fine
[17:33] <Keybuk> D-Bus reparses that directory when it's available
[17:33] <Keybuk> you just can't do activation until /usr is mounted
[17:33] <ari-tczew> cjwatson: do you will do all syncs until 30 minutes?
[17:34] <Keybuk> but then you likely don't need to for the things outside /usr
[17:34] <vila> james_w`: sorry, got interrupted, no, never saw that one
[17:34] <Keybuk> I've actually *shock* tested the NFS /usr case ;-)
[17:34] <vila> james_w`: but user_url is supposed to gives user-readble URLs :-.
[17:34] <james_w`> vila, it's cropped up a few times, seemingly after 2.3 on the client, or maybe after a change on LP
[17:35] <pitti> Keybuk: ok, good to know; thanks for the heads-up!
[17:36] <mbiebl> Keybuk: hi, what about /var/lib/dbus/machine-id?
[17:36] <pitti> Keybuk: another question, would it be possible to commit the 5 upstart patches upstream? took some effort to port them even to a new microrelease
[17:36] <Keybuk> pitti: which 5 upstart patches?
[17:36] <Keybuk> have they been sent to upstart-devel ?
[17:36] <Keybuk> mbiebl: we don't suppose NFS /var - I don't think anyone does
[17:36] <pitti> Keybuk: in dbus, for upstart service activation
[17:36] <Keybuk> suppose? support!
[17:36] <mbiebl> but a separate /var you support?
[17:36] <Keybuk> pitti: oh, there is a bug open and discussion happening on the dbus mailing list
[17:37] <Keybuk> I've sent a few variants of those packages
[17:37] <pitti> ah, cool
[17:37] <Keybuk> mbiebl: yes, dbus is started on local-filesytems in ubuntu
[17:37] <Keybuk> it's in / to support a networked /usr, networking in ubuntu needs NFS
[17:38] <mbiebl> Keybuk: but upstart works just fine without a running dbus
[17:38] <Keybuk> argh, patches not packages
[17:38] <Keybuk> mbiebl: no, it works "mostly fine"
[17:38] <mbiebl> what's broken besides unprivileged user access?
[17:39] <bdrung> jamespage: you are working on the groovy sync? the clock ticks. ~ 20 mins till FF
[17:39] <Keybuk> mbiebl: that is what's broken
[17:39] <Keybuk> plus obviously receiving signals (plymouth uses them)
[17:39] <Keybuk> etc.
[17:39] <Keybuk> though I'm not sure whether colin did that via a direct connection or not, you'd have to ask him
[17:40] <Keybuk> *shrug*
[17:40] <Keybuk> sorry, I don't get the "this all works, can I change it and break it?" attitude
[17:40] <mbiebl> hm, what?
[17:40] <Keybuk> well, boot works in Ubuntu right now
[17:41] <Keybuk> with dbus-daemon in /
[17:41] <Keybuk> moving it to /usr seems to be "let's break things for the hell of it" :-)
[17:41] <Keybuk> especially since Debian is afaik the only distro with dbus-daemon in /usr
[17:41] <jamespage> bdrung: yep  -  sync needed a patch for ubuntu as well - zul reviewing now
[17:41] <cjwatson> plymouth uses an ordinary connection to the system bu
[17:41] <cjwatson> *bus
[17:41] <Keybuk> cjwatson: that's what I thought
[17:41] <pitti> Keybuk: I think Fedora also has NM in /, to support networked /usr better
[17:42] <cjwatson> it might be worth changing that
[17:42] <Keybuk> pitti: we did for a while
[17:42] <cjwatson> but the direct-connection stuff looked kind of private to upstart IIRC
[17:42] <Keybuk> but I put it back in /usr since networked /usr was mostly covered by /e/n/i
[17:42] <Keybuk> the way our configuration stuff worked
[17:42] <Keybuk> cjwatson: no, you did it right - direct-connection is supposed to be for things in upstart's tarball only
[17:42] <mdz> pitti, my branch was --fixes lp:blah, will that propagate into trunk or do I need to do something to make sure the bug gets closed?
[17:42] <cjwatson> oh good
[17:43] <cjwatson> (I suppose I could have made it upstart-plymouth-bridge instead, but ...)
[17:43] <pitti> mdz: it won't be propagated through merges unfortunately
[17:43] <pitti> mdz: but the ubuntu task will get closed via debian/changelog once that hits the ubuntu branch and get uploaded
[17:43] <Keybuk> pitti: the only reason for having NM in / was if you wanted to do an NFS /usr on WiFi
[17:44] <Keybuk> oh, on WPA WiFi
[17:44] <pitti> Keybuk: that sounds a little on the crazy side to me..
[17:44] <cjwatson> ah, that's right, I made plymouth-upstart-bridge be 'start on started dbus'
[17:44] <Keybuk> pitti: crazy wasn't the problem, it was the "so where do the keys come from, then?" that was the problem :)
[17:44]  * cjwatson had a brief moment of self-doubt there :)
[17:44] <Keybuk> cjwatson: rofl
[17:44] <Keybuk> cjwatson: I never doubted you for a moment
[17:45] <mbiebl> pitti: NM is still in /usr on F14
[17:45] <mbiebl> unless they changed it in rawhid
[17:46] <cjwatson> obviously my code is at all times perfect.  er, or something.
[17:46] <ogra> oh, das Keybuk !
[17:47] <ogra> good to see you around :)
[17:47] <mbiebl> Keybuk: fwiw, I wasn't telling pitti to move dbus-daemon back to /usr in Ubuntu, I was just telling him why it was still on /usr in Debian
[17:47] <mbiebl> Keybuk: so, if dbus-daemon is started after local-filesystems
[17:48] <mbiebl> how do you communicate with plymouth before?
[17:48] <mbiebl> e.g. fsck progress bar etc
[17:48] <Keybuk> fsck progress bar is done by plymouth's own native communication
[17:48] <Keybuk> the upstart->plymouth is done via dbus
[17:48] <mbiebl> cjwatson: what does plymouth communicate with upstart then?
[17:49] <cjwatson> job changes
[17:49] <Keybuk> mbiebl: "apache started"
[17:49] <mbiebl> why does plymouth need to know that?
[17:49] <cjwatson> mbiebl: http://lists.freedesktop.org/archives/plymouth/2010-November/000464.html
[17:49] <cjwatson> (and thread, spread over a few months of the archives)
[17:49] <cjwatson> because otherwise even a non-"quiet" boot doesn't tell you anything about services starting
[17:50] <cjwatson> upstart doesn't print anything on the console when a job starts
[17:50] <cjwatson> this lets us show useful progress again
[17:50] <mbiebl> ok, but all those services will start after remote_fs anyway in Debian
[17:50] <cjwatson> it's not exactly identical to the output from init scripts, but it should make server people feel a bit more at home
[17:51] <mbiebl> so it doesn't really make a gread difference if dbus-daemon is started after local_fs or remote_fs
[17:51] <mbiebl> imho
[17:51] <cjwatson> depends what you're trying to debug
[17:52] <cjwatson> it might well be very useful to you to see that your server is hanging at boot in "Mounting remote filesystems"
[17:54] <mbiebl> Keybuk: when did you last try starting dbus without /usr being available?
[17:54] <mbiebl> does it install an inotify watch in / or how does it work?
[17:55] <Keybuk> mbiebl: each time you attempt to activate an interface, if it hasn't got an interfaces list, it goes to walk that directory
[17:55] <Keybuk> if the directory doesn't exist yet, the activation fails, but it'll try again next time
[17:55] <Keybuk> if the directory exists, then I believe it does use an inotify watch rather than reload each time
[17:56] <Keybuk> as to when
[17:56] <Keybuk> probably 2 years ago
[17:56] <Keybuk> when we made the change
[17:58] <mdz> pitti, I'm seeing an intermittent test failure in report.py (readelf: Error: core: Failed to read file's magic number), ever seen that before?
[17:59] <ari-tczew> 10 minutes requires, don't close :D
[17:59] <pitti> mdz: I think I did, once in about 10 times; but I never took the time to track it down
[17:59] <Daviey> doko_, around?  Could really do with some ld help
[18:00] <Keybuk> mbiebl: doesn't systemd also use dbus? :)
[18:00] <doko_> Daviey: what about?
[18:01] <mdz> pitti, ok, I didn't think I broke that but just checking :-)
[18:02] <mdz> pitti, what do you think is a good name for the package-independent bug pattern file? ANY.xml?
[18:02] <jamespage> any chance somone can sponsor bug 661230 for FF (yeah I know) - zul was sponsoring but has gone offline with connection issues.
[18:02] <pitti> mdz: I think I'd just use patterns.xml and obsolete the per-package ones
[18:03] <mbiebl> Keybuk: sure it does :-)
[18:03] <mdz> pitti, if we eliminate the per-package ones, we can just use the URL from crashdb.conf verbatim
[18:03] <mdz> instead of as a base
[18:04] <pitti> *nod*
[18:04] <mdz> pitti, is anyone other than Ubuntu using bugpatterns?
[18:05] <pitti> mdz: I don't think so; we are pretty much the only disto using apport at all
[18:06] <mvo> CA?
[18:10] <kees> cjwatson: say... isc-dhcp doesn't mention apparmor in the merge changelog and half of the apparmor logic got dropped.
[18:12] <cjwatson> :set ignorecase
[18:12] <cjwatson>     - Add enforcing AppArmor profile for DHCP client and server.
[18:12] <cjwatson>   * Drop preinst code to set AppArmor to complain mode on upgrades from very
[18:12] <cjwatson>     old Ubuntu releases, predating the last LTS.
[18:12] <kees> weird, I wonder how the symlink got lost
[18:12] <mbiebl> Keybuk: fwiw, I didn't know about the plymouth<->upstart interaction via dbus
[18:12] <cjwatson> if I missed something, sorry, and feel free to put it back :)
[18:13] <kees> cjwatson: yup, I will. thanks!
[18:13] <mbiebl> and before shuffling stuff around from /usr to / I need a good reason why it's necessary
[18:13] <Keybuk> mbiebl: of course, we can hope that dbus-daemon goes away soon enough
[18:14] <mbiebl> AF_DBUS ftw
[18:14] <Keybuk> no, multicast AF_UNIX1
[18:14] <Keybuk> s/1/!/
[18:15] <Keybuk> http://alban.apinc.org/blog/2011/02/16/introducing-multicast-unix-sockets/
[18:16] <mbiebl> yeah, I know about that : http://lists.freedesktop.org/archives/dbus/2010-September/013531.html
[18:16] <vila> james_w`: sorry, got *massively* interrupted
[18:16] <kees> cjwatson: actually, sorry, it's there (isc-dhcp-client.links), but dpkg seems to have ignored it. anyway, I'll track it down and fix it.
[18:17] <Keybuk> *nods*
[18:17] <vila> james_w`: so, regarding the wierd URLs, that only bell it ringing is 'fallouts from +branch handling', but that's rather ancient now so...
[18:17] <pitti> good night everyone!
[18:17] <vila> james_w`: .. pretty unlikely
[18:18] <kees> cjwatson: ah! dh_link is missing from rules. easy fix
[18:18] <vila> g'night pitti !
[18:18] <cjwatson> kees: ah, righto, that would have been easy to miss
[18:18] <cjwatson> silly non-dh(1) packages
[18:18] <kees> hehe :)
[18:19] <james_w`> vila, ok, we'll see if any appear again, and we can debug
[18:19] <vila> james_w`: in other news: more packages flirting with > 400M and up to 700M, that's also something we want to monitor for robustness and also to drive memory optimizations on the bzr side
[18:20] <vila> james_w`: yup
[18:20] <james_w`> vila, ok, thanks for keeping an eye on that
[18:20] <cdbs> skaet_: heh, your announcement refers to natty as lucid
[18:21] <cdbs> skaet_: the announcement about the feature freeze
[18:21] <cjwatson> heh, I didn't notice when moderating that ...
[18:21] <vila> james_w`: thank to you, I appreciate your support
[18:22] <Daviey> doko_, bug 724470
[18:23] <cdbs> cjwatson: :o You moderate -announce?
[18:23] <doko_> Daviey: did you apply the existing patch?
[18:23] <Daviey> doko_, to axis2c?
[18:23] <cjwatson> cdbs: -devel-announce, yes
[18:23] <cdbs> hmm
[18:24] <doko_> Daviey: which package does /usr/lib/axis2/services/EucalyptusNC/libEucalyptusNC.so belong to?
[18:24] <Daviey> doko_, binary package eucalyptus-nc, source package eucalyptus
[18:25] <doko_> Daviey: then fix eucalyptus ;-P
[18:25] <Daviey> doko_, Easy to say :)
[18:25] <doko_> it's not about ld, it's about searching the patch in the launchpad ...
[18:25] <Daviey> doko_, I'm not quite sure why it's compiling seemingly ok, but not ld correctly
[18:25] <proti> cjwatson: bug 723482, we answered your questions.
[18:26] <Daviey> doko_, searching the patch?
[18:26] <cjwatson> proti: yep, thanks, I'm going to have to set up a test environment, which is blocked on getting the server CDs working again, ...
[18:26] <proti> Good luck with this one.
[18:26] <cjwatson> (in progress)
[18:27] <doko_> Daviey: ahh, there was a new upload ... well, it looks like object files are placed before libraries when linking a library. dpkg-shlibdeps should have given warnings about unresolved symbols
[18:28] <proti> cjwatson: ok thanks. I you need testers, My machine is dead and 2 others at works.
[18:28] <proti> If you need*
[18:29] <cjwatson> thanks
[18:30] <doko_> Daviey: gcc -shared generated/*.o server-marshal.o handlers.o  -L/usr/lib/axis2/lib -lcap -lz -lrt -lpthread -lneethi -lmod_rampart -lm -laxutil -laxis2_parser -lguththila -laxis2_http_sender -laxis2_http_receiver -laxis2_http_common -laxis2_engine -laxis2_axiom -L/usr/lib/axis2/modules/rampart -L/usr/lib/axis2/lib   ../util/misc.o ../util/euca_auth.o ./gl-client-marshal-adb.o -o libEucalyptusGL.so -lssl -lcrypto
[18:31] <doko_> Daviey: that's not the only one
[18:32] <Daviey> doko_, i tried http://pb.daviey.com/U2O6/raw/
[18:33] <Daviey> ( see i have dupes)
[18:33] <doko_> dupes don't matter
[18:34] <doko_> in this order
[18:34] <Daviey> yeah, but that didn't work
[18:35] <doko_> Daviey: of course it doesn't work
[18:36] <Daviey> doko_, ok, let me try your entry
[18:36] <doko_> there's no lib after the .c file which can used to resolve *any* symbol
[18:37] <Daviey> ahhhh!
[18:37] <Daviey> doko_, that makes sense!
[18:38] <doko_> Daviey: http://wiki.debian.org/ToolChain/DSOLinking
[18:40] <Daviey> doko_, perfect!  thanks
[18:40] <doko_> Daviey: again, this is not the only lib ...
[18:40] <skaet_> cbs, drat - missed one.
[18:42] <skaet_> cdbs,  thanks for flagging.  yup s/lucid/natty/.  (sigh,  thought I caught them all :P )
[18:43] <cdbs> skaet_: well, you missed more than one
[18:43] <Daviey> doko_, yeah, i assume you mean the other libs with a build.sh file?
[18:43] <cdbs> skaet_: looks like you ran s/lucid/natty but not s/Lucid/natty
[18:43] <cdbs> ubuntu-bug announcement :D
[18:44] <cdbs> ahh, nautilus needs a rebuild
[18:44] <doko_> Daviey: I just pasted one line from the build logs, search for '-shared'
[18:44]  * cdbs confirms nautilus' fate
[18:45] <skaet_> cdbs,  yup and did a manual scan too...   /me shakes head and figures its time for lunch.
[18:45] <Daviey> doko_, Okay, great - how did you identify the other libs that need -l'ing?  I got my list from running ldd on the lucid binary, is that the best way?
 Daviey: I just pasted one line from the build logs, search for '-shared'
[18:46] <Daviey> doko_, ok, thanks
[18:49] <kklimonda> kirkland: hmm.. I have a really interesting problem, I've used ecryptfs-migrate-home to encrypt my home directory, but I don't have the $HOME/.ecryptfs/wrapped-passphrase which I should probably backup. I can still login, and all my data is fine.
[18:53] <mdeslaur> barry: does this make sense: bug #724494
[18:53] <mdeslaur> barry: can I just add the depends an upload it?
[19:00] <barry> mdeslaur: yep.  i was actually trying to test that fix in my ppa, but i'm certain it will fix the problem
[19:00] <barry> mdeslaur: thanks!
[19:00] <mdeslaur> barry: np!
[19:01] <barry> mdeslaur: i'm actually having more problems getting python-keyring built for maverick so leonardr can test it ;)  not your problem tho!
[19:01] <mdeslaur> barry: what's "maverick"? :)
[19:01] <barry> mdeslaur: exactly :)
[19:15] <mdeslaur> barry: why isn't it building for maverick?
[19:15] <mdeslaur> barry: (now you've got me curious :) )
[19:17] <ari-tczew> @pilot out
[19:19] <barry> mdeslaur: when i build it in my mav schroot it keeps wanting to pull in sysvinit as a dependency.  but obviously that's not in maverick
[19:20] <barry> mdeslaur: i probably won't matter for natty, but in my ppa test i added Depends: python-keyring (>= 0.5.1)
[19:21] <mdeslaur> barry: that's exactly what I put
[19:21] <barry> mdeslaur: beauty.  thanks
[19:22] <mdeslaur> barry: hmm...that sounds like a sbuild issue that got resolved a while ago (sysvinit)
[19:22] <barry> mdeslaur: maybe i should blow away my mav chroot and rebuild it.  i do keep it up to date
[19:32] <till_> hello, got a quick debhelper question
[19:32] <till_> anyone about?
[19:33] <ScottK> !ask | till_
[19:34] <till_> aight
[19:35] <till_> so, i have a piece of software, i run ./configure && make and then usually copy a single file after 'make' to finalize the install. i debianized the configure and make part, trying to figure out how to tell my package to 'cp' to the designated path/location.
[19:39] <ScottK> till_: man dh_install probably has your answer.
[19:40] <bryce_> ev, any chance you're about?
[19:40] <bryce_> ev, ok well if/when you're back to within working hours, here's the skinny
[19:42] <bryce_> ev, for the past month or so we've been fielding some X crash issues that people using livecd have been reporting to us.  The crashes are caused by an out of memory situation.  The X crashes themselves are just trivial null pointer derefs and easy to fix but the core issue is the OOM situation
[19:46] <bryce_> ev, unfortunately pinning that down is proving to be much more challenging.  However, we *suspect* it is an X client app rather than X itself which is leaking memory massively
[19:46] <bryce_> ev, best guess at this point is maybe it's the installer, since people see the issue only while in livecd environment and usually (always?) while the installer is in use
[19:46] <bryce_> ev, but we're unsure how we can debug this further, and hope you can give us some tips on how to debug ubiquity or other bits that you think could possibly be involved
[19:46] <bryce_> ev, for reference, the first reported bug in the sequence was bug #705078, from mid-Jan.  Suggesting that perhaps the issue arose around the timeframe of ubiquity 2.5.6
[19:51] <till_> ScottK: would i override the dh_install target in my rules?
[19:52] <ScottK> till_: That or make a {packagename}.install file.
[19:52] <till_> ok
[20:02] <hallyn> anyone else having trouble with apt-cacher-ng in natty?
[20:02] <hallyn> it keeps hanging for me, both with libvirt guests and schroots
[20:06] <ScottK> hallyn: Caching any Debian releases?
[20:06] <hallyn> don't think so
[20:08] <till_> ScottK: any idea how long an initial release of a package takes to build on launchpad?
[20:09] <ScottK> It varies considerably.  For PPAs, you can ask in #launchpad for help.
[20:11] <till_> ScottK: ok, will do
[20:17] <hallyn> ScottK: then again, i did have trouble with it before, but now i have just as much trouble without apt-cacher
[20:17] <hallyn> is anyone else having trouble with us.archive.ubuntu.com?
[20:17] <ScottK> I asked about Debian because they recently added sha-512 to their release files and lots of packages didn't handle it well.  It's being/been reverted.
[20:19] <hallyn> ScottK: well i left the default .conf file, but /var/cache/apt-cacher-ng doesn't have any debian.org subdirs
[20:20] <ScottK> OK. So that's not it.
[20:20] <hallyn> Thu Feb 24 14:15:18 2011|/var/cache/apt-cacher-ng/uburep/dists/natty-updates/Release
[20:20] <hallyn> Thu Feb 24 14:16:40 2011|Warning, disconnected during package download
[20:23] <ion> I’ve built the apt-cacher-ng package from natty on my karmic box and it segfaults every once in a while. Haven’t got around to investigating it, since i’ll upgrade the box anyway soon and that may fix the problem.
[20:25] <hallyn> i've turned it off and pointed everything at us.archive.ubuntu.com directly.  still hanging
[20:37] <janimo> ScottK, retried the build myself now
[20:38] <ScottK> Just imagine i replied to that on this channel and not #ubuntu-arm.
[20:41] <ScottK> lamont: Running 2.8.1-1 on my test server.  Seems all good here.
[21:07] <Fjodor> Hi all. https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/650539?comments=all is reported as fixed, but it isn't for me. Does anyone else see that, and how and what can I do to diagnose?
[21:09] <barry> mdeslaur: nope, rebuilding my maverick chroots did not help :(
[21:10] <mdeslaur> barry: got a build log somewhere I can see?
[21:15] <barry> mdeslaur: http://pastebin.ubuntu.com/571920/
[21:18] <mdeslaur> barry: how are you calling sbuild, and are you running natty?
[21:19] <mdeslaur> barry: https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/684931
[21:22] <barry> mdeslaur: that's the bug that's hitting me.  my build host is maverick.  i've already installed a locally backported sbuild to pick up the (nice!) feature of keeping the session alive when the build fails.  i guess i'll build natty's current sbuild for maverick (in my ppa :) for my maverick build machine
[21:22] <barry> or well, i could just remove sysvinit locally
[21:23] <mdeslaur> barry: cool
[21:23] <barry> mdeslaur: thanks for the bugclue :)
[21:59] <bryce_> kirkland, you around today?
[22:05] <bryce_> are any archive admins around?  I've got a package stuck in NEW I think
[22:07] <ScottK> What package?
[22:08] <bryce_> ScottK, wayland
[22:09] <ScottK> Yes.  It's in binary New.
[22:09] <ScottK> https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=wayland
[22:09] <bryce_> ScottK, ok, what needs to happen to get it moved along?
[22:09] <ScottK> It'll still get in since it was uploaded before FF.
[22:09] <ScottK> It needs an archive admin with more time than I have right now to review and accept it.
[22:10] <bryce_> I see
[22:10] <ScottK> Also, it's generally preferable to wait until it's built on all archs (but not required).
[22:11] <bryce_> the only arch remaining is powerpc, and it's been nearly 24 hrs
[22:12] <ScottK> It's way behind.  It's mostly needing an archive admin with time.  Not sure who's day this is.  There's a list somewhere.
[22:13] <micahg> bryce_: https://wiki.ubuntu.com/ArchiveAdministration#Archive days
[22:13]  * StevenK quietly rescores wayland on powerpc
[22:13] <bryce_> ScottK, would it help if I just removed powerpc as an arch and reuploaded?
[22:13] <ScottK> bryce_: No.  I'd look up who's day it is and ask them to review it.
[22:14] <bryce_> hi StevenK, thanks
[22:15] <micahg> bryce_: with the rescore, it'll probably be ready by morning and jdstrand is the AA on duty tomorrow
[22:15] <TheMuso> lol
[22:16] <StevenK> It amused me that the rescore took its estimated start time of 23 hours and changed to 23 minutes
[22:17] <jdstrand> bryce_: what do you need?
[22:17] <bryce_> jdstrand, trying to get wayland in the archive
[22:18] <seb128> bdrung_, what was that nautilus upload?
[22:18] <bryce_> jdstrand, so far I've spoken about it to slangasek, riddell, dustin kirkland, stevek just rescored it moments ago, and now I have your ear :-)
[22:18] <jdstrand> bryce_: unlike the others, I will help you ;)
[22:18] <jdstrand> oh, snap!
[22:19] <bryce_> heh, all have been helpful, I think I'm working on building a straight flush.  Just need to get cjwatson ;-)
[22:20] <jdstrand> :)
[22:20] <micahg> TGIAF
[22:20] <bryce_> jdstrand, the source package has been reviewed by riddell and kirkland and approved by dustin kirkland, but I gather the binaries need reviewed/approved separately?
[22:20] <StevenK> Yes, but binary NEW is much easier
[22:21] <bryce_> jdstrand, amd64, i386, and armel packages have built, ppc is still TBD, but wayland only works on amd64 and i386 so lack of ppc is pretty irrelevant I figure
[22:21] <jdstrand> bryce_: yes. I am doing it. Riddell and kirkland are the real heroes here
[22:21] <bryce_> ok cool
[22:21] <bryce_> if it helps, I've tested the package (via ppa) on 4 different boxes with 2 gfx card architectures
[22:22] <bryce_> I have one more box which has never had wayland or its deps installed, primed to test a clean install from the archive
[22:24] <RAOF> Gak!  Is dhclient broken?
[22:25] <kees> RAOF: yes, fixing
[22:25] <kees> https://bugs.launchpad.net/bugs/724556
[22:25] <RAOF> Ta.
[22:26] <jdstrand> bryce_: accepted. ppc will float in when it does. I even filed the first bug! :)
[22:28] <bryce_> jdstrand, yay thanks!
[22:29] <bryce_> heh, man pages
[22:29] <bryce_> jdstrand, ok thanks for the lintian, I forgot to doublecheck that
[22:29] <jdstrand> bryce_: well, yeah, that's the noise. there was a library one in there too though
[22:30] <jdstrand> bryce_: anyhoo, I'll leave that in your able hands :)
[22:32] <bryce_> jdstrand, thanks on it
[22:32] <jdstrand> sure, np
[22:35] <bdrung_> seb128: sorry for not checking the vcs field
[22:35] <seb128> bdrung_, I've fixed the vcs now
[22:35] <bdrung_> thanks
[22:36] <seb128> bdrung_, but please before uploading desktop packages next time check with #ubuntu-desktop, for one thing there is no recent gio upload so the rebuild doesn't make sense, and you screwed the vcs
[22:36] <bdrung_> gvfs instead of gio?
[22:38] <seb128> bdrung_, no, not since week or the week before
[22:38] <seb128> since this week or...
[22:39] <chrisccoulson_> is this for nautilus?
[22:39] <seb128> yes
[22:39] <chrisccoulson_> i did suggest in #ubuntu-desktop that we should try and figure out what actually broke. did that not happen?
[22:40] <seb128> no, people did a random no change rebuild update without considering the vcs or the change in there
[22:40] <chrisccoulson_> hmmmm, that's not very good :(
[22:41] <seb128> not it's not, well I rebased and did a new upload now, it still doesn't explain what was broken and why
[22:41] <chrisccoulson_> yeah, we should figure that out, especially if it's just a rebuild which fixes it...
[22:41] <seb128> chrisccoulson_, do you think it could be libdbusmenu?
[22:41] <chrisccoulson_> hmmm, i'm not sure. i don't think we've made any ABI breaking changes there
[22:42] <seb128> chrisccoulson_, well I noticed the bug while testing rodrigo's patch today and I don't think I upgrade this box this week out of getting the new libdbusmenu to do some valgrinding
[22:42] <chrisccoulson_> but doing a random rebuild definitely isn't a very scientific way of approaching it :(
[22:42] <seb128> upgraded
[22:43] <chrisccoulson_> i guess it could be that. i can have a look later and try and figure out what broke
[22:43] <seb128> so I wouldn't be surprised if it had something to do with it
[22:43] <seb128> chrisccoulson_, if you want to I will not stop you ;-)
[23:00] <RoAkSoAx> .wub 19
[23:24] <cnd> Riddell, where are we at with the qt package?
[23:25] <Riddell> cnd: just about to upload it now
[23:26] <cnd> Riddell, cool :)
[23:26] <Riddell> sorry for the delay, the builder I was using to test ran out of disk space and I had to learn about eleastic cloud volume things
[23:26] <cnd> hah
[23:26] <cnd> np
[23:26] <cnd> thanks a bunch!
[23:57] <Keybuk> kees: given that the kernel community seem unhappy with your plan to make debugfs root-only, are you going to revert the mountall patch?
[23:58] <kees> Keybuk: nope
[23:59] <kees> Keybuk: they're wrong
[23:59] <kees> Keybuk: all the interfaces in there are designed to be used by the root user.
[23:59] <Keybuk> /sys/kernel/debug/usb/devices isn't
[23:59] <Keybuk> that's intended for all users
[23:59] <kees> then it should move