[02:03] <Hew> Hey guys, is there a page somewhere that defines the usage of depends/recommends/suggests for a package? I have an idea of what they are for, but figured there should be a guideline/policy for it somewhere to define the grey areas.
[05:04] <ScottK> asac: I thought you were going to support the firefox package in Hardy?  I don't see the most recent security update for it?
[06:39] <mcasadevall__> and the internet here makes **** smell like roses
[07:20] <NCommander> any sponsors in the room?
[07:21] <NCommander> er
[07:21] <NCommander> wrong room
[08:01] <mouz> pitti: new grep fails to authenticate?
[09:00] <pitti> mouz: authenticate? how do you mean?
[09:03] <mouz> pitti sorry: the package could not be authenticated. when doing the upgrade.
[09:09] <mouz> pitty plz ignore :)
[09:12] <asac> ScottK: its on its way.
[09:33] <pitti> mouz: that sounds like a mirroring problem rather, not specific to grep
[09:39] <Keybuk> has anybody got a spare buildd I can borrow
[09:39] <Keybuk> (would like to find out what will break if I upload libtool 2.2 to the archive
[09:39] <pitti> o_O? don't we have enough?
[09:39] <Keybuk>  best way seems to be rebuild the archive with it)
[09:39] <Keybuk> uploading it to the _real_ archive and using the usual buildds seems to be the second best way
[09:40] <evand> Can someone else with access to ubuntu-devel run through the moderation queue today?  Broadcom decided I should no longer have access to the machine with my listadmin configuration.
[09:55] <tseliot> pitti: can you upload these packages to Intrepid, please? They only remove a useless file. http://albertomilone.com/ubuntu/newlrm/pitti/links.txt
[09:56] <pitti> tseliot: meeting, I'll do it later
[09:57] <tseliot> pitti: ok, thanks. And maybe you could also move these from hardy-proposed to hardy-updates: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-envy-2.6.24/+bug/246301
[09:58] <calc_> bdmurray: it looks like the graphs messed up last night or at least the OOo ones did
[09:58] <calc_> oops
[09:58] <calc> bdmurray: you do generate the graphs and bryce did the web interface (right?)
[09:59] <ion_> Nice, the new compcache patch might actually fix the bug i’ve been running into. http://code.google.com/p/compcache/wiki/Changelog
[09:59] <bdmurray> calc: that's correct
[10:00] <bdmurray> calc: that's really odd if you look at the csv file it shows low numbers but not zeros
[10:01] <calc> bdmurray: yea, i wonder why it reported incorrect numbers, instead of just not at all
[10:14] <cjwatson> evand: ubuntu-devel> partly done
[10:14] <evand> much appreciated
[10:23] <Wubbbi> Bug in Ubuntu Intrepid found: Synaptic Installs things sucsessfull but he dont close. It is installed but after it was installed he freezed up :(
[10:36] <slangasek> jelmer: hrm, why am I having to pull a source package in order to be able to review bzr-cvsps-import, instead of checking out a bzr branch? ;)
[11:58] <pitti> tseliot: your upload list doesn't have -173, is that already correct?
[11:59] <pitti> tseliot: rest uploaded
[11:59] <pochu> pitti: hi, could you remove emesene from the hardy-proposed unapproved queue? I uploaded it with a wrong version number
[12:00] <pitti> pochu: done
[12:00] <pochu> thank you
[12:01] <tseliot> ﻿pitti: yes, 173 was not affected by the "problem"
[12:01] <tseliot> ﻿pitti: thanks for the upload ;)
[12:02] <tseliot> ﻿pitti: did you move the drivers from -proposed to updates too?
[12:02] <pitti> tseliot: just at it
[12:03] <tseliot> ﻿pitti: super! :-)
[12:24] <ScottK> asac: Thanks.
[12:25] <asac> ScottK: i guess it will go out today. we just have to wait for security team to wake up ;)
[12:25] <ScottK> Understand.  I just wanted to make sure it wasn't missed.
[12:26] <asac> sure. thanks. feel free to remind me ;)
[13:06]  * Hobbsee ntoes that nm on intrepid seems to have spontaneously fixed itself.  \o/
[13:08] <slangasek> Riddell: kubuntu desktop image sizes haven't come down because kdeplasma-addons is uninstallable, causing the livefs build to fail
[13:09] <Wubbbi> slangasek: Please report it here #kubuntu-devel
[13:09] <slangasek> Wubbbi: erm, I don't intend to join a separate channel to let Riddell know about livefs build problems, sorry
[13:10] <Wubbbi> slangasek: ohhh ... ok sorry ^^ i have read wrong ^^
[13:10] <slangasek> ok :)
[13:10] <Riddell> slangasek: ah hah
[13:11] <Riddell> slangasek: coincidently that's actually the next think on my todo list for looking at
[13:11] <slangasek> ok :)
[13:11] <ion_> benc: Judging from the changelog, the new compcache patch probably fixes the system hang i’ve been running into. http://code.google.com/p/compcache/wiki/Changelog
[13:11] <slangasek> hmm I'm repeating myself
[13:23]  * pitti discovers gdmflexiserver --monte-carlo-pi and wonders how much other useless crack we ship on CDs by default
[13:28] <slangasek> wtf
[13:28] <Robot101> its not even very good at calculating pi :P
[13:28] <slangasek> why is that in there?
[13:28] <slangasek> yeah, that's an awful long time to get the first 5 digits right
[13:28] <pitti> slangasek: for the same reason as Alt+F2 "free the fish" is
[13:30] <cody-somerville> What does --monte-carlo-pi do?
[13:30] <Mithrandir> calculate pi.
[13:30] <Mithrandir> slowly.
[13:30] <cody-somerville> Atleast the gnome folks are consistent.
[13:36] <Wubbbi> bug 249850
[13:36] <mvo> hello Wubbbi
[13:36] <mvo> Wubbbi: could you please attach the output of pstree -a to the bugrpeort?
[13:40] <Wubbbi> mvo: done :)
[13:41] <Wubbbi> mvo: and brause is because ... I have a stupid keyborad ^^
[13:41] <pitti> daemon/slave.c:static gboolean gdm_can_i_assume_root_role (struct passwd *pwent);
[13:41]  * pitti thinks it would be better to stop poking in gdm code soon...
[13:42] <mvo> Wubbbi: hm, the pstree output does not list synatpic currently, is it no longer available when the freeze happens?
[13:43] <Wubbbi> mvo: yes. I can select my KDE Desktop withput problems. Just Synaptic is frozen and I cant use it anymore. I have to kill it :(
[13:44] <Wubbbi> but to packages are installed without problems
[13:44] <mvo> Wubbbi: ok, the pstree output does not contain synaptic, could you please run it (pstree) before you kill synaptic so that I can see what processes are running when it hangs?
[13:44] <mvo> Wubbbi: could you also please open a terminal window (e.g. konsole) and run "sudo synaptic" and see if that shows the hang then too? or if it only happens if you run it via the menu (by the means of gksu)?
[13:47] <Wubbbi> mvo: ok wait ^^
[13:49] <Wubbbi> mvo: I dont know why but now it works without freez up! O.o ... sorry xD
[13:49] <Wubbbi> Very Strange
[13:50] <mvo> Wubbbi: so it does work with sudo in a terminal but it does not when you run it from the menus?
[13:50] <Wubbbi> wait let me test
[13:50] <mvo> Wubbbi: please add this information to the bugreport, that is pretty useful
[13:51] <Wubbbi> mvo: ok it just work with terminal :/
[13:51] <MacSlow> seb128, looks like I've just to add a minor patch to clutter-gtk... so it should be pretty easy and fast
[13:51] <Wubbbi> at these momtent Synaptic is freezed up.
[13:51] <MacSlow> seb128, but first I need to test it with my test-case and the drawingcode from gdm
[13:51] <seb128> MacSlow: no problem, let me know when there is a package to upload
[13:51] <Wubbbi> you need any informations?
[13:52] <mvo> Wubbbi: please add this information to the bugreport, when it freeze and (if/when) it does not freeze
[13:52] <Wubbbi> mvo: done
[13:54] <Wubbbi> mvo: can i kill synaptic or do you need any information while it's frozen?
[13:55] <mvo> Wubbbi: the pstree output would be good (if you haven't added that already while it is frozen). other than that, it hsould be fine for now, but I may come back later
[13:55] <mvo> Wubbbi: and ask for more infomation (depends on if I can reproduce it or not)
[13:57] <Wubbbi> mvo: ok ... the pstree doesn't change. See you :)
[13:57] <calc> where are the 8.04 release notes?
[13:58] <slangasek> the editable ones, or the published ones?
[13:58] <calc> ah i found them with the search :)
[13:58] <calc> the published one, i found it via search
[13:58] <calc> it appears not to be linked very well
[13:59]  * calc had to reference it to close a bug :)
[14:04] <slangasek> they're linked from the installer, and I think from the release announcement mail-
[14:04] <slangasek> mails
[14:08] <jelmer> slangasek: OpenChange should work better for you now - it was missing a dependency on doxygen
[14:08] <slangasek> hmm
[14:08] <slangasek> and adding that build-dep fixed it?
[14:08] <slangasek> if so, you're missing something in your clean target, because I saw a doxygen error earlier, installed it, and tried a rebuild - got the error
[14:16] <jelmer> slangasek: ah, I should of course be running distclean
[14:16] <slangasek> aha :)
[14:16] <jelmer> should be fixed now
[14:23] <ion_> benc: Did you get my message? :-)
[14:25] <liw> is there a tool for corrupting a filesystem (so that one may test fsck)?
[14:26] <ion_> liw: dd if=/dev/zero of=/dev/sda1 :-)
[14:26] <BenC> ion_: yes, have you confirmed it?
[14:27] <BenC> liw: disconnect the driver during a copy of a lot of files
[14:27] <BenC> s/driver/drive/
[14:27] <pitti> liw: ext3?
[14:27] <liw> pitti, ext3, yeah
[14:27] <pitti> liw: tune2fs -s 0 /dev/bla; tune2ds -s 1 /dev/bla
[14:27] <ion_> benc: Sorry, no. The crash just seems to match with the changelog description perfectly: a backtrace is dumped from notify_swap_entry_free and the system hangs.
[14:27] <pitti> liw: that won't actually break anything, but forces an fsck
[14:28] <liw> pitti, I'm actually looking for somethign to break things so that fsck finds errors, but that will get me started
[14:28] <pitti> liw: then just do -s0, fsck will complain a lot
[14:28] <pitti> but be warned, that might really fuck up your fs
[14:29] <pitti> so don't do it on a partition which you still need
[14:29] <ln-> i think the freenode channel guidelines forbid the use of the word "fuck".
[14:29] <pitti> *cough*; /me edits history to say "screw"
[14:29] <BenC> ion_: are you sure that the compcache patch doesn't cause the problem?
[14:30] <BenC> ion_: notify_swap_entry_free() doesn't exist unless you patch in compcache
[14:31] <ion_> benc: http://heh.fi/tmp/compcache-crash-log
[14:31] <liw> pitti, I'm running this against an fs in a file, so no worries about screwing up the system :)
[14:31] <ion_> benc: There’s a new compcache patch. From its changelog: “Fixed incorrect BUG() in notify_swap_entry_free() callback”
[14:31] <liw> oh, wow, e2fsprogs not only has an LSM file, it has an up-to-date LSM file
[14:31] <BenC> ion_: ah, I was thinking you meant the patch in our kernel
[14:32] <BenC> ion_: I'll check the patch, thanks
[14:32] <ion_> benc: The one currently in the Ubuntu kernel causes the crash.
[14:32] <ion_> benc: Thanks
[14:33] <ion_> The new patch: http://compcache.googlecode.com/files/patch_compcache_with_notify_support_2.6.26.diff
[14:38] <\sh> pitti: would you like to take a look at bug 246911 or should I just upload the changed bits to intrepid?
[14:39] <pitti> \sh: if it's sane, just upload it
[14:39] <\sh> pitti: well, it's much ;)
[14:40] <\sh> pitti: but will do it this evening..so I can request a backport to make me happy on hardy and my army of flash media servers
[14:54] <BenC> ion_: committed
[15:12] <ion_> benc: Thanks!
[15:19] <asac> norsetto: any reason why gecko-mplayer wont work with 1.0~rc?
[15:19] <asac> the depends appear to be too  high for debian
[15:19] <norsetto> asac: thats what upstream recommends
[15:19] <asac> if you say its ok to use >= 1.0~
[15:19] <asac> then i will just bump and upload now
[15:19] <asac> norsetto: yeah. but 1.0 is not available in sid here
[15:19] <asac> so not installable ;)
[15:20] <norsetto> asac: I see
[15:20] <norsetto> asac: can we wait few hours, I can ask upstream to make sure, or if you want to test it, I can only test in a sid chroot?
[15:20] <asac> norsetto: i guess i can just bump it
[15:20] <asac> norsetto: yes. please test in a sid chroot
[15:21] <asac> my chroot is at home and doing that through internet is not really going to go ;)
[15:21] <asac> if it starts and works somehow its good enough
[15:23] <norsetto> asac: hmm, perhaps you should have said that in a query ;-)
[15:23] <asac> norsetto: no ;)
[15:23] <asac> thats fine ;)
[15:24] <asac> norsetto: ok i dumped the revision and took the responsibility by adding a comment in changelog for that under a [Alexander Sack] banner
[15:24] <asac> norsetto: let me know if thats ok with you ;)
[15:25] <asac> norsetto: http://paste.ubuntu.com/28285/
[15:25] <norsetto> asac: no need to do that, just bump it and don't mention it in the changelog, if there are problems I'll take care of that
[15:25] <asac> ok
[15:26] <norsetto> asac: its my fault, I should have checked the deps in sid to be sure
[15:26] <asac> norsetto: no problem
[15:29] <seb128_> jcastro: https://bugs.edge.launchpad.net/bugs/bugtrackers/gnome-bugs/%s
[15:59] <seb128_> soren: hey, is virtualbox known to be broken in intrepid?
[15:59] <seb128_> virtmanager rather
[16:00] <soren> seb128_: There appear to be some issues w.r.t. installing new vm's from it, yes.
[16:00] <seb128_> soren: clicking on the "choosing installation method" next button doesn't do anything
[16:01] <soren> Ok.. that might be a side effect of the same bug.
[16:01] <seb128_> any workaround?
[16:01] <soren> So yeah, it's known, but I don't have a fix for it right now. Sorry.
[16:01] <seb128_> would downgrading something to the hardy version workaround the issue?
[16:02] <soren> Try installing python-virtinst from Hardy.
[16:02] <soren> If my hypthosis is correct, that's the actual culprit.
[16:05] <seb128_> soren: do I need to restart something after installing that?
[16:05] <soren> seb128_: virt-manager.
[16:06] <seb128_> no change
[16:06] <seb128_> do I need to be in the kvm group?
[16:06] <cjwatson> Riddell: I think oem-config and ubiquity might need to be updated in similar ways to casper - could you check please?
[16:06] <cjwatson> Riddell: at least for the autologin stuff
[16:06] <soren> seb128_: Depends on what you're trying to do.
[16:06] <seb128_> I'm trying to boot an iso
[16:06] <soren> seb128_: It certainly can't hurt :)
[16:06] <Riddell> cjwatson: ok
[16:07] <soren> seb128_: You need it if you're interacting with qemu:///session rather than qemu:///system.
[16:07] <soren> seb128_: You need membership of libvirtd to interact with qemu:///system.
[16:07] <seb128_> yes
[16:07] <seb128_> and virt-manager was working fine in hardy
[16:07] <soren> Perhaps this it the right time to upgrade my laptop to intrepid. :/
[16:08] <seb128_> I did upgrade on monday
[16:08] <soren> seb128_: Oh, right. Well, if it worked in hardy on the same machine, then you should not need additional memberships or anything.
[16:08] <seb128_> things are mostly working
[16:08] <seb128_> that's what I though
[16:08] <soren> My workstation at home has been running intrepid since it opened. I just kept the laptop on hardy to be able to reproduce KVM bugs.
[16:10] <pitti> kvm hates me in intrepid, too, feels like a pot of tar; it takes half a week to start the desktop CD...
[16:10] <seb128_> pitti: eventually it starts for you ;-)
[16:11] <liw> intrepid under hardy kvm fails to boot for me, though
[16:11] <seb128_> mine just refuse to go to the next wizard stage and let me choose an iso
[16:11] <cjwatson> intrepid-in-intrepid WFM
[16:11] <cjwatson> except that there's no mouse cursor in the booted image
[16:11] <cjwatson> (except for very briefly as the desktop is coming up)
[16:15] <seb128_> soren: "kvm -m 512 -cdrom iso" is working
[16:16] <soren> Right. It's totally a virt-manager and/or virt-install problem.
[16:16] <soren> liw: intrepid under hardy needs "no-kvmclock" on the kernel command line.
[16:17] <soren> intrepid under intrepid needs a kernel based on 2.6.26 final (which I believe is what the current kernel packages are).
[16:17] <liw> soren, cool, I'll try that when I get back home
[16:20] <paran> There is a fixed kvm in hardy-proposed that can boot intrepid without any kernel parameters. However for me it then fails to start Xorg
[16:25] <mathiaz> slangasek: still working on the slapd upgrade code - I'm trying to figure out how to support systems that don't want to migrate to slapd.d
[16:26] <mathiaz> slangasek: I'm going through the functions in scripts-common. What should they return when slapd.conf is used ? 0 or 1 ?
[16:26] <mathiaz> slangasek: I think they shouldn't fail if slapd.conf is used
[16:29] <seb128_> soren: do you know how I can switch to a vt in a kvm box?
[16:29] <slangasek> mathiaz: why do we want to give them the option not to migrate? :)
[16:29] <seb128_> ctrl-alt-f1 switches on the real box
[16:30] <slangasek> mathiaz: if they don't migrate, then *none* of the other package integration work we're trying to lay on top of this will function, and we'll have to continually special-case those systems
[16:30] <slangasek> mathiaz: for a use-case that upstream says is going away within a few revisions anyway
[16:30] <mathiaz> slangasek: there are some modules currently that don't support slapd.conf
[16:30] <TheMuso> seb128_: Are you using virt-viewer?
[16:30] <mathiaz> slangasek: *slapd.d*
[16:30] <soren> seb128_: Depends on your client.
[16:30] <seb128_> TheMuso: no, I'm using kvm, virt-manager doesn't work
[16:31] <soren> seb128_: Some clients have a dropdown with "interesting" keypresses you can send.
[16:31] <slangasek> mathiaz: but from the conversations at UDS, my understanding was that we would either fix or drop those for intrepid
[16:31] <seb128_> soren: using "kvm -m 512 -cdrom iso"
[16:31] <slangasek> well, upstream would fix them or we would drop them
[16:31] <slangasek> ;)
[16:31] <mathiaz> slangasek: hm. So we'd force user to upgrade to slapd.d/
[16:31] <slangasek> mathiaz: I don't remember precisely which modules were affected, but I thought they weren't critical ones?
[16:31] <mathiaz> slangasek: if they don't want, they cannot upgrade.
[16:31] <mathiaz> slangasek: there probably not critical
[16:32] <mathiaz> slangasek: they're probably not critical
[16:32] <slangasek> mathiaz: I think it would be fine to detect use of those modules in preinst and abort the upgrade
[16:32] <mathiaz> slangasek: ok - the same way as ldbm was handled
[16:32] <slangasek> (mvo might disagree, but this is server stuff, so pff :)
[16:32] <slangasek> right
[16:33] <mathiaz> slangasek: ok - so that supplifies the logic
[16:44] <Zorocke> Hey peoples, i am looking to contribute a bit to the open source world.
[16:44] <Zorocke> i have some C++ programming expeirence.
[16:44] <Zorocke> experience*
[16:45] <soren> seb128_: Sorry about the long response times here... )
[16:46] <soren> seb128_: You can do ctrl-alt-2 to get to the monitor.
[16:46] <seb128_> soren: no problem, I guess I'll not get virt-manager working today anyway
[16:46] <soren> seb128_: in the monitor, you type: sendkey ctrl-alt-f2
[16:46] <soren> seb128_: That'll send ctrl-alt-f2 to the guest.
[16:46] <seb128_> ah ok, good to know
[16:46] <seb128_> thanks
[16:46] <soren> seb128_: and then you do ctrl-alt-1 to get back to the actual guest.
[16:46] <soren> seb128_: Any time :)
[16:47] <geser> seb128_: is a comment in a sync request enough to get a package moved from multiverse -> universe or do you/the archive admins want a seperate bug for it?
[16:47] <seb128_> geser: better to have a different bug
[16:48] <geser> seb128_: ok, will file one then
[16:49] <seb128_> geser: I usually just check that the sync has been acked to sync something, better to have other requests in an another bug, not sure about other archive admins though
[16:56] <slangasek> jelmer: openchange packages now build here correctly in a pristine env, cheers
[17:02] <slangasek> pitti: do we still have both versions of sqlite in main for intrepid, or have we managed to trim the one that was only needed for upgrades?
[17:03] <pitti> slangasek: still four sources using sqlite: bacula, cyrus-sasl2, php5, qt4-x11
[17:03] <slangasek> and sqlite is the old one?
[17:03] <pitti> qt is just bindings I suppose which we could probably disable
[17:03] <slangasek> yes, it appears to be
[17:04] <slangasek> php5 is bindings; I failed to manage that transition on the Debian side in a timely manner, and now I don't care about php anymore
[17:09] <Riddell> cjwatson: hopefully CIA just told you I commited the kdm change to ubiquity and oem-config
[17:14] <mdz> mvo: hmm, dist-upgrade won't upgrade ubuntu-desktop at the moment
[17:14] <mdz> needs to remove gnome2-user-guide and scrollkeeper, install rarian-compat
[17:15] <pitti> cjwatson already tried to demote scrollkeeper to extra and promote rarian-compat to optional, but that didn't help
[17:15] <pitti> apt- doesn't want to upgrade, but apt-get install rarian-compat works
[17:15] <mdz> pitti: 2 packages > 1
[17:16] <mdz> we don't need scrollkeeper anymore?
[17:16] <seb128_> rarian-compat conflicts, provides, replaces scrollkeeper, not sure why apt doesn't like it
[17:16] <mdz> oh
[17:16] <pitti> it's replaced by rarian-compat
[17:16] <pitti> I had the same problem with cups, though
[17:16] <mdz> seb128_: what's wrong with gnome2-user-guide?
[17:16] <seb128_> mdz: looking, I'm not aware of any issue on this one
[17:16] <pitti> it wouldn't auto-replace/upgrade with only one reverse dependency, but with several it did
[17:16] <mdz> seb128_: ah, versioned depends on scrollkeeper
[17:16]  * thom dances briefly on scrollkeeper's grave
[17:16] <pitti> so I ended up doing an empty transitional package
[17:16] <mdz> seb128_: change that to rarian and that should make apt happy
[17:16] <seb128_> mdz: where? I thought I fixed those
[17:16] <mvo> mdz: hm, should be fine for release-upgrades, the meta-packages get a explicit upgrade call if they are not upgraded as part of dist-upgrade
[17:16] <mdz> mizar:[~] apt-cache show gnome2-user-guide | grep Dep
[17:16] <mdz> Depends: scrollkeeper (>= 0.3.14-5)
[17:17] <pitti> we could just remove scrollkeeper from the archive and let rarian-compat build an empty transitional scrollkeeper?
[17:17] <mdz> mvo: I'm just dist-upgrading within intrepid
[17:17] <seb128_> mdz: oh, gnome2-user-guide is an old thing
[17:17] <pitti> hm, if that works, it would be nice as well
[17:17] <seb128_> mdz: it has been renamed gnome-user-guide some time ago
[17:17] <pitti> mdz: does it actually compare for ">1" or "packages depending on scrollkeeper" > "packages depending on rarian"?
[17:17] <mdz> seb128_: heh, it's from edgy
[17:17] <slangasek> renamed but without an upgrade path
[17:17] <slangasek> (no transitional package)
[17:17] <mdz> I wonder why the  release upgrader didn't remove it
[17:18] <seb128_> iz mvo bog
[17:18] <mdz> pitti: sort of the latter, but not exactly
[17:20] <seb128_> should we change the depends to rarian-compat | scrollkeeper rather than scrollkeeper | rarian-compat during the cycle when touching those sources?
[17:21] <mvo> mdz: I suspect that the release upgrader back in edgy did something wrong and later it was no longer be able to figure out if the gnome2-user-guide package was a manual (explicit) install or a left-over
[17:22] <mdz> seb128_: why not just change to rarian-compat and drop scrollkeeper?
[17:22] <seb128_> that works too
[17:22] <seb128_> I was just curious to know if inverting the order would make apt happier
[17:22] <mdz>   Considering scrollkeeper 39 as a solution to rarian-compat 22
[17:22] <mdz>   Holding Back rarian-compat rather than change scrollkeeper
[17:23] <mdz> it likes scrollkeeper 77% more than rarian-compat
[17:23] <seb128_> we should just use aptitude
[17:23] <mdz> you need to tell it that you love rarian-compat
[17:23] <slangasek> depending only on rarian-compat would seem to make the relationships more rigid (-> fragile), no?
[17:23] <seb128_> it's smarter about those things usually ;-)
[17:23] <mdz> seb128_: troll :-)
[17:23] <mdz> haha
[17:24] <mdz> mizar:[~] sudo aptitude upgrade
[17:24] <mdz> [...]
[17:24] <mdz> The following packages have been kept back:
[17:24] <mdz>   ubuntu-desktop
[17:24] <mdz> The following packages will be REMOVED:
[17:24] <mdz>   gnome-bin{u} gnome-libs-data{u} libart2{u} libdns42{u} libelfg0{u}
[17:24] <mdz> (16 packages removed)
[17:24] <mvo> it is smarter ;)
[17:24] <slangasek> seb128_: this must be some definition of "usually" meaning "at one point in the distant past", right? :)
[17:24] <mvo> that gnome stuff is not needed anyway
[17:24] <seb128_> yeah, that's GNOME 1
[17:24] <realist> I actually lol'ed just now.
[17:24]  * seb128_ wonders how much old crap are installed on mdz's box
[17:25] <mdz> seb128_: it removes 16 packages but still doesn't upgrade ubuntu-desktop :-P
[17:25] <slangasek> we should all get images of mdz's box to use for upgrade testing
[17:25] <mvo> !
[17:25] <mvo> that is a excellent idea :)
[17:25] <Keybuk> mdz: I blame the previous maintainer
[17:25]  * ion_ uses debfoster to get rid of the old crap. And ams-run debfoster to synchronize its idea of which packages are installed manually and which automatically to apt and aptitude. :-)
[17:26] <ion_> It would be neat if aptitude had debfoster-like functionality.
[17:26] <mdz> ion_: it does, and so does apt
[17:26] <mdz> The following packages were automatically installed and are no longer required:
[17:26] <mdz>   openoffice.org-filter-binfilter libdns42 libelfg0 render-dev xmms
[17:27] <ion_> No. aptitude considers all packages it doesn’t specifically know about manually installed. debfoster asks about them and only keeps the ones the user specifically chooses to keep manually installed.
[17:27] <mdz> sounds like a lot of questions
[17:28] <mvo> ion_: a long time ago aptitude did it the other way around and people got confused when half of their system got removed suddenly :)
[17:28] <ion_> Not really *that* many, since it only asks about the ones on the top (or bottom, whichever way you think of it) of the dependency tree.
[17:28] <mdz> why is libelfg0 still in main?
[17:28] <seb128_> because the archive admins are slackers? ;-)
[17:28]  * mdz glares at bug-buddy
[17:28] <liw> I use a custom meta package (or set of them, actually) to keep track of which packages I am specifically interested in; apt/aptitude mark all manuall istalled packages as "wanted", which is not what I want, when I just briefly try a new program
[17:28] <ion_> And i don’t want that functionality to be aptitude’s default. I want it to be something you can optionally launch from a menu.
[17:28] <mdz> seb128_: the bug-buddy maintainer is a slacker, apparently
[17:28] <seb128_> mdz: I did this change!
[17:28] <seb128_> doh, didn't upload
[17:28]  * seb128_ uploads now
[17:29]  * pitti demotes in the meantime
[17:29] <pitti> seb128_: no more build depends for you :)
[17:29] <Keybuk> pitti: could you demote dselect while you're in there?
[17:29] <mdz> clearly you guys discovered that there's beer in the fridge
[17:30] <jcastro> beer?
[17:30] <LaserJock> lol
[17:30] <ion_> There is, but nothing any good.
[17:30] <slangasek> jcastro: you can't have any, you're too young
[17:30] <seb128_> jcastro: do you have an highlight on beer? ;-)
[17:30] <jcastro> oh, shucks
[17:30] <elmo> apart from keybuk being a horrific troll, what's the rationale for demoting dselect?
[17:30] <slangasek> it takes up space and we don't use it? ;)
[17:31] <Keybuk> elmo: we do not, by any stretch of the imagination, support it
[17:31] <seb128_> elmo: nobody is maintaining it actively
[17:31] <ion_> What, dselect still exists? ;-)
[17:31] <Keybuk> any bug starting with "I used dselect to" is met by laughter and scorn
[17:31] <pitti> it will just cause yet another instance of main/universe skew, but *shrug*
[17:31]  * seb128_ got beer, thanks mdz
[17:31] <slangasek> it's been largely superseded by dpoll
[17:31] <elmo> slangasek: I use it
[17:32] <mdz> elmo: it's unmaintained upstream?
[17:32] <elmo> Keybuk: I've yet to see such laughter and scron
[17:32] <Keybuk> elmo: we do it behind your back :)
[17:32]  * pitti still uses dselect
[17:32] <ion_> :-)
[17:32] <seb128_> pitti: troll!
[17:32] <slangasek> elmo: so you want your dpkg front-end of choice to be one maintained by mrvn?
[17:32] <elmo> mdz: it wasn't any more unmaintained than dpkg, last I looked?
[17:32] <seb128_> let's move dpkg to universe then ;-)
[17:32] <seb128_> maybe we can use rpm
[17:33] <mdz> elmo: it gets built, but no one is fixing its bugs
[17:33] <pitti> packagekit!!!
[17:33] <Keybuk> when I took over dpkg, we decided to stop maintaining dselect
[17:33] <mdz> seb128_: I hear rpm packaging is easier anyway
[17:33]  * slangasek moves pitti to universe
[17:33] <Keybuk> well, actually, Colin said he would ... and then he ran away
[17:33] <mdz> seb128_: and it's already in main
[17:33] <seb128_> see ;-)
[17:33] <ion_> No, no, no. Ebuilds.
[17:33] <Keybuk> dmerge!
[17:33] <seb128_> mvo: want to maintain rpm for us?
[17:34] <elmo> slangasek: if I thought he was actually going to do anything, I might be vaguely concerned
[17:34] <mdz> seb128_: we can use autopackage, then upstreams will do the packaging for us
[17:34] <stgraber> why is rpm in main btw ? only for file-roller ? :)
[17:34]  * liw votes for replacing dpkg with bzr
[17:35] <slangasek> stgraber: lsb, perhaps
[17:35] <Keybuk> elmo: are you going to start fixing the open bugs against dselect?
[17:35] <seb128_> file-roller doesn't depends on rpm
[17:35] <elmo> however much certain members of the distro team might hate it, dselect works and works well for me.  "it's not being actively worked on" could be said of a lot of software in main, as long as it's bugs are not actively causing problems, I don't think that's necessarily a problem
[17:35] <mvo> seb128_: rpm++
[17:35] <slangasek> bzr -BORGiE
[17:35] <stgraber> slangasek: ah, right lsb.
[17:36] <elmo> Keybuk: so, if 'fix bugs or it gets demoted' is the attitude, I have several bugs against other packages in main I could point you to?
[17:36] <liw> wouldn't life be so much simpler if we delivered Ubuntu as a bzr branch, which contains a full installed system (anyone wanting to select which software they have installed could just go to Gentoo)
[17:37] <thom> slangasek: the dpoll pun was terrible, btw. (since no-one else seems to have abused you for that)
[17:37] <Keybuk> elmo: if nobody was even looking at the bugs, I would certainly not like to ship that software
[17:37] <LaserJock> gosh, that would be fun to branch :/
[17:37] <james_w> liw: if only you were able to put VM images in bzr
[17:37] <elmo> Keybuk: oh please
[17:37] <slangasek> thom: thanks :-)
[17:37] <stgraber> liw: you could you multiple bzr branch and use unionfs to have different "packages" installed :)
[17:37] <stgraber> *you could have
[17:39]  * LaserJock sticks each of stgraber's limbs in a bzr branch and tries to unionfs them
[17:39] <liw> otoh, we could convert each .deb into a bzr branch, put them into /bzr/$packagename, then have a script that symlinks from /bin and /usr/bin etc to /bzr/$packagename... yeah, this is a good idea, can I do that for intrepid?
[17:39] <slangasek> liw: python kernel first
[17:39] <Keybuk> liw: why not take the opportunity to switch to /System, /Libraries, /Programs and /Users? :-)
[17:40] <liw> Keybuk, I was thinking of writing a kernel module that does gettext on pathnames so that we can have those names properly localised for the user, based on $LANG
[17:40] <Keybuk> fuse-as-root!
[17:40] <ion_> Let’s switch to C:\Ubuntu\System32, C:\Program Files etc.
[17:41] <liw> slangasek, oh yeah, that old thing, I really should finish it, shouldn't I? let's see, I got as far as saying "mkdir linux.py && cd linux.py && bzr init"... so it's almost done
[17:43] <seb128_> ogra: rather here, are you sure you can't lock a gnome-panel position?
[17:44] <slangasek> liw: yes, all you need is a memory manager and I/O, and the Internet will write all the drivers for you quickly enough
[17:44] <ogra> seb128_, i only found a global key
[17:45] <liw> slangasek, Python already manages my memory for me, and I have a novel, revolutionary idea for doing I/O, based on the fact that pidgeons can make enough noise to emulate an acoustic modem
[17:45] <ogra> but that also disables right click and all options of applets ... as well as adding/removing applets indeed
[17:45] <seb128_> ogra: /apps/panel/toplevels/top_panel_screen0/orientation?
[17:45] <ogra> thats lockable ?
[17:45]  * ogra checks
[17:45] <seb128_> ogra: wouldn't setting a mandatory key work there?
[17:46] <Keybuk> what's worrying is that I briefly wondered whether you _could_ write a kernel in Python
[17:46] <seb128_> ogra: well, gconf has a mandatory key concept, sysadmins can force a key value over the user
[17:46] <Keybuk> and then realised that Emacs already has one in lisp ...
[17:46] <seb128_> ogra: not sure how much the code would like that though
[17:46] <ogra> seb128_, hmm, i have never used that out of a gconf defaults file
[17:46] <elmo> so, out of 70 bugs open in Launchpad for dpkg, 2 are related to dselect, AFAICT
[17:47] <tseliot> ﻿Keybuk: a kernel in Python wouldn't have to be (re)compiled. Yay!
[17:47] <Keybuk> tseliot: and you get pdb for free ;)
[17:48] <ogra> seb128_, is there any magic to do it from /usr/share/gconf/defaults ?
[17:48] <liw> I am now planning to use bsddb for storing the process list
[17:48] <seb128_> ogra: no
[17:48] <ogra> hmm
[17:48] <seb128_> that's an administrator thing usually
[17:48] <Keybuk> elmo: at least 15,000 bugs can be blamed directly on dselect's existance
[17:48]  * liw stops trolling and lets the channel return to being useful
[17:48] <seb128_> ogra: http://library.gnome.org/admin/system-admin-guide/stable/gconf-7.html.en
[17:48] <ogra> right, thats what i thought
[17:48] <ogra> merci !
[17:48] <Keybuk> removing it from existence would make the universe a better place, and instantly fix them
[17:48] <elmo> one of which is a UTF-8 bug with a patch, being actively tracked in Debian
[17:49] <elmo> the other is likely a duplicate of the same bug/issue
[17:49] <ogra> seb128_, hrm, that requires gconfd to be running :/ tricky ...
[17:50] <seb128_> ogra: gconf is autospawned when you call gconftool
[17:50] <ogra> right, but i dont know if it likes that in a chroot :)
[17:50] <ogra> i'll fiddle with it
[17:50] <seb128_> otherwise doing a code patch should not be too hard
[17:50] <seb128_> to lock a panel position
[17:51] <ogra> seb128_, well, i dotn reallly want to maintain another package in a separate repo
[17:51] <ogra> the kernel already gives me a lot of headdache
[17:51] <seb128_> ogra: well, we could sru this
[17:51] <ogra> (i'm forced to hardy)
[17:52] <ogra> hmm, does that qualify for SRU ... its actually a new feature
[17:52] <cody-somerville> \o_
[17:52] <seb128_> ogra: well, if the patch is easy enough and required
[17:52] <ogra> but that would indeed be the best way to go
[17:52] <ogra> i assume lexington would like to use it too, they have similar screen constraints everywhere
[17:53] <seb128_> will talk with vuntz about that
[17:53] <seb128_> but that's not going to be today
[17:54] <seb128_> brb
[17:55] <stgraber> ogra: IIRC you can use gconftool without having gconfd running, it directly changes the xml file then
[17:55] <stgraber> ogra: I use that to disable suspend and similar things when generating a fat client chroot
[17:55] <ogra> stgraber, ah, that would be cool
[17:55] <ogra> i will try that
[17:56] <stgraber> gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --set --type bool /apps/gnome-power-manager/general/can_hibernate false
[18:19] <ogra> seb128, btw, if we could SRU a fix for bug 247501 that would be very good, i know the guys here areound have a fix that adds another tab and moves elements over, and i'll take a look at that the next days how intrusive that is
[18:21] <seb128> ogra: UI changes are usually not an option for sru
[18:21] <ogra> ah, k
[18:31] <ogra> seb128, hmm, setting the mandatory key results in a big warning on first boot after install about "the admin has locked this setting, it will be set as a readonly setting to your defaults"
[18:32] <seb128> not good
[18:32] <ogra> no
[18:32] <ogra> hmm
[18:35] <ogra> beyond that it works as intended though
[18:59] <ogra> seb128, ah, the default panel setup touches the same value as well, if i drop it there the message is gone
[19:00] <seb128> drop what?
[19:01] <ogra> the reference to the orientation key for the toplevel panel
[19:03] <ogra> seb128, http://paste.ubuntu.com/28321/
[19:03] <ogra> that avoids the msg
[19:05] <mkrufky>  Is Steve Langasek in here?
[19:05] <crimsun_> yes, slangasek.
[19:05] <mkrufky> slangasek: ping
[19:05] <mkrufky> crimsun_: thanks
[19:05] <slangasek> 'morning
[19:06] <mkrufky> hi... i'm the contact for anything hvr950q or sms1xxx related
[19:06] <slangasek> I noticed :-)
[19:06] <mkrufky> slangasek: you just touched a bunch of bugs saying "verification needed"
[19:06] <mkrufky> i mailed out samples to canonical
[19:06] <mkrufky> and i have tested all those patches BEFORE i merged them upstream and then backported into LUM
[19:06] <mkrufky> what else should I do ?
[19:07] <seb128> ogra: ah ok, workaround for your installation maybe then but we should still look at a clean solution
[19:07] <ogra> yeah
[19:09] <slangasek> mkrufky: it's not necessarily required that you do anything personally here; we do need in-the-wild verification that the new packages don't regress anything (which is unlikely since these are entirely new drivers), and our SRU QA processes will address that.  It's ideal to also have in-the-wild verification that the packages, as uploaded, actually work on the intended hardware - again, not necessarily something that you have to do pers
[19:09] <slangasek> hmm, do I have splitlines turned on
[19:09] <mkrufky> slangasek: that'll be rough, since that hardware itself is not "in the wild"
[19:09] <liw> slangasek, your line ended "have to do per"
[19:09] <slangasek> ... personally, but given that I don't know where  within Canonical that hardware is, it might not be a bad idea
[19:10] <mkrufky> slangasek: this is all for belmont, and we decided to not *only* add support for belmont.  we want users to be able to use their sticks on their OTHER ubuntu machines too
[19:10] <slangasek> liw: so evidently, I do not have splitlines turned on ;)
[19:11] <mkrufky> slangasek: ...and I have a very limited supply of samples.  it's possible that the canonical allocations went to {the customer} before getting to canonical ... that i dont know.
[19:12] <slangasek> mkrufky: er, I wouldn't have any idea, frankly
[19:12] <cjwatson> mkrufky: just as a general policy, *all* SRU bugs require verification of some kind; I wouldn't recommend tilting at this windmill because previous attempts to bypass it have resulted in Things Going Horribly Wrong, but the exact nature of the verification is open to negotiation
[19:12] <mkrufky> dont get me wrong -- i dont want to be an exception to any rule
[19:12] <slangasek> I don't even know what Belmont is, other than having now seen via SRUs who some of the people involved are :)
[19:12] <mkrufky> all i want is to know what is expected of me
[19:12] <cjwatson> mkrufky: "verification needed" is not necessarily directed at you personally; it is also a directive to the Canonical QA team that they need to verify this bug
[19:13] <mkrufky> ok, good to know.
[19:13] <mkrufky> im not sure that any of them have the hardware..... unless mario_limonciell counts :-)
[19:14] <cjwatson> if Canonical has the hardware, our QA team should be able to get access one way or another
[19:14] <slangasek> well, anyone who has the hardware should please check that the binary packages actually work as intended
[19:14] <mkrufky> pmcgowan has the hardware
[19:17] <mkrufky> ok, cool... thanks for explaining
[19:27] <ogra> seb128, gah, i missed that there was still a gconfd runing, removing it didnt actually fix it, so i'll wait for the real fix and keep it completely locked until thats there
[19:27] <seb128> ok
[20:31] <norsetto> asac: I have spoken with upstream about the gnome-mplayer problem, I'm trying to convince him to not have gmo created by his make dist. In any case, I have a patch available that solves this. What is the best way forward?
[21:13] <jdstrand> no-- added to my todo list
[21:52] <Awsoonn> for the clock it 8.10 it gives a list of locations that can be added to the applet, where does it get the list from?
[21:52] <Awsoonn> 8.10 and 8.04 accually
[21:56] <norsetto> Awsoonn: check the source code
[21:56] <Awsoonn> :)
[22:08] <mario_limonciell> mkrufky, you still here?
[22:09] <mario_limonciell> it's the -20 kernel that will be getting the hvr950q support right?
[22:09] <mkrufky> mario_limonciell: hi
[22:09] <mkrufky> mario_limonciell: huh?
[22:10] <mario_limonciell> do you know what kernel to test with?
[22:10] <mario_limonciell> 2.6.24-20?
[22:10] <mkrufky> do I know what kernel to test with?
[22:10] <mario_limonciell> well i thought there was an SRU out there for hardy
[22:10] <mkrufky> oh!
[22:10] <mario_limonciell> that will be showing up in one of the proposed kernels
[22:10] <mkrufky> im sorry
[22:10] <mario_limonciell> and needed someone to ack it
[22:10] <mkrufky> yes
[22:10] <mkrufky> yeah, they need it "validated"
[22:11] <mkrufky> bugs # 241745 , bug # 241628
[22:11] <mario_limonciell> bug 261628
[22:11] <mario_limonciell> hum where's ubottu ?
[22:11] <mario_limonciell> bug 241628
[22:11] <mkrufky> thats what i wanna  know
[22:12] <mario_limonciell> bug 241745
[22:12] <mkrufky> yay
[22:12] <mario_limonciell> ah both in lum
[22:12] <mkrufky> i cant say i understand... at all
[22:12] <mario_limonciell> they are both in linux-ubuntu-modules 2.6.24
[22:12] <mkrufky> what i know is that they were merged into the git trees weeks agho
[22:12] <mkrufky> ago
[22:12] <mkrufky> so slangasek totally confused me today
[22:13] <mario_limonciell> well once the binaries show up on hardy-proposed i'll be able to test the first one at least
[22:13] <mario_limonciell> the second one is dvb only right?
[22:13] <mkrufky> i sent the dvbt ones to pat
[22:13] <mario_limonciell> yeah so let pat ack thouse
[22:13] <mario_limonciell> *those
[22:13] <mkrufky> actually, i think pat has 'em all
[22:13] <mkrufky> er....  can you confirm that?
[22:13] <mario_limonciell> no i'm not sure
[22:13] <mkrufky> there's a chance those went to compal, now i realize :-/
[22:13] <mario_limonciell> well my mirror is usually a day behind
[22:14] <mario_limonciell> so i'll test early next week
[22:14] <mkrufky> i mean the hardware
[22:14] <mkrufky> if i get dvb-t sticks over to you, do you have a generator?
[22:14] <mario_limonciell> yeah i'm not sure who has what at this point
[22:14] <mario_limonciell> i don't have one personally no
[22:14] <mkrufky> there's a chance that nobody at ubuntu / canonical actually  has them.  the guy that knows (here) isnt here today, and away from email
[22:15] <mario_limonciell> okay well can sort it out early next week
[22:15] <mario_limonciell> no rush on these, since the hardware isn't even "out in the wild" yet
[22:15] <mkrufky> actually...
[22:15] <mario_limonciell> shhhhhhhh ;)
[22:15] <mkrufky> we're thinking two different things, for sure
[22:16] <mkrufky> all i know is this -- we sent dvb-t sticks, but probably not to you guys yet
[22:16] <mkrufky> and i would like to send them out right now, if you can give me an address
[22:16] <mkrufky> (*if* you have a dvbt generator to test with)
[22:16] <mario_limonciell> jim has one
[22:16] <mario_limonciell> so sending 1 wouldn't hurt
[22:16] <mkrufky> a stick, or a generator?
[22:16] <mario_limonciell> stick
[22:17] <mario_limonciell> jim has a generator
[22:17] <mkrufky> oops, i was thinking of you with the other hat on
[22:17] <mkrufky> jim didnt ask for one, i dont think he needs one
[22:17] <mkrufky> he only wants plastics, afaik
[22:17] <mario_limonciell> oh okay
[22:18] <mkrufky> i need somebody that can ack to get a stick :-)
[22:18] <mario_limonciell> ah okay
[22:18] <mario_limonciell> well you should be able to ack yourself too
[22:18] <mario_limonciell> i mean just install the newer kernel on a  box
[22:18] <mkrufky> slangasek said no
[22:18] <mario_limonciell> i don't see why not?  I mean as long as you are testing the binaries in hardy-proposed
[22:18] <mkrufky> this is going to get worse.....  because i was planning on backporting drivers for tons of totally unreleased products to you ghuys
[22:19] <mkrufky> and nobody but me will *ever* be able to test them
[22:19] <mkrufky> the idea was to get drivers out there *before* the hardware is available
[22:19] <mkrufky> so that it will *actually* JustWork
[22:19] <stgraber> that should be fine, if you ack the driver works with your hardware and some other ack that the new lum doesn't break the world I don't see where the problem would be
[22:20] <mkrufky> hmm, ok
[22:20] <mario_limonciell> yeah the important part is testing that the binary worked
[22:20] <mkrufky> all i can do is pull down a git tree :-/
[22:20] <mario_limonciell> that you aren't running off your own source built tree
[22:20] <mario_limonciell> so once this newer lum hits hardy-proposed, install it, and check.
[22:20] <stgraber> what we don't want are regressions so having people saying that we don't have regressions and you saying that it works better should be fine to move the package to -updates
[22:21] <mkrufky> so, when will the binary be availeble?
[22:22] <mkrufky> ...and how do i install it without totally destroying my own build environment :-P
[22:22] <mkrufky> eh, scratch that last question
[22:22] <mario_limonciell> well it's in hardy-proposed as of 4 hours ago
[22:22] <mkrufky> ah!
[22:22] <mario_limonciell> but its marked NEW
[22:22] <mkrufky> how do i get it?
[22:22] <stgraber> you can get it from Launchpad
[22:22] <mario_limonciell> so that means that an archive admin would need to "ack" it to get the binaries the "normal" way
[22:22] <mario_limonciell> https://edge.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/2.6.24.14-20.46
[22:23] <mario_limonciell> click your architecture, and then there should be a list of resulting binaries
[22:23] <stgraber> as it's a new kernel (-20) you'll also need to download all the other kernel packages
[22:23] <mario_limonciell> oops thats the lrm
[22:23] <mkrufky> i can install that on a "2.6.24-19-generic" kernel ?
[22:23] <mario_limonciell> lum is what you need
[22:23] <mario_limonciell> let me find that
[22:23] <mario_limonciell> you might also need lrm though anyway if you have stuff in there like ati or nvidia
[22:24] <mario_limonciell> here's LUM https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/2.6.24-20.29
[22:24] <mkrufky> :-(
[22:24] <mario_limonciell> and here's the matching kernel image: https://edge.launchpad.net/ubuntu/+source/linux/2.6.24-20.37
[22:25] <mario_limonciell> so if you install the set of those 3 together, you should have a system that you can boot into the newer kernel and test.  if that's too much mess, then early next week an archive admin will clear these into hardy-proposed
[22:26] <mario_limonciell> at which point you can follow the directions on slangasek's comment to turn on proposed and install from there
[22:26]  * mkrufky digging up a hewlet crappard to test this on
[22:27] <mkrufky> sorry, my humor sucks right now
[22:34] <mkrufky> gonna be a few minutes... doing a dist-upgrade first before installing the above new packages
[22:37] <laga> mkrufky: do you need people who can test DVB-T hardware?
[22:37] <mkrufky> *I* dont...
[22:37] <mkrufky> i have a generatorm, here
[22:37] <mkrufky> generator
[22:38] <laga> nice. i saw one of these a few years back at an exposition and wanted to take it ;)
[22:38] <mkrufky> dvb-t generator?
[22:38] <mkrufky> i want one for home...  i can stop coming to the office, then :-P
[22:40] <mario_limonciell> mkrufky, how pricey are they? i think it'd be really neat to have one at home too
[22:42] <mkrufky> i just asked them in the lab
[22:42] <mkrufky> ... it ranges in price, depending on features, etc
[22:42] <mkrufky> brb
[22:44] <mkrufky> sorry, had a visitor
[22:44] <mkrufky> anyway....  ranges from 1500 to 15000
[22:45] <mario_limonciell> oh yikes okay
[22:45] <mkrufky> probably a $1500 one would be fine for home
[22:45] <mario_limonciell> novelty value wears off quick though at 1500 i think
[22:45] <mkrufky> meanwhile.... i hear the "management" talking from time to time about some generator on ebay for $100
[22:45] <mkrufky> when they see those, they buy 'em
[22:45] <mkrufky> hopefully, next time *I* will see one before they do
[22:46] <mkrufky> for a few hundred bucks, i'd totally buy one
[22:46] <mkrufky> heh, he didnt like the price, so he ditched
[22:51] <slangasek> mkrufky: sorry, I certainly didn't mean to give the impression that you weren't /allowed/ to ack
[22:53] <mkrufky> ah, then i misunderstood slangasek
[22:53] <mkrufky> slangasek: when we spoke earlier, i had no idea that i was able to test / ack it myself
[22:54] <mkrufky> meanwhile, apt says there are 42 minutes left in this download.... unlikely i'll stick around long enough
[23:01] <slangasek> mkrufky: right - the question that I remember you asking me earlier was what you /needed/ to do on the bug
[23:01] <slangasek> if you are /willing/ to test that the packages work, so much the better. :)
[23:06] <mkrufky> slangasek: ah, lol
[23:06] <mkrufky> magically 42 minutes have turned to zero -- yay
[23:11] <mkrufky> i am surfing thru those links and i dont see a deb to download
[23:11] <slangasek> which links?
[23:12] <mkrufky> (5:24:05 PM) mario_limonciell: here's LUM https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/2.6.24-20.29
[23:12] <mkrufky> (5:24:41 PM) mario_limonciell: and here's the matching kernel image: https://edge.launchpad.net/ubuntu/+source/linux/2.6.24-20.37
[23:12] <slangasek> pick an architecture
[23:12] <mkrufky> did
[23:12] <slangasek> then you'll get a list of binaries on the right side
[23:12] <mkrufky> nope
[23:12] <mkrufky> https://edge.launchpad.net/ubuntu/hardy/+package/linux-image-2.6.24-20-generic
[23:13] <mkrufky> oops
[23:13]  * mkrufky shuts up now
[23:13] <mkrufky> downloading.......
[23:13] <slangasek> in the case of the linux package, though, those are published in hardy-proposed already
[23:13] <slangasek> (they have to be, in order for lum to build against them)
[23:13] <mkrufky> i dont even know how to get hardy-proposed
[23:14] <slangasek> the (autogenerated) comment at the end of the bug should point to a page that explains it
[23:14] <mkrufky> i just download the deb
[23:15] <mkrufky> i'll go with that, if i have a choice
[23:15] <mkrufky> (i have to leave here in 10 minutes, wanna get this done as fast as i can)
[23:15] <slangasek> fwiw, it's not urgent; we hold these packages in -proposed for a full 7 days, to get regression-testing from a range of users
[23:16] <mkrufky> meh
[23:16] <mkrufky> https://edge.launchpad.net/ubuntu/hardy/i386/linux-ubuntu-modules-2.6.24-20-386/2.6.24-20.29
[23:16] <mkrufky> ok then... i guess i'll just let the 7 days happen
[23:17] <slangasek> between linux and linux-ubuntu-modules there are some 30 bugfixes, so that gives some opportunity for regressions
[23:17] <slangasek> mkrufky: mm, the validation needs to happen /while/ it's in -proposed
[23:17] <mkrufky> ?
[23:18] <slangasek> that's a condition of it being copied to -updates
[23:18] <mkrufky> i dont understand... but...
[23:18] <slangasek> so "let the 7 days happen" - if no one else verifies this bugfix for us, it becomes more than 7 days
[23:18] <mkrufky> ugh
[23:18] <mkrufky> i dont know what to say
[23:19] <mkrufky> i'm going back to upstream
[23:19] <mkrufky> whatever gets merged gets merged
[23:19] <mkrufky> heh
[23:19] <mkrufky> thanks for explaining slangasek
[23:20] <mkrufky> slangasek: have a good weekend
[23:20] <slangasek> mkrufky: sorry for causing frustration
[23:20] <slangasek> you too... :)
[23:20] <mkrufky> slangasek: its ok -- i think somebody just assumes that i know the policies, and i dont :-/
[23:21] <mkrufky> all that _really_ matters is that belmont has these changesets
[23:21] <mkrufky> belmont *does* have them, so its fine
[23:21] <slangasek> well, https://wiki.ubuntu.com/StableReleaseUpdates is the policy
[23:21] <mkrufky> after all deadlines come and go, then i will revisit hardy mainstream
[23:21] <mkrufky> hopefully this will all be done by then.... if not, then.... oh well
[23:21] <slangasek> which you're welcome to acquaint yourself with, but again, I don't know that this is anything that you /have/ to take responsibility for directly
[23:22] <mkrufky> i want to become more active in ubuntu kernel devel
[23:22] <mkrufky> so yes, i would like to become more acquainted
[23:22] <mkrufky> ...just now is the end of my week....  no more "retail" work for me... back to upstream kernel hacking ... otherwise there wont be any new code to backport into LUM / Intrepid ;-)
[23:22] <slangasek> ok; if you have questions about policies, here or #ubuntu-motu are good places to ask
[23:23] <mkrufky> cool, thanks
[23:23] <slangasek> heh, enjoy :)
[23:23] <mkrufky> you too ;-)
[23:23] <mkrufky> does laga work for canonical?
[23:24] <mkrufky> laga, if you work for canonical, please email me and i'll have a stick sent to you
[23:24]  * mkrufky goes home
[23:24] <mkrufky> goodnight,. all