=== robbiew is now known as robbiew_ [00:03] james_w: ^ [00:10] lifeless: "which is better?" <- I'm not sure which choice you are referring to? [00:10] and yes, it knows how to sync] [00:11] ok, cool. === jelmer_ is now known as jelmer [00:29] james_w: can you make lp:~lifeless/debian/sid/python-testtools/debian lp:debian/python-testtools then ? === asac_ is now known as asac [01:31] Keybuk: hum, the latest bootchart assigns all the disk usage to init? :) [01:51] slangasek: yeah, something wrong there ;) [01:51] I suspect ureadahead isn't working properly [01:51] and in a very strange way [02:09] oh, I see what I've managed to do [02:09] *no* idea why init is spinning though [02:09] that's very strange [02:10] must be something ptracey [02:11] it's not disk usage [02:11] that bright red means something else [02:12] heh [02:12] bright red isn't a good color to see in relation to a hard drive [02:12] stopped/uninterruptable I think [02:12] nah, it's bootcharts way of trying to highlight a bad/dead process [02:12] the init job is failing because the process doesn't exist [02:13] oh, I was thinking the fail led's on some drive cages [02:13] but I guess isn't trapping out of ptrace properly === jtisme is now known as jtholmes [02:41] slangasek: I'm going to go find joey hess [02:42] and explain to him that "--" is not meant to be syntactically vital [02:42] who does he think he is?! [02:42] Tom Lord? [02:50] 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] what an interesting errno [02:50] \o/ [02:57] haha [02:57] usually means "where did I stash that errno, I'm sure I had it here somewhere" [02:57] most common mistake [02:57] if (! working) { [02:57] free (shit); [02:57] perror ("argh"); [02:57] } [02:57] since free can, of course, modify errno ;) [02:58] Keybuk: though nothing is supposed to set errno to zero. [02:58] other than the app, of course. [02:58] lamont: uhm, actually. [02:58] but hey, you know, that's just errno standards... [02:58] There is at least one syscall that does [02:59] * Keybuk can think of quite a few that do :p [02:59] lifeless: according to the manpage? [02:59] deviants! [02:59] mind you, I gave up on believing that bit of the spec some time ago [02:59] oh, thats right [02:59] readdir is what I was thinking of [03:00] and its just nasty [03:00] end of dir - return NULL and 'errno is not changed' [03:01] can also be [03:01] int saved_errno; [03:01] : [03:01] if (! working) { [03:01] return -1; [03:01] } [03:01] type thing where you forget to save the errno [03:14] slangasek: hi [03:14] lamont: did you comment on that kernel-img.conf bug? === nxvl_ is now known as nxvl [03:15] 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] 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] cool [03:16] meh [03:16] which bug again? [03:17] 470265 [03:20] slangasek: which file did you like? [03:20] lamont: IIRC I asked for you to send the contents of /var/log/installer, yes? [03:20] yeah [03:20] but that has lots of files [03:20] how much if any sensitiveish data is in there? [03:21] depends on how private you consider your partition layout tobe [03:22] /proc/cpuinfo: model name : QEMU Virtual CPU version 0.9.1 [03:22] lol wut? [03:22] debconf is smart enough not to leave any passwords there [03:23] so attach all said files to the bug? [03:23] well, a tarball will probably be less painful for all :) [03:25] for anyone that was interested in following along: http://www.shtylman.com/archives/154 [03:25] thar. posted^H^Hing [03:25] and yeah, tarball is less work all around [03:25] s/ing/ed/ [03:26] lamont: ta [03:26] lamont: thanks [03:26] (910.0 KiB, application/x-tar) [03:26] total win [03:30] StevenK: libapache2-mod-auth-pam is trying to sneak yada back into main ;) [03:35] slangasek: so the ~1build1 version of bind9 should get autosync'ed over with the non ~ version, right? [03:49] lamont: I think so, yes [03:51] hey everyone [03:52] i was wondering if you going to put the new squashfs 4.0 with lzma in your kernel [03:53] this may allow you guys to have more space [04:04] lamont: well, your broken /etc/kernel-img.conf is not the same as lifeless's [04:06] 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] slangasek: woot? :( [04:07] anyway, bed. [04:07] Is there a cleaner way to get the upstream version in debian/rules with dh 7 other than dpkg-parsechangelog? [04:07] lamont: add the hook lines to your file by hand, and be merry :) [04:07] 'night [04:09] slangasek: did that a few days back [04:09] ok :) [04:11] slangasek: libgnome. bug 77010 [04:11] Launchpad bug 77010 in alsa-lib "Overuse of system beep without volume control" [Medium,Confirmed] https://launchpad.net/bugs/77010 [04:13] 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] slangasek: do your mixer element strings match between 2.6.31 and 2.6.32? [04:15] (i.e., from 'amixer') [04:16] answering that question seems to require me to reboot, yah? [04:16] I'll trawl the commit, one sec. [04:17] nope, not kernel-side, no need to reboot [04:17] (the beep rework won't land until 2.6.33) [04:17] fwiw: [04:17] Simple mixer control 'Beep',0 [04:17] Capabilities: pvolume pvolume-joined pswitch pswitch-joined [04:17] Playback channels: Mono [04:17] Limits: Playback 0 - 15 [04:17] Mono: Playback 0 [0%] [-45.00dB] [off] [04:19] dtchen: should I file a new bug about this, and if so, on what package? [04:21] 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] dtchen: alert volume is maxed out; 'enable window and button sounds' is not checked. [04:22] slangasek: are you using metacity or compiz? [04:22] dtchen: I've also disabled the noises now by disabling the bell in the gnome-terminal config [04:22] metacity [04:23] slangasek: looks like pulseaudio, then. bug 301174 [04:23] Launchpad bug 301174 in pulseaudio "Use proper sound event instead of system beep" [Wishlist,Fix released] https://launchpad.net/bugs/301174 [04:24] you can try 'pactl unload-module module-x11-bell' [04:25] dtchen: no change in behavior [04:26] slangasek: err, I misread. That was for non-metacity, anyhow. [04:26] k [04:27] slangasek: well, I can't see anything at a first glance. The only other package I haven't checked is libcanberra. [04:28] slangasek: Bah! [04:28] "yada is moving, kill it!" [04:29] Only 14 reverse build-depends. [04:29] None that I care about either .... [04:34] 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] 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] it doesn't seem to involve any changes from linux upward through pulseaudio, however. [04:37] wah [04:38] StevenK: I'm surprised you haven't removed, burnt & blacklisted it from ever entering the archive [04:39] hmm, there's a thought [04:40] Three archive admins makes a quorum, right? [04:40] Haha [05:04] cjwatson_: hi - why is john in both supported-misc-servers and supported-sysadmin-common? [05:14] 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] hi. i'm noticing that pybootchartgui won't function without bootchart installed. [05:35] why does pybootchart now conflict with bootchart? [05:57] mathiaz: dunno, sorry === dendrobates is now known as dendro-afk [07:39] good morning [07:47] Good mornin [07:49] 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] and *now* all of germany has arrived [07:57] * fagan waves from Ireland === thekorn_ is now known as thekorn [08:09] * pitti dist-upgrades and gets a debconf question "Various snmp software needs extracted MIBs from RFCs and IANA" [08:10] oh, sure, those MIBs are said to be veery tasty! [08:23] mdke: thanks [08:28] I just want to point out [08:28] USE="python3" emerge portage [08:28] Gentoo uses Python 3 now [08:28] and compiles packages which support Py3 for both Py2 and Py3 at the same time === abms1116 is now known as abms1116|away [09:54] mathiaz`: john> I have no idea, try bzr blame or similar ... [09:55] mathiaz`: not everything on the server image is in server-ship, no; you have to follow the inheritances in the STRUCTURE file too === cjwatson_ is now known as cjwatson [10:00] what are the current plans for Py3 in Ubuntu? [10:01] 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] Arc: if you wait til its daytime in our tz, you may get an answer [10:11] py3 will certainly not be the default in 10.10 [10:11] it's available in the archive, though (for quite a while already) [10:13] 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] maco: But 2.6 and 3 are version numbers, not sovers :-P [10:17] StevenK: its 5am i dont know the difference === abms1116|away is now known as abms1116 [10:39] StevenK, in python terms, what's the difference? [10:40] they are nearly different languges. [10:40] something, - probably 80% - of packages haven't updated to support python 3 at all [10:40] lifeless: i think directhex is asking the diff between version and so-version in python [10:41] pitti, hi === tkamppeter_ is now known as tkamppeter [10:41] hi tkamppeter [10:42] maco, my point is, given it's not compiled, the target python version is the closest thing to soname versioning [10:42] directhex: fine by me. as i said, im too tired to figure out a difference [10:42] maco, have you considered this advanced device w/ a duvet & pillows on it? [10:43] yeah yeah im goin im goin [10:47] 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] pitti: I have already uploaded 3.9.10 to Lucid earlier and it built correctly. [10:48] tkamppeter: this seems to be quite an obvious error, tough [10:48] "though" [10:48] 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] apparently the debian/foo.manpages specifies a nonexisting file? [10:50] pitti, hp-devicesettings.1 is present. [10:50] tkamppeter: what does the .manpages file specify, and where is it present? [10:51] It simply says [10:51] hp-devicesettings.1 [10:51] in one of its lines. [10:51] It is debian/hplip-gui.manpages, by the way. [10:52] The man page is present in the root of the source tree. [10:52] It builds locally for me, but on the buildds it fails. [10:53] And it seems to build on Debian. [11:04] tkamppeter: so what does debian/hplip-gui.manpages specify for the manpage in question? what's the full line? [11:07] The full line is [11:07] hp-devicesettings.1 [11:08] Nothing more. [11:08] pitti: ^^ [11:09] tkamppeter: that seems to be correct then; try DH_VERBOSE=1 dh_installman -i to see what it does? [11:10] Locally it works: [11:10] DH_VERBOSE=1 dh_installman -i [11:10] install -p -m644 hp-devicesettings.1 debian/hplip-gui/usr/share/man/man1//hp-devicesettings.1 [11:10] ... [11:14] pitti, if I do rm -rf debian/hplip-gui/usr/share/man [11:14] and try again, the man pages also get successfully installed. dh_installman does [11:14] install -d debian/hplip-gui/usr/share/man/man1/ [11:15] to create the needed directory then. [11:15] 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] tkamppeter: so what happens if you don't remove the dir before? [11:19] pitti: do we need to split the patches in bug 488115 into seperate patches to get the SRU reviewed? [11:19] Launchpad bug 488115 in ruby "ruby garbage collector segfaults under certain conditions" [Undecided,In progress] https://launchpad.net/bugs/488115 [11:19] btm: the current patch is about 20 times bigger than it should be [11:20] pitti: hahaha. so yes then. [11:20] 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] but seriously, I strongly advise to not do such things in the first place [11:20] do some careful minimally invasive patches to just fix one or two bugs at a time, get them verified, and to -updates [11:21] with a patch like this, we can hardly ever say whether it breaks something [11:21] Is it possible that more recent versions of dh_installman do not create the directories any more? [11:21] tkamppeter: no [11:21] tkamppeter: as you see, it calls install -d, which creates the dirs [11:21] or at least it's astonishingly unlikely [11:22] Locally, I get the man pages successfully installed both with and without explicitly creating the directory. [11:22] tkamppeter: you have to reproduce the failing case with DH_VERBOSE, not a working case [11:22] and in any case that error message is not that the target directory doesn't exist [11:22] the error message says that the source file does not exist [11:22] pitti, then it seems I will have to load a Lucid pbuilder at first. [11:23] it literally just tried to open the file and it wasn't there [11:24] tkamppeter: it doesn't look very lucid specific to me, though [11:24] tkamppeter: is the manpage created during package build, or shipped in the orig.tar.gz? [11:28] cjwatson: As per the desktop-lucid-une spec, unr. is moving -- do you think it belongs in ubuntu., or shall I create netbook.? [11:29] pitti, the .orig.tar.gz seems to generate it. [11:29] tkamppeter: s/generate/contain/ ? [11:29] pitti, perhaps Lucid executes some stuff in another order [11:31] StevenK: I think netbook. is more suitable [11:31] pitti, they get generated by the install-stamp: rule in debian/rules. [11:32] tkamppeter: ah, then I suppose that the arch-independent packages are generated first, before the arch-dep install rule [11:33] The binary-indep: and binary-arch: rules run dh_installman [11:33] Can I make these two rules dependent on install-stamp: to force the needed order? [11:34] I think in general these rules should only get executed when the installation is completed. [11:34] at first sight this seems to make sense [11:36] pitti, it could even make sense to be this way by default. [11:36] "by default"? [11:37] StevenK: or maybe even ubuntu-netbook.? [11:37] Are these db_ helpers not generally supposed to be run after "make install"? [11:37] 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] 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] especially for targets that are specific to your debian/rules file [11:38] tkamppeter: some might well work before, but in general most of them make more sense after the install target, yet [11:38] even 'install' is not a required target, come to that [11:38] tkamppeter: but install-stamp is just a convention, not something that buildds even understand (or dpkg-buildpackage) [11:39] pitti, cjwatson, broken debian/rules from Debian maintainer which simply worked by accident for all the time ... [11:39] seems like it [11:41] 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] forcing the order is entirely correct and not a workaround at all [11:42] there's nothing intrinsically broken about a rules file written in that way, when the inter-target dependencies are correct [11:42] 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] pitti: uploaded new debdiff to bug 488115 that contains two small patches to fix segv bugs with corresponding lp bugs. [11:55] Launchpad bug 488115 in ruby "ruby garbage collector segfaults under certain conditions" [Undecided,In progress] https://launchpad.net/bugs/488115 [12:02] The following packages have unmet dependencies: [12:02] lightsoff: Depends: seed but it is not installable [12:02] 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] ogra: software center? [12:05] oh [12:05] ogra: only guessing [12:06] ogra: ubiquity too [12:06] oooh, right, the new slideshow stuff [12:06] thanks, i didnt think of that [12:07] interestingly ubiquity-frontend-gtk doesn't actually depend on python-webkit or anything ... [12:07] ev: is that an oversight? [12:08] nope [12:08] because ubiquity can function just fine without the slideshow === MacSlow is now known as MacSlow|lunch [12:10] hmm. just feels odd that there's no mention of it in the control file. Maybe a Suggests or something? [12:10] or even Recommends given that we want the slideshow in Ubuntu [12:11] the odd thing I think is that the slideshow essentially only works by accident because python-webkit is in desktop [12:11] which feels odd to me somehow, although I don't know the best fix [12:16] well, we could just add python-webkit to the seeds as well, but I'm equally fine with a Suggests or Recommends. [12:17] I just wanted to make it as easy as possible for derivatives that didn't want the slideshow === seb128_ is now known as seb128 [12:41] dear firefox. why is it that every morning when I get on my computer, your window is dead-n-gone _AGAIN_?? [12:41] no core file, no nothing. [12:43] I'd suggest the OOM killer, but it's somewhat suspcious it's always firefox [12:47] pitti: so running 'xbacklight -get' fails? works for me with the karmic versions [12:47] could somebody in the desktop team deal with MIRing 'seed', please? reasonably urgent since CD builds are failing due to this [12:48] pitti: of course -set works too [12:48] 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] tjaalton: right, that gives said error message [12:55] tkamppeter: ah, good [12:55] tjaalton: if it's generally supposed to work on intel, then I just blame the xorg-edgers packages :) [12:57] pitti: yep :) [12:57] 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] pitti: lightsoff and swell-foop === persia` is now known as persia === MacSlow|lunch is now known as MacSlow [13:48] w/w 20 [13:48] grr [13:56] is there a howto recompile packages the dpkg way? I know you start with apt-get source [package] [13:57] debuild [13:57] (in the directory that apt-get source creates) [13:57] see manual pages etc. for more details [13:57] thanks! [14:03] the debian administration guide for this thing tells an outright lie [14:04] "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] mdeslaur: you fixed the security issue of libgd2 in the stable version, but it is not fixed in lucid. [14:10] goldins: edit debian/rules [14:10] goldins: you *need* to edit the package, even if that isn't what you *want* to do :-) [14:11] cjwatson: I see! thanks again [14:16] 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] mdeslaur: thank for the info. === jamie is now known as Guest84682 [14:32] * ttx painfully tries to get a bzr branch from LP... it's... slow... today... === ogra__ is now known as ogra [15:02] pitti,sabdfl: TB meeting? [15:02] haven't seen Keybuk around [15:07] cjwatson: thanks, incoming [16:06] MacSlow, ping [16:06] h4writer, pong [16:06] hi MacSlow, it's about bug #489414, if you think it is easier to debug over chat, go ahead... [16:06] Launchpad bug 489414 in notify-osd "Wrong icon gets used" [Undecided,Incomplete] https://launchpad.net/bugs/489414 [16:10] h4writer, hm... maybe somehow your from-source installs messed up the system-wide icon-cache [16:11] So removing the cache would solve it? [16:13] h4writer, hm... awn installs (or used to install) icons in /usr/share/hicolor maybe those override everything else [16:14] MacSlow, I have no /usr/share/hicolor folder === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [16:14] h4writer, awn used to have a plugin replacing notification-daemon... maybe that's "getting in the way" [16:15] h4writer, but that would not explain why you still see notificatino-bubbles rendered by notify-osd [16:15] I have had notification-deamon, but I removed it [16:16] *had notification-deamon in jaunty, upgraded and removed it in karmic [16:16] h4writer, http://launchpadlibrarian.net/36182432/Schermafdruk.png clearly is rendered by notify-osd [16:16] MacSlow, yeah it is definitly notify-osd ;-) [16:17] h4writer, do you know malept or moonbeam in #awn? [16:17] yes [16:42] 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] 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] Arc: Debian and Ubuntu share a system for supporting multiple Python interpreters. [16:44] ScottK: and that is? [16:44] Currently a lot of stuff doesn't particularly work on Python 3, so we don't see a great rush. [16:45] is it not generally understood that developers use Ubuntu too? [16:46] Certainly. [16:46] That's why we ship python-3.1 [16:47] but do you, for example, ship cherrypy for py3? [16:47] or sqlalchemy, or even wsgi [16:47] Nope. [16:48] Arc: there is no stable release of sqlalchemy that supports python 3.x [16:48] Arc: and that's similar for most libraries and applications [16:48] I'd expect after Lucid there will be a lot more of a push to support Python 3. [16:49] kklimonda: im using sqlalchemy on py3 right now. [16:49] Arc: Then you're using a prerelease version [16:50] 0.6 isn't the stable release yet [16:50] so? it will be by the time my software is ready to release [16:50] developers need to target tomorrow, not today, or the entire community plays a continual game of catch-up [16:51] 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] 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] Arc: This channel is for development of Ubuntu, not complaing about it. I think you probably want #ubuntu-offtopic. [16:53] I was hoping that this may be useful feedback, but I guess it'll be ignored [16:54] 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] 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] he's left [16:55] ebroder: We have other, more pressing, problems in the Debian/Ubuntu Python stack. [16:55] Ah. Thanks. [16:56] I believe we have a general expectation of python3-* binary packages [16:56] and separate source packages if they need more than 2to3 [16:56] * ebroder nods [16:57] ScottK: btw, how can we (and by we I mean 'me') help with Python stack if you need more resources? [16:58] 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] kklimonda: I was more responding to his complaints about lack of development versions of libraries than Python specifically. === steveire_ is now known as steveire === luisbg is now known as luisbg_afk [17:31] cjwatson: hi - I'm looking at the ubuntu-server package set in lucid [17:31] cjwatson: libgtop2 is part of it - why? [17:32] cjwatson: seems to be gnome related [17:32] something depends or build-depends on it. check germinate output [17:32] cjwatson: and what's the difference between the ubuntu.lucid and platform.lucid seeds? [17:32] the package sets are unlikely to be tightly closed in the way you expect [17:33] platform.lucid is stuff that's shared between flavours [17:33] cjwatson: is the former only used for iso/image creation? [17:33] err - no? [17:33] cjwatson: ok [17:36] mathiaz: libapache2-mod-perl2 build-depends on libgtop2-dev [17:37] cjwatson: how did you find that information? [17:37] I grepped germinate output [17:37] cjwatson@rookery:/home/ubuntu-archive/public_html/germinate-output/ubuntu.lucid$ grep ^libgtop2 * [17:37] or you can run germinate yourself locally [17:38] cjwatson: great - thanks! [17:44] jdstrand: hi! [17:45] jdstrand: where is the list of server supported files for hardy? [17:46] mathiaz, moving lilo to universe might have implications for installer, and it's rdepends list tons of kernel packages [17:47] 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] superm1: if you have other concerns for lilo don't hesitate to add it to the wiki page [17:48] 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] I'm unsure about lilo [17:49] if we remove it from main, that will indeed basically take out that installer component as well, which is currently an option [17:49] that may be OK, we just need to be aware it's a pretty firm commitment! === ogasawara_ is now known as ogasawara === sconklin1 is now known as sconklin [18:04] mathiaz: hi! it has not been generated yet [18:06] mathiaz: ie we have this http://people.canonical.com/~ubuntu-security/dapper-lts-server-supported.txt, but not one for hardy yet [18:06] jdstrand: ok - has the list been generated by hand? [18:11] mathiaz: I think it is mostly automated. see seed-report in UCT [18:11] jdstrand: ok - thanks. [18:12] mvo_: howdy, around? [18:12] mvo_: i'm having a few issues merging/building eucalyptus for Lucid, looks like problems with librampart [18:12] mvo_: i noticed that you're the maintainer ;-) [18:14] mvo_: hmm, well, you're listed as the maintainer, but have no changelog entries; perhaps I'm mistaken :-) [18:16] mathiaz: the dapper supported list was reviewed by hand, yes. it required a lot of seed splitting [18:16] mathiaz: hardy will likely require the same attention. [18:16] (as will lucid, etc) [18:28] kirkland: I helped soren with rampart, but he took over then === deryck is now known as deryck[lunch] [18:32] mvo_: okay, thanks! [18:33] mvo_: i'm having a build issue with eucalyptus that I *think* I can solve with a symbol|shlib file in rampart [18:33] mvo_: i was looking for someone to confirm this with === RainCT_ is now known as RainCT === artir is now known as RainCT_ === RainCT_ is now known as artir === manny__ is now known as mannyv [18:52] james_w: Could I get an UDD nudge for missing import subversion 1.6.6dfsg-2 ? [18:55] maxb: file bugs: lp/udd [19:07]