[00:03] <lifeless> james_w: ^
[00:10] <james_w> lifeless: "which is better?" <- I'm not sure which choice you are referring to?
[00:10] <james_w> and yes, it knows how to sync]
[00:11] <lifeless> ok, cool.
[00:29] <lifeless> james_w: can you make lp:~lifeless/debian/sid/python-testtools/debian lp:debian/python-testtools then ?
[01:31] <slangasek> Keybuk: hum, the latest bootchart assigns all the disk usage to init? :)
[01:51] <Keybuk> slangasek: yeah, something wrong there ;)
[01:51] <Keybuk> I suspect ureadahead isn't working properly
[01:51] <Keybuk> and in a very strange way
[02:09] <Keybuk> oh, I see what I've managed to do
[02:09] <Keybuk> *no* idea why init is spinning though
[02:09] <Keybuk> that's very strange
[02:10] <Keybuk> must be something ptracey
[02:11] <Keybuk> it's not disk usage
[02:11] <Keybuk> that bright red means something else
[02:12] <nixternal> heh
[02:12] <nixternal> bright red isn't a good color to see in relation to a hard drive
[02:12] <Keybuk> stopped/uninterruptable I think
[02:12] <Keybuk> nah, it's bootcharts way of trying to highlight a bad/dead process
[02:12] <Keybuk> the init job is failing because the process doesn't exist
[02:13] <nixternal> oh, I was thinking the fail led's on some drive cages
[02:13] <Keybuk> but I guess isn't trapping out of ptrace properly
[02:41] <Keybuk> slangasek: I'm going to go find joey hess
[02:42] <Keybuk> and explain to him that "--" is not meant to be syntactically vital
[02:42] <Keybuk> who does he think he is?!
[02:42] <Keybuk> Tom Lord?
[02:50] <lamont> Nov 30 19:49:48 staypuff pulseaudio[6813]: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success
[02:50] <lamont> what an interesting errno
[02:50] <lifeless> \o/
[02:57] <Keybuk> haha
[02:57] <Keybuk> usually means "where did I stash that errno, I'm sure I had it here somewhere"
[02:57] <Keybuk> most common mistake
[02:57] <Keybuk>   if (! working) {
[02:57] <Keybuk>     free (shit);
[02:57] <Keybuk>     perror ("argh");
[02:57] <Keybuk>   }
[02:57] <Keybuk> since free can, of course, modify errno ;)
[02:58] <lamont> Keybuk: though nothing is supposed to set errno to zero.
[02:58] <lamont> other than the app, of course.
[02:58] <lifeless> lamont: uhm, actually.
[02:58] <lamont> but hey, you know, that's just errno standards...
[02:58] <lifeless> There is at least one syscall that does
[02:59]  * Keybuk can think of quite a few that do :p
[02:59] <lamont> lifeless: according to the manpage?
[02:59] <lamont> deviants!
[02:59] <lamont> mind you, I gave up on believing that bit of the spec some time ago
[02:59] <lifeless> oh, thats right
[02:59] <lifeless> readdir is what I was thinking of
[03:00] <lifeless> and its just nasty
[03:00] <lifeless> end of dir - return NULL and 'errno is not changed'
[03:01] <Keybuk> can also be
[03:01] <Keybuk>   int saved_errno;
[03:01] <Keybuk>     :
[03:01] <Keybuk>   if (! working) {
[03:01] <Keybuk>     return -1;
[03:01] <Keybuk>   }
[03:01] <Keybuk> type thing where you forget to save the errno
[03:14] <lifeless> slangasek: hi
[03:14] <lifeless> lamont: did you comment on that kernel-img.conf bug?
[03:15] <lifeless> slangasek: I've been keeping an eye out, and lamont and poolie have also had upgrade-to-karmic, look no hooks in kernel-img.conf symptoms.
[03:15] <slangasek> lifeless: I don't think lamont ever commented on it; he sent me a private url to a tarball instead, which I've had zero time to go chase down
[03:16] <lifeless> cool
[03:16] <lamont> meh
[03:16] <lamont> which bug again?
[03:17] <lifeless> 470265
[03:20] <lamont> slangasek: which file did  you like?
[03:20] <slangasek> lamont: IIRC I asked for you to send the contents of /var/log/installer, yes?
[03:20] <lamont> yeah
[03:20] <lamont> but that has lots of files
[03:20] <lamont> how much if any sensitiveish data is in there?
[03:21] <slangasek> depends on how private you consider your partition layout tobe
[03:22] <lamont>  /proc/cpuinfo: model name       : QEMU Virtual CPU version 0.9.1
[03:22] <lamont> lol wut?
[03:22] <slangasek> debconf is smart enough not to leave any passwords there
[03:23] <lamont> so attach all said files to the bug?
[03:23] <slangasek> well, a tarball will probably be less painful for all :)
[03:25] <shtylman> for anyone that was interested in following along: http://www.shtylman.com/archives/154
[03:25] <lamont> thar.  posted^H^Hing
[03:25] <lamont> and yeah, tarball is less work all around
[03:25] <lamont> s/ing/ed/
[03:26] <slangasek> lamont: ta
[03:26] <lifeless> lamont: thanks
[03:26] <lamont> (910.0 KiB, application/x-tar)
[03:26] <lamont> total win
[03:30] <slangasek> StevenK: libapache2-mod-auth-pam is trying to sneak yada back into main ;)
[03:35] <lamont> slangasek: so the ~1build1 version of bind9 should get autosync'ed over with the non ~ version, right?
[03:49] <slangasek> lamont: I think so, yes
[03:51] <godane> hey everyone
[03:52] <godane> i was wondering if you going to put the new squashfs 4.0 with lzma in your kernel
[03:53] <godane> this may allow you guys to have more space
[04:04] <slangasek> lamont: well, your broken /etc/kernel-img.conf is not the same as lifeless's
[04:06] <slangasek> which package was it that included the late fix in karmic for the terminal bell?  seems to have regressed for me in lucid
[04:07] <lamont> slangasek: woot? :(
[04:07] <lamont> anyway, bed.
[04:07] <LucidFox> Is there a cleaner way to get the upstream version in debian/rules with dh 7 other than dpkg-parsechangelog?
[04:07] <slangasek> lamont: add the hook lines to your file by hand, and be merry :)
[04:07] <slangasek> 'night
[04:09] <lamont> slangasek: did that a few days back
[04:09] <slangasek> ok :)
[04:11] <dtchen> slangasek: libgnome. bug 77010
[04:13] <slangasek> dtchen: hum, ok; but libgnome is still at the karmic version, so that doesn't seem to be the package to blame in lucid?
[04:15] <dtchen> slangasek: do your mixer element strings match between 2.6.31 and 2.6.32?
[04:15] <dtchen> (i.e., from 'amixer')
[04:16] <slangasek> answering that question seems to require me to reboot, yah?
[04:16] <dtchen> I'll trawl the commit, one sec.
[04:17] <dtchen> nope, not kernel-side, no need to reboot
[04:17] <dtchen> (the beep rework won't land until 2.6.33)
[04:17] <slangasek> fwiw:
[04:17] <slangasek> Simple mixer control 'Beep',0
[04:17] <slangasek>   Capabilities: pvolume pvolume-joined pswitch pswitch-joined
[04:17] <slangasek>   Playback channels: Mono
[04:17] <slangasek>   Limits: Playback 0 - 15
[04:17] <slangasek>   Mono: Playback 0 [0%] [-45.00dB] [off]
[04:19] <slangasek> dtchen: should I file a new bug about this, and if so, on what package?
[04:21] <dtchen> slangasek: in Sound Preferences's Sound Effects tab, what is the Alert volume set to, and is Enable window and button sounds ticked?
[04:22] <slangasek> dtchen: alert volume is maxed out; 'enable window and button sounds' is not checked.
[04:22] <dtchen> slangasek: are you using metacity or compiz?
[04:22] <slangasek> dtchen: I've also disabled the noises now by disabling the bell in the gnome-terminal config
[04:22] <slangasek> metacity
[04:23] <dtchen> slangasek: looks like pulseaudio, then. bug 301174
[04:24] <dtchen> you can try 'pactl unload-module module-x11-bell'
[04:25] <slangasek> dtchen: no change in behavior
[04:26] <dtchen> slangasek: err, I misread. That was for non-metacity, anyhow.
[04:26] <slangasek> k
[04:27] <dtchen> slangasek: well, I can't see anything at a first glance. The only other package I haven't checked is libcanberra.
[04:28] <StevenK> slangasek: Bah!
[04:28] <StevenK> "yada is moving, kill it!"
[04:29] <ScottK> Only 14 reverse build-depends.
[04:29] <ScottK> None that I care about either ....
[04:34] <slangasek> dtchen: huh - I see libcanberra has a new version in lucid, but seems odd that the problem would be there when I'm only seeing problems with the terminal bell
[04:35] <dtchen> slangasek: no, I'm pretty sure it isn't libcanberra. That was the only part that I hadn't checked when I had responded.
[04:35] <dtchen> it doesn't seem to involve any changes from linux upward through pulseaudio, however.
[04:37] <slangasek> wah
[04:38] <ajmitch> StevenK: I'm surprised you haven't removed, burnt & blacklisted it from ever entering the archive
[04:39] <slangasek> hmm, there's a thought
[04:40] <ScottK> Three archive admins makes a quorum, right?
[04:40] <StevenK> Haha
[05:04] <mathiaz> cjwatson_: hi - why is john in both supported-misc-servers and supported-sysadmin-common?
[05:14] <mathiaz> slangasek: is it correct to say that every package that will be on the -server isos are listed in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/server-ship?
[05:35] <LLStarks> hi. i'm noticing that pybootchartgui won't function without bootchart installed.
[05:35] <LLStarks> why does pybootchart now conflict with bootchart?
[05:57] <slangasek> mathiaz: dunno, sorry
[07:39] <dholbach> good morning
[07:47] <pitti> Good mornin
[07:49] <slangasek> james_w: lp:debian/laptop-mode-tools is lagged behind the archive by about a month and a half (lp:debian/sid/laptop-mode-tools is, however, current)
[07:49]  * slangasek waves to Germany
[07:53] <maco> and *now* all of germany has arrived
[07:57]  * fagan waves from Ireland
[08:09]  * pitti dist-upgrades and gets a debconf question "Various snmp software needs extracted MIBs from RFCs and IANA"
[08:10] <pitti> oh, sure, those MIBs are said to be veery tasty!
[08:23] <dholbach> mdke: thanks
[08:28] <Arc> I just want to point out
[08:28] <Arc> USE="python3" emerge portage
[08:28] <Arc> Gentoo uses Python 3 now
[08:28] <Arc> and compiles packages which support Py3 for both Py2 and Py3 at the same time
[09:54] <cjwatson_> mathiaz`: john> I have no idea, try bzr blame or similar ...
[09:55] <cjwatson_> mathiaz`: not everything on the server image is in server-ship, no; you have to follow the inheritances in the STRUCTURE file too
[10:00] <Arc> what are the current plans for Py3 in Ubuntu?
[10:01] <Arc> Gnome 3 with 10.10 is an obvious hard deadline to getting at least many of the python packages >> py3, but is that just going to be flipping a switch?
[10:10] <maco> Arc: if you wait til its daytime in our tz, you may get an answer
[10:11] <pitti> py3 will certainly not be the default in 10.10
[10:11] <pitti> it's available in the archive, though (for quite a while already)
[10:13] <maco> does fedora even have py3? one of my friends said he hated ubuntu package naming because of the sonames in library package names....and then later switched from fedora to ubuntu because it meant py2.6 and py3 could be parallel installed
[10:16] <StevenK> maco: But 2.6 and 3 are version numbers, not sovers :-P
[10:17] <maco> StevenK: its 5am i dont know the difference
[10:39] <directhex> StevenK, in python terms, what's the difference?
[10:40] <lifeless> they are nearly different languges.
[10:40] <lifeless> something, - probably 80% - of packages haven't updated to support python 3 at all
[10:40] <maco> lifeless: i think directhex is asking the diff between version and so-version in python
[10:41] <tkamppeter_> pitti, hi
[10:41] <pitti> hi tkamppeter
[10:42] <directhex> maco, my point is, given it's not compiled, the target python version is the closest thing to soname versioning
[10:42] <maco> directhex: fine by me. as i said, im too tired to figure out a difference
[10:42] <directhex> maco, have you considered this advanced device w/ a duvet & pillows on it?
[10:43] <maco> yeah yeah im goin im goin
[10:47] <tkamppeter> pitti, it is about a build failure of HPLIP: See https://launchpad.net/ubuntu/+source/hplip/3.9.10-2ubuntu1/+build/1371109/+files/buildlog_ubuntu-lucid-i386.hplip_3.9.10-2ubuntu1_FAILEDTOBUILD.txt.gz
[10:47] <tkamppeter> pitti: I have already uploaded 3.9.10 to Lucid earlier and it built correctly.
[10:48] <pitti> tkamppeter: this seems to be quite an obvious error, tough
[10:48] <pitti> "though"
[10:48] <tkamppeter> pitti, now it is not able any more to run dh_installman. The changes done in the meantime do affect the man pages.
[10:48] <pitti> apparently the debian/foo.manpages specifies a nonexisting file?
[10:50] <tkamppeter> pitti, hp-devicesettings.1 is present.
[10:50] <pitti> tkamppeter: what does the .manpages file specify, and where is it present?
[10:51] <tkamppeter> It simply says
[10:51] <tkamppeter> hp-devicesettings.1
[10:51] <tkamppeter> in one of its lines.
[10:51] <tkamppeter> It is debian/hplip-gui.manpages, by the way.
[10:52] <tkamppeter> The man page is present in the root of the source tree.
[10:52] <tkamppeter> It builds locally for me, but on the buildds it fails.
[10:53] <tkamppeter> And it seems to build on Debian.
[11:04] <pitti> tkamppeter: so what does debian/hplip-gui.manpages specify for the manpage in question? what's the full line?
[11:07] <tkamppeter> The full line is
[11:07] <tkamppeter> hp-devicesettings.1
[11:08] <tkamppeter> Nothing more.
[11:08] <tkamppeter> pitti: ^^
[11:09] <pitti> tkamppeter: that seems to be correct then; try DH_VERBOSE=1 dh_installman -i to see what it does?
[11:10] <tkamppeter> Locally it works:
[11:10] <tkamppeter> DH_VERBOSE=1 dh_installman -i
[11:10] <tkamppeter> 	install -p -m644 hp-devicesettings.1 debian/hplip-gui/usr/share/man/man1//hp-devicesettings.1
[11:10] <tkamppeter> ...
[11:14] <tkamppeter> pitti, if I do rm -rf debian/hplip-gui/usr/share/man
[11:14] <tkamppeter> and try again, the man pages also get successfully installed. dh_installman does
[11:14] <tkamppeter> install -d debian/hplip-gui/usr/share/man/man1/
[11:15] <tkamppeter> to create the needed directory then.
[11:15] <pitti> tjaalton: do you know whether XBACKLIGHT is supposed to work on intel? I only get "No outputs have backlight property", but I'm also using xorg-edgers
[11:15] <pitti> tkamppeter: so what happens if you don't remove the dir before?
[11:19] <btm> pitti: do we need to split the patches in bug 488115 into seperate patches to get the SRU reviewed?
[11:19] <pitti> btm: the current patch is about 20 times bigger than it should be
[11:20] <btm> pitti: hahaha. so yes then.
[11:20] <pitti> so if we have other bugs reported against ruby, they should be referenced in the changelog as well, so that they can be reviewed/tested individually
[11:20] <pitti> but seriously, I strongly advise to not do such things in the first place
[11:20] <pitti> do some careful minimally invasive patches to just fix one or two bugs at a time, get them verified, and to -updates
[11:21] <pitti> with a patch like this, we can hardly ever say whether it breaks something
[11:21] <tkamppeter> Is it possible that more recent versions of dh_installman do not create the directories any more?
[11:21] <cjwatson> tkamppeter: no
[11:21] <pitti> tkamppeter: as you see, it calls install -d, which creates the dirs
[11:21] <cjwatson> or at least it's astonishingly unlikely
[11:22] <tkamppeter> Locally, I get the man pages successfully installed both with and without explicitly creating the directory.
[11:22] <pitti> tkamppeter: you have to reproduce the failing case with DH_VERBOSE, not a working case
[11:22] <cjwatson> and in any case that error message is not that the target directory doesn't exist
[11:22] <cjwatson> the error message says that the source file does not exist
[11:22] <tkamppeter> pitti, then it seems I will have to load a Lucid pbuilder at first.
[11:23] <cjwatson> it literally just tried to open the file and it wasn't there
[11:24] <pitti> tkamppeter: it doesn't look very lucid specific to me, though
[11:24] <pitti> tkamppeter: is the manpage created during package build, or shipped in the orig.tar.gz?
[11:28] <StevenK> cjwatson: As per the desktop-lucid-une spec, unr.<release> is moving -- do you think it belongs in ubuntu.<release>, or shall I create netbook.<release>?
[11:29] <tkamppeter> pitti, the .orig.tar.gz seems to generate it.
[11:29] <pitti> tkamppeter: s/generate/contain/ ?
[11:29] <tkamppeter> pitti, perhaps Lucid executes some stuff in another order
[11:31] <cjwatson> StevenK: I think netbook.<release> is more suitable
[11:31] <tkamppeter> pitti, they get generated by the install-stamp: rule in debian/rules.
[11:32] <pitti> tkamppeter: ah, then I suppose that the arch-independent packages are generated first, before the arch-dep install rule
[11:33] <tkamppeter> The binary-indep: and binary-arch: rules run dh_installman
[11:33] <tkamppeter> Can I make these two rules dependent on install-stamp: to force the needed order?
[11:34] <tkamppeter> I think in general these rules should only get executed when the installation is completed.
[11:34] <pitti> at first sight this seems to make sense
[11:36] <tkamppeter> pitti, it could even make sense to be this way by default.
[11:36] <pitti> "by default"?
[11:37] <cjwatson> StevenK: or maybe even ubuntu-netbook.<release>?
[11:37] <tkamppeter> Are these db_ helpers not generally supposed to be run after "make install"?
[11:37] <pitti> tkamppeter: as long as people insist on writing the same (buggy?) debian/rules manually over and over (i. e. not using dh7 or cdbs), there is no "default" :)
[11:37] <cjwatson> tkamppeter: install-stamp is not a required target in debian/rules. If you want inter-target dependencies, you *have* to specify them yourself
[11:38] <cjwatson> especially for targets that are specific to your debian/rules file
[11:38] <pitti> tkamppeter: some might well work before, but in general most of them make more sense after the install target, yet
[11:38] <cjwatson> even 'install' is not a required target, come to that
[11:38] <pitti> tkamppeter: but install-stamp is just a convention, not something that buildds even understand (or dpkg-buildpackage)
[11:39] <tkamppeter> pitti, cjwatson, broken debian/rules from Debian maintainer which simply worked by accident for all the time ...
[11:39] <pitti> seems like it
[11:41] <tkamppeter> For me it looks like that the quickest solution is to force order by this dependency, the best solution would that the Debian maintainer redesigns the debian/rules file.
[11:41] <cjwatson> forcing the order is entirely correct and not a workaround at all
[11:42] <cjwatson> there's nothing intrinsically broken about a rules file written in that way, when the inter-target dependencies are correct
[11:42] <cjwatson> the smarter helpers tend to centralise things such that we can fix bugs in a single place, but it's not actually wrong not to use them :)
[11:55] <btm> pitti: uploaded new debdiff to bug 488115 that contains two small patches to fix segv bugs with corresponding lp bugs.
[12:02] <ogra> The following packages have unmet dependencies:
[12:02] <ogra>   lightsoff: Depends: seed but it is not installable
[12:02] <ogra>   swell-foop: Depends: seed but it is not installable
[12:02]  * ogra scratches head
[12:03]  * ogra wonders what in ubuntu-desktop pulls in webkit stuff
[12:05] <davmor2> ogra: software center?
[12:05] <ogra> oh
[12:05] <davmor2> ogra: only guessing
[12:06] <davmor2> ogra: ubiquity too
[12:06] <ogra> oooh, right, the new slideshow stuff
[12:06] <ogra> thanks, i didnt think of that
[12:07] <cjwatson> interestingly ubiquity-frontend-gtk doesn't actually depend on python-webkit or anything ...
[12:07] <cjwatson> ev: is that an oversight?
[12:08] <ev> nope
[12:08] <ev> because ubiquity can function just fine without the slideshow
[12:10] <cjwatson> hmm. just feels odd that there's no mention of it in the control file. Maybe a Suggests or something?
[12:10] <cjwatson> or even Recommends given that we want the slideshow in Ubuntu
[12:11] <cjwatson> the odd thing I think is that the slideshow essentially only works by accident because python-webkit is in desktop
[12:11] <cjwatson> which feels odd to me somehow, although I don't know the best fix
[12:16] <ev> well, we could just add python-webkit to the seeds as well, but I'm equally fine with a Suggests or Recommends.
[12:17] <ev> I just wanted to make it as easy as possible for derivatives that didn't want the slideshow
[12:41] <lamont> dear firefox.  why is it that every morning when I get on my computer, your window is dead-n-gone _AGAIN_??
[12:41] <lamont> no core file, no nothing.
[12:43] <StevenK> I'd suggest the OOM killer, but it's somewhat suspcious it's always firefox
[12:47] <tjaalton> pitti: so running 'xbacklight -get' fails? works for me with the karmic versions
[12:47] <cjwatson> could somebody in the desktop team deal with MIRing 'seed', please? reasonably urgent since CD builds are failing due to this
[12:48] <tjaalton> pitti: of course -set works too
[12:48] <tkamppeter> pitti, about the HPLIP I have found the cuase of the problem. HPLIP is running itself to generate its man pages and this is done by the debian/rules script, instead of letting "make install" do it). I think I will remove that unneeded part.
[12:54] <pitti> tjaalton: right, that gives said error message
[12:55] <pitti> tkamppeter: ah, good
[12:55] <pitti> tjaalton: if it's generally supposed to work on intel, then I just blame the xorg-edgers packages :)
[12:57] <tjaalton> pitti: yep :)
[12:57] <pitti> cjwatson: it's only required by the "lightsoff" package, AFAICS, and we don't even intend to install that by default any more; thanks for pointing out, on my list now
[12:58] <cjwatson> pitti: lightsoff and swell-foop
[13:48] <mr_pouit> w/w 20
[13:48] <mr_pouit> grr
[13:56] <goldins> is there a howto recompile packages the dpkg way? I know you start with apt-get source [package]
[13:57] <cjwatson> debuild
[13:57] <cjwatson> (in the directory that apt-get source creates)
[13:57] <cjwatson> see manual pages etc. for more details
[13:57] <goldins> thanks!
[14:03] <goldins> the debian administration guide for this thing tells an outright lie
[14:04] <goldins> "of course we did miss out any editing of the package to make it build differently, but if you know already you need to rebuild a package to change its options, or bahaviour, you will know how to do that!" -- I don't want to edit the package, just change the options passed to the configure script. How do I do that?
[14:10] <bdrung_> mdeslaur: you fixed the security issue of libgd2 in the stable version, but it is not fixed in lucid.
[14:10] <cjwatson> goldins: edit debian/rules
[14:10] <cjwatson> goldins: you *need* to edit the package, even if that isn't what you *want* to do :-)
[14:11] <goldins> cjwatson: I see! thanks again
[14:16] <mdeslaur> bdrung_: correct...we track issues that are not fixed in lucid. If the package doesn't get synced or merged with debian, we'll release an update to it long before lucid releases.
[14:18] <bdrung_> mdeslaur: thank for the info.
[14:32]  * ttx painfully tries to get a bzr branch from LP... it's... slow... today...
[15:02] <cjwatson> pitti,sabdfl: TB meeting?
[15:02] <cjwatson> haven't seen Keybuk around
[15:07] <sabdfl> cjwatson: thanks, incoming
[16:06] <h4writer> MacSlow, ping
[16:06] <MacSlow> h4writer, pong
[16:06] <h4writer> hi MacSlow, it's about bug #489414, if you think it is easier to debug over chat, go ahead...
[16:10] <MacSlow> h4writer, hm... maybe somehow your from-source installs messed up the system-wide icon-cache
[16:11] <h4writer> So removing the cache would solve it?
[16:13] <MacSlow> h4writer, hm... awn installs (or used to install) icons in /usr/share/hicolor maybe those override everything else
[16:14] <h4writer> MacSlow, I have no /usr/share/hicolor folder
[16:14] <MacSlow> h4writer, awn used to have a plugin replacing notification-daemon... maybe that's "getting in the way"
[16:15] <MacSlow> h4writer, but that would not explain why you still see notificatino-bubbles rendered by notify-osd
[16:15] <h4writer> I have had notification-deamon, but I removed it
[16:16] <h4writer> *had notification-deamon in jaunty, upgraded and removed it in karmic
[16:16] <MacSlow> h4writer, http://launchpadlibrarian.net/36182432/Schermafdruk.png clearly is rendered by notify-osd
[16:16] <h4writer> MacSlow, yeah it is definitly notify-osd ;-)
[16:17] <MacSlow> h4writer, do you know malept or moonbeam in #awn?
[16:17] <h4writer> yes
[16:42] <Arc> pitti: so what is the plan to support both py2 and py3 versions of packages until then?  or is Ubuntu basically dying for Python developers overall?
[16:43] <Arc> Gentoo did this through slotting; each major.minor python version gets its own slot now, so even if you have py2.5 2.6 and 3.1 packages which support all will be compiled and installed for all
[16:44] <ScottK> Arc: Debian and Ubuntu share a system for supporting multiple Python interpreters.
[16:44] <Arc> ScottK: and that is?
[16:44] <ScottK> Currently a lot of stuff doesn't particularly work on Python 3, so we don't see a great rush.
[16:45] <Arc> is it not generally understood that developers use Ubuntu too?
[16:46] <ScottK> Certainly.
[16:46] <ScottK> That's why we ship python-3.1
[16:47] <Arc> but do you, for example, ship cherrypy for py3?
[16:47] <Arc> or sqlalchemy, or even wsgi
[16:47] <ScottK> Nope.
[16:48] <kklimonda> Arc: there is no stable release of sqlalchemy that supports python 3.x
[16:48] <kklimonda> Arc: and that's similar for most libraries and applications
[16:48] <ScottK> I'd expect after Lucid there will be a lot more of a push to support Python 3.
[16:49] <Arc> kklimonda: im using sqlalchemy on py3 right now.
[16:49] <ebroder> Arc: Then you're using a prerelease version
[16:50] <ebroder> 0.6 isn't the stable release yet
[16:50] <Arc> so? it will be by the time my software is ready to release
[16:50] <Arc> developers need to target tomorrow, not today, or the entire community plays a continual game of catch-up
[16:51] <Arc> Ubuntu doesn't support packages for tomorrow, or today, but yesterday.  there isn't even an option to install new versions of libraries
[16:52] <Arc> I'm frustrated that at the end of 2009 I still have to maintain my Gentoo workstations and on my colocated servers because Ubuntu fails to meet my needs as a developer
[16:52] <ScottK> Arc: This channel is for development of Ubuntu, not complaing about it.  I think you probably want #ubuntu-offtopic.
[16:53] <Arc> I was hoping that this may be useful feedback, but I guess it'll be ignored
[16:54] <ebroder> There was a valid point in there - do we have an answer yet for dealing with python 3 packages? Most of the things that have "Python 3 compatibility" just work after you run them through 2to3. Separate source packages?
[16:55] <ScottK> It's not that I don't understand your problem (or care) but that there's a lot of extra work involved in supporting what you ask for and we really don't have the resources.
[16:55] <cjwatson> he's left
[16:55] <ScottK> ebroder: We have other, more pressing, problems in the Debian/Ubuntu Python stack.
[16:55] <ScottK> Ah.  Thanks.
[16:56] <cjwatson> I believe we have a general expectation of python3-* binary packages
[16:56] <cjwatson> and separate source packages if they need more than 2to3
[16:56]  * ebroder nods
[16:57] <kklimonda> ScottK: btw, how can we (and by we I mean 'me') help with Python stack if you need more resources?
[16:58] <ScottK> kklimonda: Well at the moment the blockers are primarily not resource driven.  Once we get Python 2.6 into Debian and work on a new Python policy moving forward, then I think there will be more to do.
[16:59] <ScottK> kklimonda: I was more responding to his complaints about lack of development versions of libraries than Python specifically.
[17:31] <mathiaz> cjwatson: hi - I'm looking at the ubuntu-server package set in lucid
[17:31] <mathiaz> cjwatson: libgtop2 is part of it - why?
[17:32] <mathiaz> cjwatson: seems to be gnome related
[17:32] <cjwatson> something depends or build-depends on it. check germinate output
[17:32] <mathiaz> cjwatson: and what's the difference between the ubuntu.lucid and platform.lucid seeds?
[17:32] <cjwatson> the package sets are unlikely to be tightly closed in the way you expect
[17:33] <cjwatson> platform.lucid is stuff that's shared between flavours
[17:33] <mathiaz> cjwatson: is the former only used for iso/image creation?
[17:33] <cjwatson> err - no?
[17:33] <mathiaz> cjwatson: ok
[17:36] <cjwatson> mathiaz: libapache2-mod-perl2 build-depends on libgtop2-dev
[17:37] <mathiaz> cjwatson: how did you find that information?
[17:37] <cjwatson> I grepped germinate output
[17:37] <cjwatson> cjwatson@rookery:/home/ubuntu-archive/public_html/germinate-output/ubuntu.lucid$ grep ^libgtop2 *
[17:37] <cjwatson> or you can run germinate yourself locally
[17:38] <mathiaz> cjwatson: great - thanks!
[17:44] <mathiaz> jdstrand: hi!
[17:45] <mathiaz> jdstrand: where is the list of server supported files for hardy?
[17:46] <superm1> mathiaz, moving lilo to universe might have implications for installer, and it's rdepends list tons of kernel packages
[17:47] <mathiaz> superm1: right - I think that point was mentioned during the UDS discussion - the notes are unclear - cjwatson may have said it was ok though.
[17:47] <mathiaz> superm1: if you have other concerns for lilo don't hesitate to add it to the wiki page
[17:48] <superm1> mathiaz, i was gonna add those comments last night (if they weren't there), but couldnt get to the wiki page.  nothing else comes to mind though
[17:49] <cjwatson> I'm unsure about lilo
[17:49] <cjwatson> if we remove it from main, that will indeed basically take out that installer component as well, which is currently an option
[17:49] <cjwatson> that may be OK, we just need to be aware it's a pretty firm commitment!
[18:04] <jdstrand> mathiaz: hi! it has not been generated yet
[18:06] <jdstrand> mathiaz: ie we have this http://people.canonical.com/~ubuntu-security/dapper-lts-server-supported.txt, but not one for hardy yet
[18:06] <mathiaz> jdstrand: ok - has the list been generated by hand?
[18:11] <jdstrand> mathiaz: I think it is mostly automated. see seed-report in UCT
[18:11] <mathiaz> jdstrand: ok - thanks.
[18:12] <kirkland> mvo_: howdy, around?
[18:12] <kirkland> mvo_: i'm having a few issues merging/building eucalyptus for Lucid, looks like problems with librampart
[18:12] <kirkland> mvo_: i noticed that you're the maintainer ;-)
[18:14] <kirkland> mvo_: hmm, well, you're listed as the maintainer, but have no changelog entries; perhaps I'm mistaken :-)
[18:16] <kees> mathiaz: the dapper supported list was reviewed by hand, yes.  it required a lot of seed splitting
[18:16] <kees> mathiaz: hardy will likely require the same attention.
[18:16] <kees> (as will lucid, etc)
[18:28] <mvo_> kirkland: I helped soren with rampart, but he took over then
[18:32] <kirkland> mvo_: okay, thanks!
[18:33] <kirkland> mvo_: i'm having a build issue with eucalyptus that I *think* I can solve with a symbol|shlib file in rampart
[18:33] <kirkland> mvo_: i was looking for someone to confirm this with
[18:52] <maxb> james_w: Could I get an UDD nudge for missing import subversion 1.6.6dfsg-2 ?
[18:55] <Laney> maxb: file bugs: lp/udd
[19:07] <james_w> hi maxb.
[19:07] <james_w> sorry for the delay, done now
[19:07] <maxb> Thanks. Is there anything I can do to assist in figuring out why it happens?
[19:09] <maxb> And for that matter, is the importer code open-source?
[19:09] <jono> didrocks, are you planning on making a panel applet Quickly template?
[19:09] <slangasek> kirkland: what exactly is the build issue?
[19:10] <kirkland> slangasek: http://paste.ubuntu.com/332545/
[19:10] <kirkland> slangasek: any help would be *much* appreciated
[19:10] <kirkland> slangasek: I've spent my entire day so far on this
[19:10] <slangasek> interesting error; one sec
[19:11] <james_w> maxb: most of the logic is in bzr-builddeb, the stuff that polls LP is a couple of hacky scripts
[19:11] <didrocks> jono: not sure, as the panel will be deprecated in GNOME3, I'm waiting for the replacement model
[19:11] <kirkland> slangasek: thanks for looking; standing by ....
[19:12] <slangasek> kirkland: the issue is that the library is installed in /usr/lib/axis2/lib instead of /usr/lib; this a) is probably an FHS violation, b) requires passing a -l option to dh_shlibdeps if you *really* want to do this (and assuming the rpath is correctly set) - but I suggest fixing a) instead
[19:13] <slangasek> all shared libraries in Ubuntu are supposed to be installed to /usr/lib, and that appears to apply here
[19:13] <jono> didrocks, the panel is in a state of flux, but indicators are not going away though
[19:13] <kirkland> slangasek: cool, thanks
[19:14] <kirkland> soren: any idea why you chose to install rampart to /usr/lib/axis2/lib ?
[19:14] <slangasek> kirkland: oh, the dpkg error even tells you that the binary has no rpath set - so yeah, as built this would never work anyway
[19:15] <didrocks> jono: I'll log a bug to remind me to take a look at that. But gedit plugin is on a higher priority for 0.4 (next January) :)
[19:15] <slangasek> (setting rpath might fix the shlibdeps problem; moving the library to /usr/lib is still preferred)
[19:15] <jono> didrocks, np :)
[19:15] <jono> was just curious :)
[19:16]  * didrocks logs a bug as a reminder :)
[19:16] <kirkland> slangasek: okay, i'll fix up rampart, and pass the debdiff by you for verification
[19:16] <kirkland> slangasek: i haven't done too much library work
[19:18] <slangasek> kirkland: the key bit is probably just setting --prefix=/usr instead of --prefix=/usr/lib/axis2 in debian/rules; there's probably some other cleanup to do of various extra symlinks, though
[19:18] <kirkland> slangasek: okay, i'm looking into that now
[19:18] <slangasek> lrwxrwxrwx root/root         0 2009-10-12 10:57 ./usr/lib/axis2/include/axis2-1.6.0/rampart_token_processor.h -> ../../../../include/rampart-1.3.0/rampart_token_processor.h:  do not want
[19:18] <kirkland> slangasek: i was wondering if a set of symlinks in /usr/lib/ might suffice?
[19:19] <slangasek> oh damn; we really need that link farm, because the include option we use is -I/usr/lib/axis2/include/axis2-1.6.0
[19:19] <kirkland> slangasek:         cd debian/$(cdbs_curpkg)/usr/lib ; for x in axis2/lib/*.so*; do ln -s $$x; done
[19:19] <kirkland> slangasek: something like that
[19:20] <slangasek> the /usr/include/axis2-1.6.0 looks redundant then, however
[19:20] <slangasek> kirkland: mumble; that part needs fixed up to make sure we really get our links in /usr/lib
[19:21] <slangasek> oh, that's what you're doing, so... right
[19:21] <slangasek> well, no
[19:21] <slangasek> the current linkage is only because of the modules/ subdir
[19:21] <slangasek> if you set the prefix right, the main lib should land in /usr/lib automatically, and the modules fixup just needs adjusted to not include axis2/lib in the path
[19:22] <slangasek> oh, that will install to /usr/modules, hah
[19:22] <slangasek> yeah, so s/ln/mv/ :P
[19:22] <kirkland> slangasek: fun
[19:23] <slangasek> kirkland: --prefix=/usr/lib/axis2 --libdir=/usr/lib, I think
[19:24] <slangasek> (and shame on upstream for this build system)
[19:24]  * kirkland tries
[19:24] <kirkland> slangasek: um ... are you sure about that?
[19:25] <slangasek> nope
[19:25] <kirkland> slangasek: should it be: --prefix=/usr/lib --libdir=/usr/lib ?
[19:25] <kirkland> oh, hmm
[19:25] <slangasek> no, I'm sure it's not that :)
[19:25] <kirkland> slangasek: i see now
[19:25] <kirkland> slangasek: yeah, my bad
[19:26] <kirkland> slangasek: okay, building/testing
[19:30] <slangasek> kirkland: doesn't work, because the upstream build doesn't use --libdir as God intended
[19:30] <kirkland> slangasek: my build agrees with you
[19:30] <kirkland> slangasek: arg... and this package does not debuild repeatedly cleanlyh
[19:30] <kirkland> what a mess
[19:30] <slangasek> yep
[19:31] <slangasek> prglibdir=$(prefix)/lib
[19:31] <slangasek> DIE
[19:32] <slangasek> kirkland: well, quick-and-dirty will be to just move the files around in the debian/rules target
[19:32] <slangasek> librampart.so* to /usr/lib; libmod_rampart.so* symlinked to /usr/lib from the axis2 dir (because there's a modules.xml used by axis2 which I guess needs to be in the same directory as the files)
[19:33] <kirkland> slangasek: why mv and not ln ?
[19:34] <slangasek> because there's no reason for librampart to be in a subdir of /usr/lib at all
[19:34] <deryck> jcastro, ping
[19:34] <slangasek> the only reason to leave libmod_rampart in a subdir is the modules.xml that references it
[19:35] <slangasek> module.xml, rather
[19:35] <kirkland> slangasek: gotcha
[19:35] <kirkland> slangasek: okay, well i had build an ln'd one in the meantime; i've built/installed that; testing the eucalyptus build now
[19:35] <kirkland> slangasek: if that works, i'll go back in and mv those .so's around
[19:36] <jcastro> deryck: pong
[19:37] <mathiaz> cjwatson: in the germinate output, what's the difference between all and all+extra?
[19:38] <slangasek> interesting that the utility lib provides no .so link at all
[19:39] <kirkland> slangasek: \o/  it built!!!
[19:39] <kirkland> slangasek: that's the first time this build has completed for me in ~1 week!!!
[19:39] <jcastro> slangasek: I think I just ran into the japanese symbol for death.
[19:39]  * kirkland hugs slangasek 
[19:39] <jcastro> slangasek: fscking it now
[19:39] <slangasek> jcastro: heh
[19:40] <slangasek> kirkland: eep
[19:40] <kirkland> slangasek: http://paste.ubuntu.com/332560/
[19:40] <kirkland> slangasek: that was my quick/dirty fix
[19:40] <slangasek> kirkland: minor buglet I just noticed, btw: linking to -lmod_rampart is actually the wrong thing to do, we should be linking against librampart.so instead... :)
[19:40] <kirkland> slangasek: now i'll try to clean it up a bit
[19:40] <slangasek> the symbols it uses are provided by the utility lib - the only reason this links against -lmod_rampart is that this is the only .so available (!)
[19:41] <slangasek> so if rampart were fixed to provide librampart.so, and eucalyptus were then fixed to use -lrampart, all the libmod_rampart symlinking could be tossed
[19:42] <kirkland> slangasek: hrm, okay ...  there seems to be too many options on the table for me right now
[19:42] <slangasek> kirkland: understood - don't let me get in the way of your progress
[19:42] <kirkland> slangasek: i am going to have to modify both rampart and eucalyptus at this point
[19:43] <kirkland> slangasek: if you have a preferred methodology, let me know which it is ;-)
[19:43] <kirkland> slangasek: but i want something that can get my eucalyptus build going today-ish
[19:43] <james_w> maxb: failure information is now available at http://package-import.ubuntu.com/failures/.bzr/failures/
[19:43] <maxb> excellent
[19:43] <james_w> maxb: I had to work out how to bypass loggerhead so that I could make it public
[19:43] <james_w> sorry for not doing that early
[19:43] <slangasek> kirkland: well, the right thing to do here really is to have librampart-dev provide /usr/lib/librampart.so, *not* libmod_rampart.so, and have eucalyptus link to -lrampart
[19:43] <slangasek> kirkland: but that doesn't need to be addressed right now
[19:44] <james_w> I'm going to file an RT now to take down loggerhead as we don't need it and to just serve the logs directly
[19:44] <kirkland> slangasek: okay
[19:45] <slangasek> kirkland: doing it the way it's done now does incur some overhead because eucalyptus never uses anything that's in mod_rampart itself... but I suppose the overhead is negligible, all things considered ;)
[19:46] <soren> kirkland: Yes.
[19:47] <soren> kirkland: Give me a second, it's going to take me a bit to phrase this tactfully.
[19:47] <kirkland> slangasek: gotcha
[19:48] <soren> kirkland: Axis2/C and Rampart/C are both rather new to the notion of being installed in a manner roughly corresponding to the FHS. Some might even say that they're not quite there yet.
[19:48] <soren> kirkland: I may or may not be one of the people of that opinion.
[19:48] <slangasek> soren: right, we covered that in the interim
[19:48] <slangasek> 11:31 < slangasek> prglibdir=$(prefix)/lib
[19:48] <slangasek> 11:31 < slangasek> DIE
[19:48] <slangasek> :-)
[19:49] <kirkland> heh
[19:49] <soren> Well :)
[19:50] <soren> Right, and the point is that none of the projects that use axis2 have the faintest clue where to find things if we put them were people who are used to dealing with sensible libraries expect to find things.
[19:50] <soren> Namely with libraries in /usr/lib or /usr/lib/axis2 and headers in /usr/include/axis2 or whatnot..
[19:50] <kirkland> slangasek: I *think* this covers your first suggestions -> http://paste.ubuntu.com/332570/
[19:51] <kirkland> slangasek: http://paste.ubuntu.com/332571/
[19:51] <soren> So in order to adhere as much as possible to the FHS while doing as little work as possible and not confusing the heck out of every project depending on them, I opted for the slightly odd ball directory layout, sprinkled with a metric ton of symlinks.
[19:52] <soren> The end result is a train wreck, but the starting point was a natural disaster.
[19:52] <kirkland> slangasek: hmm, based on what soren is saying now, i'm wondering if ln might be preferred over mv
[19:56] <maxb> james_w: How do you configure loggerhead to do that? (Hierarchical display of a big directory tree of branches)  I tried to make it do that for me, and failed!
[19:56] <slangasek> kirkland: since nothing else depends on librampart.so (because it can't), mv won't hurt any other projects, and will be beneficial in the long run
[19:57] <kirkland> slangasek: ack; done
[19:57] <kirkland> slangasek: i'll be uploading shortly ;-)
[19:57] <slangasek> cheers
[19:57] <kirkland> slangasek: anything else lowhanging with this mess that I should clean up while I'm in here?
[19:57] <james_w> maxb: loggerhead has a serve-branches script that I think does it
[19:58] <slangasek> kirkland: hmm, /usr/lib/libmod_rampart.so.0 -> axis2/lib/libmod_rampart.so.0 - not axis2/modules/rampart/libmod_rampart.so.0?
[19:58] <maxb> james_w: And should I be concerned that there isn't a 'subversion' failures file?
[19:58] <james_w> maxb: well, subversion has caught up now, so normally that would be correct
[19:58] <slangasek> AFAIK, axis2/lib/libmod_rampart.so.0 was itself created by the debian/rules, and we can get rid of that indirection
[19:58] <james_w> maxb: it does mean that I'm not sure why the upload was missed
[19:59] <kirkland> slangasek: true
[19:59] <james_w> maxb: I don't suppose LP backdates the publishing record creation date to the time of the Debian upload when it is imported?
[20:00] <maxb> That sounds entirely plausible
[20:00] <james_w> that would certainly explain it
[20:00] <slangasek> kirkland: here's what I would do: http://paste.ubuntu.com/332577/
[20:01] <maxb> Interesting that there's a zero-length failures file for python-defaults, but no branches in launchpad for it
[20:02] <kirkland> slangasek: hmm, why the for loop over a single file?
[20:02] <soren> kirkland, slangasek: The current state of things is the result of a long, long night of trial-and-error. If you guys can get it to be sensible and still have stuff build *and* run against it, more power to you :)
[20:02] <slangasek> kirkland: ask soren, that's just me editing what was already there :)
[20:02] <james_w> maxb: the zero length files are holders
[20:03] <soren> slangasek: Sorry, what?
[20:03] <slangasek> soren: the "for x in librampart.so" at http://paste.ubuntu.com/332577/
[20:03] <james_w> maxb: when codehosting ran out of space I was asked to pause the imports, and haven't asked it to try all those yet
[20:03] <maxb> ah, ok.
[20:04] <james_w> maxb: most of those are ones that we may want to use older branches for, but I think the best way to deal with it might be to import them all, and then overwrite the ones that we wish to do that for
[20:04] <soren> slangasek: Err.. Good question. I think perhaps in an earlier version, it iterated over more than just the one file, and when I removed the other(s), I didn't notice there was just the one left, and just left the loop there.
[20:04] <soren> slangasek: That's my best guess. I have no actual recollection.
[20:05] <soren> Of anything. Ever.
[20:05] <slangasek> soren: fair 'nuff, doesn't really matter :)
[20:06] <slangasek> I have now looked at this package name long enough that it has decomposed in my brain into "the library containing parts of rams"
[20:07] <kirkland> slangasek: many thanks for your help
[20:07] <slangasek> n/p
[20:07] <kirkland> slangasek: i had not made much progress until our conversation
[20:32] <cjwatson> mathiaz: extra is "stuff that came from the same source package as something that's seeded, but isn't seeded itself"
[20:38] <mathiaz> cjwatson: could all be considered a good list of all packages in main, with the (multiple) reasons why they're in main?
[20:48] <pitti> Keybuk: I uploaded your udev today, and CK; works fine
[20:49] <Keybuk> pitti: I saw, great :D
[20:50] <pitti> hah! DeviceKit-disks is obsolete!
[20:50] <ebroder> ...that didn't take long
[20:50] <Keybuk> there were more input_id changes in GIT head since I last pulled, do you want those uploaded too? :0
[20:50] <cjwatson> mathiaz: I'm afraid not
[20:50] <pitti> Keybuk: would be nice, yes
[20:50] <Keybuk> pitti: oh, that reminds me, I noticed last night that you removed the "and started hal" from gdm.conf ... that was a bad idea :p
[20:50] <cjwatson> mathiaz: "all" is all the packages seeded *in the flavour of Ubuntu you're looking at*
[20:51] <slangasek> pitti: huh, obsoleted by what?
[20:51] <pitti> Keybuk: eww, oops; I better put that back for now
[20:51] <cjwatson> mathiaz: but main = Ubuntu + Kubuntu + Edubuntu + Xubuntu + ...
[20:51] <mathiaz> cjwatson: right.
[20:51] <Keybuk> pitti: X seems to spin if it doesn't have it though :)
[20:51] <Keybuk> pitti: so don't worry about putting it back
[20:51] <pitti> slangasek: just renamed; but I was curious how people would jump at it :)
[20:51] <cjwatson> (actually not all the specific examples I listed but you get the idea)
[20:51] <Keybuk> I was just surprised :D
[20:51] <slangasek> pitti: heh
[20:51] <mathiaz> cjwatson: that would be enough though - I'm trying to get a list of package in main "related" to the server team
[20:51] <Keybuk> slangasek: iz now udisks
[20:51] <pitti> slangasek: since DeviceKit is no more, it's now renamed to "udisks"
[20:52] <slangasek> buh?  DeviceKit is no more?
[20:52] <slangasek> crack fiends, the lot of them
[20:52] <Keybuk> DeviceKit was stillborn
[20:52] <pitti> slangasek: it only existed for a couple of weeks
[20:52] <cjwatson> mathiaz: it's actually Ubuntu + Kubuntu + Edubuntu + UNR, right now
[20:52] <ebroder> So it's all udev now?
[20:52] <Keybuk> I think the first release was the week before LF Collaboration Summit last year
[20:52] <slangasek> the crucial couple of weeks that led us to shipping it in 9.10? :)
[20:52] <Keybuk> and at LF Collaboration Summit we had that udev security bug where you could send messages over netlink to it
[20:53] <Keybuk> and we went "ooh, didn't know you could *do* that"
[20:53] <Keybuk> fixed the security bug
[20:53] <Keybuk> then actually extended udev to *use* that functionality
[20:53] <Keybuk> then we didn't need the DeviceKit daemon anymore
[20:53] <cjwatson> mathiaz: sure, that's enough. Bear in mind that it only gives you the first reason though. If you want everything, look in rdepends/ in the output of a full germinate run
[20:53] <slangasek> so devicekit-power is also gone?
[20:53] <Keybuk> slangasek: we didn't ship DeviceKit in 9.10 I don't think
[20:53] <mathiaz> cjwatson: oh - cool.
[20:53] <Keybuk> maybe 9.04 briefly
[20:53] <cjwatson> slangasek: we shipped DeviceKit-* in 9.10, but not DeviceKit itself
[20:53] <Keybuk> slangasek: devicekit-power will be upower I think
[20:53] <slangasek> oh, you mean the daemon specifically, ok
[20:54] <Keybuk> the design is quite nice now
[20:54] <superm1> seriously devicekit is no more?
[20:54] <Keybuk> the kernel deals directly with hardware, and sends update events via uevents to udev
[20:54] <Keybuk> udev does basic processing of them and maintains a db of extra information
[20:55] <Keybuk> and sends further update events out back over netlink to things like udisks, upower, PulseAudio, NetworkManager, Upstart, etc.
[20:56]  * ajmitch can't keep up with all these moving pieces
[20:57] <slangasek> things are converging on an architecture
[20:57] <slangasek> previously, they weren't
[20:57] <slangasek> this is an improvement :)
[20:57] <sebner> slangasek: hi! Can you tell me the percentage of  main <-> universe packages? My grades at university are thanking ;D
[20:58] <superm1> but this also means an app that needs to work on say 3 releases needs to know how to talk over dbus to udisks, and then if they want karmic support devicekit-disks, and if they want jaunty support HAL
[20:58] <superm1>  /shrug
[20:58] <Keybuk> superm1: so don't do that then :)
[20:58] <Keybuk> write your app to support lucid
[20:58] <Keybuk> which is an LTS
[20:58] <slangasek> sebner: zgrep -c ^Package: /var/lib/apt/lists/*lucid_*Packages ?
[20:59] <sebner> slangasek: not on ubuntu right now :(
[20:59] <sebner> hi pochu :)
[20:59] <slangasek> sebner: 6707 binary packages in main (on amd64), 22277 in universe
[21:00] <pochu> sebner: yo :)
[21:00] <ion> keybuk: Re: <http://people.canonical.com/~scott/daily-bootcharts/>, it could be neat to have a system that upgrades the system in small parts (e.g. dividing the upgrade at the points where apt would do separate dpkg invocations) and measures a new entry for that list after each part, pointing out which packages were upgraded. So, instead of daily bootcharts, we’d have a bootchart roughly for each upgradable upload.
[21:00] <Keybuk> ion: whuh?
[21:00] <Keybuk> how would that help anything?
[21:00] <slangasek> he wants 'bootchart blame' :)
[21:00] <sebner> slangasek: cool thanks!
[21:00] <kirkland> slangasek: wow, 1/4 are in main ...  i had no idea that percentage was so high
[21:01] <slangasek> kirkland: I blame UEC ;)
[21:01]  * kirkland ducks, covers
[21:01] <Keybuk> it's generally pretty obvious what's to blame for any major change
[21:01] <kirkland> slangasek: i suppose i did serve that one up to you, underhand
[21:20] <kirkland> Is there anyone around with buildd super powers might be able to increase the priority of https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1374891 ?
[21:24] <pitti> kirkland: nudged
[21:24] <kirkland> pitti: thanks martin!
[21:39] <kirkland> arg
[21:54] <dipponaught[away> im trying to create a debdiff of the linux-image-2.6.32-6-generic sources (directions from wiki://PackagingGuide/Recipes/Debdiff) but debuild -S overwrites the original stuff. how do i increment my version from linux_2.6.32-6.8 to linux_2.6.32-6.9?
[21:55] <Keybuk> dch -i
[21:55] <Keybuk> though it's harder with the kernel stuff ;)
[21:55] <Keybuk> think you have to edit debian.master/changelog instead
[21:55] <Keybuk> and if you increment the version, you'll run into the ABI CHECKER OF DOOM
[21:56] <dipponaught[away> yeah i did the dch -i but no avail... whats that?
[21:57] <Keybuk> I suggest reading through the kernel packaging knowledge base
[21:57] <dipponaught[away> and on the same note is there a debian/ubuntu prefered way of enabling the boot menu? (beside editing grub.conf or whatver)
[21:57] <dipponaught[away> ok will do
[21:58] <dipponaught[away> ugh. i assume ur referring to the wiki page of the kernelteam?
[21:59] <Keybuk> yes
[22:00] <dipponaught[away> ugh. tmi.
[22:06] <dipponaught[away> the wiki isnt really helping. no mention of debuild anywhere. the closest I can find is "submit patches to Linus"...
[22:06] <dipponaught[away> Iim pouring over FAQ right now)
[22:10] <dipponaught[away> ok, so does changing the debian/changelog change the version thats built?
[22:12] <dipponaught[away> heh, Bug #444683 : Document need for "-c debian.master/changelog" arguments to dch -i.
[22:12] <dipponaught[away> Keybuk: thanks
[22:30] <kirkland> cjwatson: hrm, ubuntu-server dailies seem to be missing
[22:31] <jdstrand> soren: I'm close to having the libvirt merge done
[22:31] <jdstrand> soren: fyi-- with a small change to the 9007* patch, I am able to get the test suite to work as well
[22:32] <soren> jdstrand: On the buildd's?
[22:32] <soren> jdstrand: The eventtest unit test only fails on the buildd's.
[22:32] <soren> Well..
[22:32] <soren> Only on systems with a kernel with a HZ=100 setting.
[22:34] <jdstrand> soren: I was just looking at that-- I didn't fix it
[22:34] <jdstrand> soren: I had a different failure cause daemon-conf dies if the unix socket is in too deep of a directory
[22:34] <soren> jdstrand: Yeah, don't worry about it.
[22:34] <soren> jdstrand: Oh.
[22:34] <soren> jdstrand: Sounds like fun.
[22:35] <jdstrand> soren: well, I worked around it in the test
[22:35] <soren> jdstrand: I'll take a stab at the eventtest thing tomorrow.
[22:35] <jdstrand> soren: I report the failure, but don't 'fail=1'
[22:35] <jdstrand> soren: I need to test the merge, which I hope to do today/first thing tomorrow
[22:36] <jdstrand> soren: you'll see it wasn't the most straightforward merge when you see the changelog ;)
[22:36] <cjwatson> kirkland: have you checked the logs?
[22:36] <jdstrand> soren: it took a bit of time
[22:36] <kirkland> cjwatson: nope ...
[22:36]  * kirkland does that now
[22:36] <cjwatson> kirkland:
[22:36] <cjwatson> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/lucid/
[22:36] <kirkland> cjwatson: thanks
[22:37] <cjwatson> Missing debootstrap-required nih-dbus-tool
[22:37] <cjwatson> Missing debootstrap-required ureadahead
[22:37] <cjwatson> which amounts to "priority: required and the seeds aren't in sync, pls fix"
[22:38] <cjwatson> two possible fixes depending on desired state
[22:41] <pitti> meh, who broke ubuntu-dev-tools -- NameError: name 'EDGE_SERVICE_ROOT' is not defined
[22:42] <cjwatson> kirkland: I'll look tomorrow if it's still breaking; too late for me now
[22:42] <kirkland> cjwatson: sure thing, no worries
[22:43] <kirkland> cjwatson: it's not urgent for me
[22:43] <kirkland> cjwatson: just making sure someone was aware
[22:44]  * soren calls it a day
[22:46]  * Daviey tends to be more accurate and call it a "Tuesday"
[22:52] <jdstrand> soren: fyi-- I'm going to add a patch to disable eventtest for now
[22:52] <jdstrand> soren: that will get it building and into the archive while you work on the proper fix
[22:52] <jdstrand> soren: I'll ping you when I upload the merge
[22:53] <jdstrand> soren: it's looking more like first thing tomorrow for me...
[22:57] <tjaalton> lifeless: you created la_AU, but upstream refused to include it. now our libx11 has some sort of support for it, and it's never going upstream (or debian). Shouldn't the patch be dropped from libx11 for lucid?
[22:58] <tjaalton> (upstream glibc refused it..)
[22:58] <lifeless> tjaalton: upstream are bigoted :)
[22:58] <lifeless> we carry other patches they reject
[22:58] <tjaalton> but our glibc doesn't have that either?
[23:00]  * slangasek creates a separate la_US translation team to put all the 'z's back where they belong and take out the extra 'u's
[23:00] <lifeless> ?
[23:01] <tjaalton> at least the changelog doesn't mention it
[23:01] <lifeless> tjaalton: try the locale, it works :)
[23:01] <lifeless> though the x11 support has glitched, I need to fix it.
[23:01] <tjaalton> so we are going to carry it forever?
[23:02] <lifeless> that was my understanding when pitti landed it. Its not the first such thing.
[23:02] <tjaalton> well it's one of the (very) few X libs that can't be synced as of now
[23:02] <lifeless> you could push it to debian, if thats what you mean.
[23:03] <tjaalton> they won't accept it
[23:03] <tjaalton> we discussed it briefly
[23:03] <lifeless> I'm on a call at the moment, I can't give you proper attention now, sorry.
[23:04] <tjaalton> ok, np
[23:04] <tjaalton> I should be in bed anyway..
[23:05] <slangasek> Keybuk: seen that pybootchartgui and bootchart aren't co-installable?  (pybootchartgui Provides: bootchart-java, bootchart Breaks: bootchart-java
[23:05] <slangasek> )
[23:05] <garrythefish> a bunch of lesbos banned me from #ubuntu-women. can't believe it
[23:06] <slangasek> garrythefish: I suggest you apologize for the preceding remark if you don't want to find yourself banned from here as well
[23:06] <garrythefish> eeh, what now?
[23:07] <slangasek> if you think it's appropriate to denigrate members of the Ubuntu community as "a bunch of lesbos", I have an inkling of why they would have banned you
[23:08] <ion> slangasek: It’s just a troll. Let’s not indulge it. :-)
[23:08] <garrythefish> your mother is a troll
[23:09] <slangasek> !ops garrythefish
[23:09] <garrythefish> ops?
[23:10] <slangasek> bot fail
[23:10] <garrythefish> what's that? a type of garlic?
[23:11] <slangasek> !ops | garrythefish
[23:11] <garrythefish> ion: your mom screwed your dad to death before your birth
[23:12] <garrythefish> hmm, i can confirm they are lesbos. want evidence?
[23:15] <kklimonda> it looks like the number of ops have decreased lately?
[23:16] <garrythefish> nope, its just a drinking holiday :P
[23:16] <slangasek> ion: labelling everyone who behaves poorly on IRC a troll is necessarily polarizing; I think it's far preferable to express expectations clearly on the off chance that the offender is capable of modes other than "antisocial idiot"
[23:17] <slangasek> garrythefish: no, because the sexual orientation of anyone who banned you is irrelevant to this discussion, and whether or not you happen to be correct, it's inappropriate for you to make it a point of discussion
[23:17] <garrythefish> is it?
[23:18] <garrythefish> if you show me that rule in written form, i'll be convinced
[23:19] <garrythefish> maybe its one of the reasons they behave like that
[23:20] <Pici> was afk, sorry
[23:20] <pitti> thanks Pici
[23:20] <sbeattie> Pici: thanks
[23:21] <porthose> Pici, ty :)
[23:21] <chrisccoulson> well, he was a pleasant character :-/
[23:24] <kirkland> so what's the secret in karmic to drop to the grub2 menu?  i thought it was holding ESC ....
[23:25] <slangasek> shift
[23:25] <kirkland> slangasek: thanks
[23:37]  * mneptok returns clad in the golden raiment in which he was born
[23:37] <mneptok> ugh. trollfest.
[23:39] <ajmitch> mneptok: yes, you missed it, though there wasn't really anything funny about it
[23:40] <chrisccoulson> and he's been visiting all the other channels now, leaving similarly vulgar comments
[23:40] <mneptok> ajmitch: i guess it's "funny" in the same way tumors are "funny"
[23:40] <ajmitch> pretty much
[23:41] <mneptok> *sigh*
[23:51] <Keybuk> slangasek: already fixed that
[23:53] <slangasek> Keybuk: ah, stuck on the buildd, ok