[12:02] <jvw> most people will understand/see, I guess (language errors, IP in the US, hotmail address, ...), but certainly some won't
[12:03] <azeem> that would just give the impression you can get him to comment on things if you troll/fake enough
[12:03] <jvw> nvm the actual content of course
[12:05] <jvw> azeem: hrmz, yeah, well, that's true too. Anyway, Mark is prefectly capable of dealing with this himself, so, well.
[12:06] <Kamion> if you want him to see it, you'd need to e-mail him about it
[12:06] <Kamion> but I imagine having, well, just about anyone reasonably well-known in Debian/Ubuntu follow up saying "this wasn't Mark, please don't feed the troll" would do fine
[12:08] <LaserJock> jvw: what email is this?
[12:09] <sto> LaserJock: http://lists.debian.org/debian-devel/2006/03/msg00894.html
[12:10] <Kamion> errors> also, er, people generally spell their own names right
[12:11] <sivang> Kamion: http://muse.19inch.net/~sivan/culmus/breezy-updates/
[12:12] <Kamion> sivang: it's difficult for me to review it until it actually lands in the queue
[12:12] <Kamion> sivang: but get somebody to upload it and I'll happily do so
[12:12] <Kamion> you should keep the changelog entry from the previous upload
[12:13] <Kamion> have -2ubuntu2 describe the delta from -2ubuntu1 to -2ubuntu2, and upload with -v0.101-2 so that both changelog entries are visible in the .changes file (and thus on breezy-changes)
[12:13] <Kamion> s/upload/build/
[12:15] <Kamion> troll posting> followed up with a hopefully-preemptive don't-feed-the-troll
[12:16] <sivang> Kamion: -v is passed to dput or debuild?
[12:17] <sivang> ah, debuild
[12:18] <Kamion> yes, although your sponsor will have to do that too
[12:18] <Kamion> assuming they don't just sign your source package verbatim, which they shouldn't
[12:19] <sivang> I'll prepare a detailed email for pitti on that together with metnionting to him the -vVER thingy, but tomorrow. getting too much close to bed time here. thanks for the tips, I'll make sure this won't get rejected this time :)
[12:21] <Lathiat> do we still need to fakesync stuff from debian?
[12:34] <Kamion> Lathiat: yes, syncs aren't working yet
[12:34] <Lathiat> Kamion: cheers
[12:36] <elkbuntu> is there any reason why apt-get and update-manager are not getting quite the same stuff?
[12:58] <Amaranth> mjg59: btw, it appears my problem is bug 31543
[12:58] <Ubugtu> Malone bug 31543 in xserver-xgl "Xgl not working on ppc" [Normal,Confirmed]  http://launchpad.net/bugs/31543
[01:02] <mjg59> amOk
[01:02] <mjg59> Nngh.
[01:02] <mjg59> jdub: Ping?
[01:04] <mjg59> jdub: What's the situation on new usplash artwork?
[01:23] <Amaranth> mjg59: the invalid read errors in my xorg log (seem to be related to this) are supposedly fixed in suse
[01:57] <joelbryan> The Ubuntu Welcome Page is using XHTML Transitional, just wondering if you would plan to make it strict?
[02:00] <Burgwork> joelbryan, welcome page? ubuntu.com ?
[02:01] <joelbryan> no
[02:01] <joelbryan> the one that loads when you start firefox
[02:02] <Burgwork> joelbryan, ah, you need to talk to someone in #ubuntu-doc
[02:03] <joelbryan> ok
[03:11] <setuid> I've pulled the kernel source package, and I'm trying to build ibm_acpi with some patches... how do I do this? (normally I'd do 'make modules SUBDIRS=drivers/acpi', but that doesn't work with Ubuntu kernel source packages)
[04:43] <jdub> infinity: did we get that Xorg update?
[04:44] <jdub> oh, i guess it's not quite so critical for us, as our Xorg is not suid
[04:46] <infinity> Which update?
[04:46] <jdub> infinity: http://blogs.sun.com/roller/page/alanc?entry=security_hole_in_xorg_6
[04:46] <infinity> And is ours really not suid?
[04:46] <infinity> Hrm.  Doesn't seem to be in dapper...
[04:47] <infinity> I wonder if startx even works in dapper, then.
[04:47] <jdub> it wouldn't, no
[04:47] <Lathiat> no, it doesnt
[04:47] <jdub> but that is good :-)
[04:47] <Lathiat> i noticed that
[04:47] <Lathiat> which is bad..
[04:47] <jdub> (it could tell you why, though)
[04:47] <infinity> Surely we're suid root in warty/hoary/breezy...
[04:47] <jdub> i think it was fixed for breezy
[04:48] <infinity> The lack of suid in dapper is a packaging error, I'm sure, not a conscious decision.
[04:48] <jdub> though i don't have any breezy boxes anymore
[04:48] <jdub> ask pitti. he is fierce. :-)
[04:52] <infinity> Oh, nice bug.
[04:54] <nictuku> who cares about parenthesis anyway
[04:56] <Lathiat> so you see, ruby wouldn't have this problem, parenthesis optional :)
[04:56] <Lathiat> they should rewrite Xorg in ruby
[04:58] <LaserJock> :/
[05:04] <predius_> same
[05:04] <predius_> err
[05:04] <predius_> wrong
[05:05] <maswan> jdub: I have a +s X, but not Xorg, on my upgraded-to-breezy laptop, FYI
[05:09] <infinity> Oh, duh.  It's +s on dapper, too, I was looking at the wrong binary.  Thanks maswan. :)
[05:09] <infinity> (/usr/bin/X being a wrapper around /usr/bin/Xorg)
[05:09] <infinity> In which case, startx should work on dapper... At least, it should work on my machine..
[05:11] <nictuku> then the bug is an issue
[05:11] <fabbione> hmmmm
[05:11] <fabbione> infinity: should i take care of that X security hole?
[05:11] <fabbione> well THAT.. there are probably one per line..
[05:12] <fabbione> but at least that one..
[05:13] <infinity> You going to upload for all 4 dists?
[05:13] <fabbione> hmmmm
[05:13] <fabbione> let's wait pitti
[05:13] <infinity> I was about to start on it, but if you want to be the X man today. :)
[05:13] <fabbione> no no
[05:13] <fabbione> i will keep going on dapper bug list
[05:13] <fabbione> i want to get down to 160/150 today
[05:14] <na7e> hi fabbione and infinity
[05:14] <infinity> Okay, you keep attacking dapper, I'm happy to do the security updates.
[05:14] <fabbione> infinity: ok
[05:14] <infinity> Go lamont!
[05:15] <fabbione> LOL
[05:15] <fabbione> infinity: speaking of -security.. what about vivies?
[05:15] <infinity> vivies and I need to sit down and have a chat about security soon, yes.
[05:15] <fabbione> infinity: we could just get g-p-m fixed and get LiveCD out
[05:16] <infinity> And we'll chat about livecds too.
[05:16] <fabbione> good idea :)
[05:16] <infinity> Neither is much effort, I'm just hunting desperately for tuits of the correct shape and size.
[05:16] <infinity> SCC tuits!
[05:17] <nictuku> probably about a consert of something
[05:17] <infinity> Oh, neat, the advisory claims 6.8.2 and earlier don't have the bug.
[05:17] <jdub> infinity: oh, suck
[05:18] <fabbione> hmm
[05:18] <jdub> (re: X vs. Xorg)
[05:18] <fabbione> new xorg-server version or just the fix?
[05:18] <infinity> The fix is two characters.
[05:18] <fabbione> infinity: yeah i know that
[05:19] <infinity> Oh, 4 characters, it's in two parts of the code. :)
[05:19] <fabbione> infinity: i am considering 1.0.2 or just the patch..
[05:19] <fabbione> it's a hard choise
[05:19] <infinity> 1.0.2 may make up ABI incompatible with some drivers, if we're really unlucky.
[05:19] <infinity> (which would make a great excuse to update all the drivers!)
[05:29] <fabbione> going for 1.0.2 is totally harmless
[05:30] <fabbione> there are 2/3 bug fixes.. one of which is the security and the other one is the sparc i already did in 1.0.1
[05:30] <infinity> Alright, then that'd be the way to go.
[05:30] <fabbione> yea me too
[05:30] <infinity> And don't forget to mention the CVE in the changelog.
[05:30] <infinity> Or pitti will hurt you. :)
[05:30] <fabbione> i know
[05:30] <fabbione> nah
[05:30] <_ion> hunger: I couldn't repeat the interfaces bug you reported.
[05:31] <fabbione> infinity: i am going to upload 1.0.1 for now and prepare 1.0.2 for Kamion and mdz..
[05:31] <fabbione> infinity: it's a no brain anyway
[05:31] <_ion> hunger: n-m seems to parse interfaces correcty, and i didn't get a d-bus error when i tried many combinations for eth0 settings (with auto, without auto, dhcp, static).
[05:38] <infinity> fabbione: Okay, panic averted, the bug definitely only exists in dapper.
[05:41] <ajmitch> great, grub hates me now - looks like the install was not a success
[05:42] <fabbione> infinity: ehheeh ok.. i have already fixed dapper.. and i have 1.0.2 almost ready
[05:54] <fabbione> mdz: you still around?
[06:22] <mdz> fabbione: barely
[06:22] <infinity> If you're still in London, you really shouldn't be..
[06:22] <fabbione> mdz: ok nothing urgent.. it can wait when you are back
[06:22] <infinity> (shouldn't be around, that is)
[06:23] <mdz> I'm not; I'm at home
[06:23] <fabbione> mdz: otherwise it would be nice to have an UVF exception for xorg-server
[06:23] <infinity> mdz: Oh, phew.
[06:23] <fabbione> mdz: the only diff from our code and upstream is one bug fix (3 lines)
[06:23] <fabbione> mdz: but it will allow us to drop 5 local patches
[06:23] <fabbione> mdz: that are of course upstream..
[06:23] <mdz> fabbione: sounds fine
[06:24] <fabbione> mdz: ok.. i will upload after finishing the tests..
[06:24] <fabbione> mdz: thanks
[06:24] <mdz> fabbione: how is the bug list for X?
[06:25] <fabbione> mdz: yesterday i killed 17 bugs.. i started from A and going down to Z
[06:25] <fabbione> mdz: if malone doesn't lie to me, we had 200 bugs..
[06:26] <mdz> fabbione: so almost 10% smaller then ;-)
[06:26] <fabbione> mdz: yeps :)
[06:26] <fabbione> mdz: these were all stupid bugs.. but i needed to warm up my X knowledge again..
[06:27] <fabbione> who feels lucky today???
[06:27] <fabbione> http://people.ubuntu.com/~fabbione/xcrack/
[06:27] <fabbione> please test ASAP
[06:27] <fabbione> or be silent forever
[06:55] <lamont> infinity: the issue is that bld-4 can only build them after they publish, not before
[06:55] <lamont> infinity: and avahi, koffice are known b0rked, and the rest of kde is d-w libarts1, which is ftbfs (ICE).
[06:55] <lamont> gcc-3.4 might build if I give it back, or it might just ICE again
[07:01] <Lathiat> avahi is known b0rked ?
[07:02] <fabbione> Lathiat: on hppa
[07:02] <Lathiat> ah
[07:02] <Lathiat> got a build log?
[07:02] <fabbione> on LP?
[07:04] <Lathiat> Status:
[07:04] <Lathiat> Successfully built
[07:04] <Lathiat> ?
[07:05] <Lathiat> doesnt actually work?
[07:23] <infinity> Lathiat: He may be referring to breezy/breezy-security.
[07:38] <fabbione> xorg-server 1.0.2 looks good...
[07:48] <ajmitch> doko: what are we going to do with zope2.x now that various python2.3 bits are missing?
[07:48] <ajmitch> I know it's in universe, but it's rather useful to have :)
[07:59] <infinity> That would be kinda spiffy.
[08:01] <_ion> infinity: Install the "Manage Actions" thingy for nautilus.
[08:01] <_ion> infinity: I haven't created such a menu item, but i do have a "Play as a DVD" item for ISO images.
[08:02] <_ion> It runs mplayer -dvd-device foo.iso dvd://
[08:03] <neuralis> infinity: hey. until i manage to grab ahold of benc, do you perchance now the rationale behind the HZ=100 setting for the server kernel?
[08:03] <neuralis> s/now/know/
[08:03] <infinity> neuralis: Because it's good and pure and true?
[08:04] <infinity> neuralis: Lower HZ == less responsive, but faster machine.
[08:04] <_ion> 100 is also a nice, round number, just like 256.
[08:04] <infinity> neuralis: For a "server-only" machine, that's the upstream recommended value.
[08:04] <neuralis> infinity: i'm aware of the O/S theory behind the number, but i also seem to recall a metric poopton of synchronization troubles on linux SMP machines running at HZ=100
[08:04] <neuralis> infinity: did that get cleared up?
[08:05] <infinity> neuralis: For shared-task machines, they recommend 250 (we don't ship a kernel with 250, I don't think), and for desktops, something ridiculously high, like 1000 (which we ship)
[08:05] <infinity> neuralis: I'm aware of no such poopton, but you may want to ask BenC. :)
[08:06] <neuralis> infinity: yeah, okay. i can't remember when i saw that, so it's possible it was a few years back.
[08:14] <pitti> Good morning
[08:14] <ajmitch> morning pitti
[08:14] <_ion> 'ning.
[08:14] <Burgundavia> morning
[08:15] <Burgundavia> pitti: the new wastebasket icon is part of ubuntu-artwork, no?
[08:20] <pitti> Burgundavia: no idea TBH
[08:21] <infinity> pitti: Can pmount do loopback devices?
[08:22] <infinity> pitti: So I could hack up a cute nautilus action that would allow me to right-click an ISO and mount it to /media/loopX ?
[08:23] <pitti> infinity: not right now, that's a long-standing wishlist item
[08:23] <infinity> pitti: Obviously, we'd need some smart defaults to prevent us from, say, mounting an ext3 image loopback with root-owned suid files on it, or something equally bad, but I assume you already have that safety in place for removeable devices with the same scary.
[08:24] <infinity> In fact, pretend I didn't just mention that, obviously that's already adressed (I hope)
[08:24] <infinity> pitti: The loopback thing wouldn't be too tough to sort, I suspect.
[08:24] <pitti> infinity: yes, you can't disable nosuid and nodev in pmount :)
[08:25] <infinity> pitti: Oh, and BTW, if you have scary stuff in your INBOX about X vulns, I just triple-checked that warty/hoary/breezy aren't vulnerable, and Fabio uploaded for dapper.
[08:25] <pitti> infinity: I didn't think about mounting loopback devices directly, but pmounting iso images should be easy
[08:25] <pitti> infinity: I know about X, I planned to fix it today; it's just dapper
[08:26] <infinity> Yeah, so I saw.  It's fixed now. :)
[08:26] <fabbione> pitti: we already di
[08:26] <fabbione> +d
[08:26] <fabbione> pitti: you need to start to work at "real man" TZ
[08:26] <pitti> oh, great, thanks guys
[08:26] <fabbione> or you will always be left out ;)
[08:26] <fabbione> pitti: since we did spare you the X issue.. could you please reallocate that time for git-core?
[08:27] <pitti> fabbione: yes, sorry, I forgot
[08:27] <infinity> Is that the same git-core that causes the hppa buildds to spin incessantly until the build gets killed? :/
[08:28] <infinity> (seems happy on other arches though, so whatever, I'll investigate later)
[08:30] <woodwizzle> Hello
[08:31] <woodwizzle> I'm planning on creating my own distro based on ubuntu
[08:31] <woodwizzle> liveCD particularly
[08:32] <elkbuntu> woodwizzle, the guys in here probably a bit too busy for this stuff, did you try #ubuntu-motd?
[08:32] <infinity> s/d/u/
[08:33] <woodwizzle> nope, that'll be my next stop, thanks
[08:33] <neuralis> woodwizzle: he means #ubuntu-motu
[08:33] <elkbuntu> gah, she and yes
[08:33] <woodwizzle> I'm just looking for some basic info to get me started, I've never done anything like it before and dunno where to begin
[08:33] <elkbuntu> those two abbr are too similar :P
[08:34] <neuralis> elkbuntu: oh, sorry. she :)
[08:34] <elkbuntu> no prob
[08:36] <elkbuntu> while people are responding. apt-get result is far different to the update-notifier result. i'm using the mvo (??) version of the notifier i think. someone in here told me to use it instead a few days ago
[08:36] <mdke> joelbryan, ping
[08:38] <mdke> elkbuntu, the update-manager doesn't include packages which are upgraded when you do a dist-upgrade. Is that what you mean?
[08:38] <elkbuntu> mdke doing fresh screenshots now
[08:38] <elkbuntu> i did some earlier, but theres alot more pacakages listed now
[08:38] <elkbuntu> and no, a plain upgrade
[08:39] <elkbuntu> the update manager is doing more than apt-get upgrade
[08:39] <mdke> how odd
[08:39] <elkbuntu> or, wanting to
[08:39] <mdke> you have a custom version of update-manager?
[08:39] <elkbuntu> mdke, uh, one done by mvo or something like that
[08:39] <mdke> elkbuntu, all the ones are done by mvo
[08:39] <elkbuntu> well that makes it hard then
[08:40] <mdke> you installed one yourself?
[08:40] <mdke> what version?
[08:40] <elkbuntu> i came in here a few days ago to ask why both gnome and x screensaver were both installed, and someone told me i wasnt using the right update-manager since it hadnt removed xscreensaver
[08:41] <mdke> the answer is likely to be that you have been running dapper for some time :)
[08:41] <mdke> I don't think one gets removed automatically.
[08:41] <elkbuntu> mdke not really, i apt-get dist-upgraded this install about a month ago
[08:42] <elkbuntu> anyway 'apt-cache policy update-manager':
[08:42] <elkbuntu>   Installed: 0.42.2ubuntu8 Candidate: 0.42.2ubuntu8
[08:42] <mdke> that's the same one I have
[08:42] <infinity> elkbuntu: The update manager will do "upgrade + new packages", while apt-get upgrade does "only upgrade, if nothing is added or removed"
[08:42] <mdke> file a bug then, I suppose
[08:42] <mdke> aha
[08:42] <elkbuntu> infinity, apt-get is holding stuff back
[08:43] <infinity> elkbuntu: That's intentional, so we can pull in kernel upgrades (which require new packages) with update-manager.
[08:43] <infinity> elkbuntu: Yes, read what I said again.
[08:43] <infinity> elkbuntu: "apt-get upgrade" won't change anything (add/remove packages), it will only upgrade packages.
[08:43] <infinity> elkbuntu: "apt-get dist-upgrade" will violently add and remove packages to try to upgrade you.
[08:43] <elkbuntu> so update-manager runs dist-upgrade, not upgrade?
[08:44] <infinity> elkbuntu: update-manager is halfway between (it will only add packages, never remove)
[08:44] <elkbuntu> oooh
[08:44] <elkbuntu> i prefer to use apt-get, since it's a zillion times quicker
[08:45] <elkbuntu> is there not an apt-get version of 'halfway inbetween'?
[08:45] <infinity> Then you get to either dist-upgrade and carefully read the output to make sure it's not breaking something, or do upgrade, then manually "apt-get install" each package it's holding back to see why.
[08:45] <infinity> No, apt-get doesn't have the "add only" option.  (other than the advice I just gave)
[08:46] <elkbuntu> hmmm... if there's no known explosive issues i guess i'll dist-upgrade :P
[08:46] <mdke> they are kept back for a reason generally, I think
[08:47] <infinity> If dist-upgrade isn't threatening to remove anything starting with ubuntu- (ubuntu-minimal, ubuntu-desktop, etc), you're probably fine.
[08:47] <elkbuntu> mdke i pity the poor person dist-upgrading from breezy at this very minute then :)
[08:47] <_ion> The reason was just given a few lines above. :-)
[08:47] <infinity> mdke: kept back package are only kept back because upgrading them will force the removal of something else.  This isn't necessarily a bad thing (in fact, we do it on purpose a lot), it's just stressful for people who are trying to figure out why. :)
[08:47] <mdke> ah
[08:48] <infinity> mvo's cute little dist-upgrader tool is meant to take some of the mystery out of this for people going from breezy->dapper who aren't terribly CLI-friendly.
[08:48] <mdke> I thought some packages are kept back on purpose because they are known to break things
[08:48] <elkbuntu> mdke, i guess it's about 'potential'
[08:49] <elkbuntu> anyway, i'll let youse know in a while if it explodes me ;)
[08:50] <elkbuntu> btw, one other thing.. who broke amarok's xine engine *cries*
[08:53] <_ion> Hmm. I googled and found this  is this in breezy? http://people.ubuntulinux.org/~mvo/dist-upgrader/dist-upgrade.png
[08:54] <infinity> _ion: It will be in breezy-updates yes, that's the point.
[08:54] <_ion> Very nice.
[08:54] <infinity> _ion: We'll recommend people install it to do their dist-upgrade.
[08:55] <mdke> that should be added to the releasenotes I suppose
[08:56] <elkbuntu> speak of the devil
[08:56] <pitti> hi mvo
[08:56] <mvo> hey pitti
[08:58] <_ion> There's a stomach where wrestling happens.
[04:04] (BenC/#ubuntu-devel) ide-generic is actually causing immediate problems, and the "bus type" thing is just a hack
[04:04] (Kamion/#ubuntu-devel) and is there any other safe way to fix that hardware?
[04:04] (mdz/#ubuntu-devel) BenC: what problems?
[04:05] (BenC/#ubuntu-devel) mdz: problem where SATA isn't detecting fast enough, so ide-generic gets loaded and your SATA controller is suddenly a legacy IDE controller
[04:05] <BenC> Kamion: not so much a regression as it is that it's much more common
[04:06] <Kamion> can we do the 10-second thing (although I thought we did it already) and *not* do UUID?
[04:06] <BenC> that coupled with the fact that we need UUID support in order to make the change from IDE to SATA/PATA drivers next release
[04:06] <mdz> where does UUID enter  into it?
[04:06] <Kamion> BenC: we have to cope with migration from breezy anyway, doesn't much matter whether we do that in dapper
[04:06] <mdz> we made an explicit decision way back at UBZ not to do rely on UUID by default for dapper
[04:06] <BenC> switching IDE to PATA requires us to do UUID atleast one release before
[04:06] <mjg59> BenC: No, since we can't enforce UUIDs on upgrades
[04:06] <jdub> highvoltage: ping
[04:06] <Kamion> but breezy->dapper upgrades wouldn't switch fstab/grub menu.lst etc.
[04:06] <mdz> BenC: how so?  I don't see why we couldn't make that change on upgrade
[04:07] <BenC> ok, UUID makes it _simpler_
[04:07] <mjg59> Or, if we /can/ enforce that on upgrades, we can do it on upgrade anyway
[04:07] <Kamion> mjg59: right
[04:07] <Mithrandir> I'm thinking of an evil hack.
[04:07] <mdz> mounting root by UUID by default is a completely appropriate dapper+1 feature
[04:07] <mdz> trivial to switch on early, plenty of time to sort it out, dapper waiting in the wings if it turns out to be chancy
[04:07] <BenC> UUID is the minor issue here, the ide-generic delay is the major one
[04:08] <Mithrandir> we could encode the uuid of the current root fs in the initrd and fall back to that if / doesn't appear.
[04:08] <Kamion> I've got no objection to changing initramfs-tools for that at this stage
[04:08] <BenC> Mithrandir: there's a sweet idea
[04:08] <mjg59> BenC: I think we should fix that in any case. It's initramfs-tools that needs fixing - who's working on that right now?
[04:08] <Kamion> if we get it wrong, it'll be noticed quickly, and it's fixable on upgrades
[04:08] <Mithrandir> it's a hack, but it'd probably save our backside, wouldn't it?
[04:08] <Kamion> installer bugs take much much longer for people to notice
[04:08] <BenC> infinity is the culprit :)
[04:10] <BenC> ok, so initramfs-tools, record UUID in image, check it if / doesn't appear, if neither shows up, delay 10 seconds, load ide-generic and repeat with current delay (30 seconds?)
[04:10] <BenC> that sound good?
[04:10] <Kamion> also, for the IDE->PATA upgrade, I'd actually prefer if dapper didn't do UUIDs so that the upgrade issues from installations made using breezy or earlier were right in our face rather than being hidden
[04:10] <BenC> Kamion: good point
[04:10] <Kamion> (since I doubt we have time to get the upgrades right for all boot loaders etc. at this point)
[04:10] <Mithrandir> Kamion: didn't do, as in, didn't fall back?
[04:11] <highvoltage> jdub: pong
[04:11] <Kamion> Mithrandir: no, I mean didn't mount root by UUID by default in the simple way
[04:11] <Mithrandir> Kamion: or are you talking about what's put on the kernel command line?
[04:11] <Kamion> not referring to your hack
[04:11] <Kamion> command line
[04:11] <Mithrandir> Kamion: sure, so not changing the current state, which is to do it for stuff we see is on removable devices in the installer, but nothing else.
[04:12] <jdub> highvoltage: hey - mind if i copy those cake images onto the fridge? don't want to punish your server by deep linking to them.
[04:12] <highvoltage> jdub: i won't mind at all, those images are hosted on some server in the UK with lots of bandwidth :)
[04:15] <Kamion> Mithrandir: BTW, did you see my casper merge request?
[04:15] <jdub> wow
[04:15] <jdub> http://fridge.ubuntu.com/node/300
[04:15] <jdub> 300th post :)
[04:16] <Mithrandir> Kamion: yes, sorry, I never got around to it.  What's the URL again?
[04:16] <Kamion> 15:14 < Kamion> Mithrandir: please merge http://people.ubuntu.com/~cjwatson/bzr/casper/espresso-passwd/ - fixes wrong defaults on espresso's user/password screen
[04:16] <maswan> hmm..
[04:16] <highvoltage> jdub: congrats :)
[04:16] <maswan> only debian cakes so far, should perhaps adjust that. :)
[04:17] <Mithrandir> Kamion: oh, looks good.
[04:18] <Mithrandir> Kamion: uploaded
[04:18] <torkel> maswan: You know what we expect from you when Sarek is upgraded :-)
[04:18] <seb128> what is the "standard" file to use to set an environment variable your session?
[04:18] <maswan> torkel: :)
[04:18] <neuralis> Mithrandir: someone's working on updating the tags patch for bzr 0.8, iirc.
[04:19] <seb128> there is a bug on gnome-session than ~/.bashrc is not used by GNOME, it's not supposed to be, right?
[04:19] <Mithrandir> seb128: it's not.  Why should it?
[04:19] <Amaranth> heh, the forums folks are freaking out about the 2.6.16 kernel
[04:19] <Amaranth> "16 is one higher than 15, it must be better! we have to have this!"
[04:19] <Mithrandir> seb128: gnome has .gnomerc, doesn't it?
[04:20] <seb128> Mithrandir: for no reason, but I want to point the guy to what to edit
[04:20] <Seveas> Amaranth, typical for the forums
[04:20] <seb128> Mithrandir: yeah, gnome-session source ~/.gnomerc
[04:20] <highvoltage> jdub: lol! nice entry. thanks :)
[04:21] <seb128> Mithrandir: but is there a ~/.environment or something used by xorg whatever desktop you use?
[04:21] <seb128> Mithrandir: or you have to use /etc/environment? :)
[04:21] <jdub> mdke: i wonder if your fascist proxy would block 'cocksmoking'
[04:21] <jdub> i don't think i've said that in my blog yet
[04:22] <Mithrandir> seb128: ~/.pam_environment, yes.
[04:22] <jdub> nup
[04:22] <jdub> it's probably due
[04:22] <Treenaks> jdub: There is such a thing as "Too much Lugradio"
[04:22] <jdub> do they say cocksmoking?
[04:22] <Amaranth> probably
[04:22] <jdub> i should get a podcast client
[04:22] <jdub> and a portable music player
[04:22] <Treenaks> jdub: planet works great for me :)
[04:23] <seb128> Mithrandir: ok, thank you
[04:23] <Treenaks> planet + wget = all the podcasting I need :)
[04:23] <jdub> planet doesn't suck down enclosures
[04:23] <jdub> heh
[04:23] <Mithrandir> Kamion: ok, people.ubuntu.com/~tfheen/bzr/espresso/trunk/ should be mergeable now.  Note that I need to do two uploads before it's actually installable, though.
[04:24] <Kamion> Mithrandir: ok, I'm going out to pick Benedict up from school in a moment so you have some time :)
[04:24] <neuralis> jdub: let me know if you find a podcast client that doesn't suck.
[04:24] <Kamion> thanks
[04:24] <jdub> does rhythmbox suck?
[04:25] <neuralis> jdub: the podcast support there is pretty young, i haven't gotten around to trying it
[04:25] <Amaranth> banshee needs podcast support :/
[04:32] <Mithrandir> Kamion: ok, all uploaded, please new espresso-kbd-chooser and I hope I didn't break anything.
[04:46] <lbm> mvo: ping
[04:48] <mvo> lbm: hello
[04:48] <lbm> mvo: can i msg you?
[04:48] <highvoltage> jdub: i quit like beep-media-player, although it's not for everyone
[04:48] <jsgotangco> mvo: hi!
[04:48] <jdub> highvoltage: it does podcasting now?!
[04:49] <highvoltage> jdub: oops, missed that part.. erm... no :)
[04:49] <jsgotangco> heh
[04:49] <jsgotangco> rhythmbox is pretty solid on that part
[04:50] <mvo> jsgotangco: hello!
[04:50] <mvo> lbm: sure
[04:50] <jsgotangco> mvo: have you given thought on glatzor's mail about the naming conventions?
[04:52] <mvo> jsgotangco: not, not yet. sorry. I was away the last two weeks and hadn't had time to think about this
[04:52] <jsgotangco> mvo: same here catching up on emails actually
[04:53] <mvo> :)
[05:00] <jsgotangco> GAIM for chat? heh
[05:01] <spacey> is their some meta package with debug symbols? I want to do a backtrace on epiphany but no idea which debug symbol package i should get
[05:02] <BenC> Kamion, mdz, mjg59, Mithrandir: Sent a copy of the UUID/ide-generic discussion to u-d-a
[05:19] <psusi> why does mounting by uuid depend on ide-generic?
[05:21] <Kamion> psusi: that's a bit of a garbling of the discussion ...
[05:22] <Kamion> Mithrandir: you uploaded kbd-chooser to unstable by mistake
[05:28] <psusi> so the gist of it is that you don't want to load ide-generic until you are sure you have tried all other drivers, but you have no way to know for sure that all the other drivers have given up?
[05:29] <mjg59> psusi: You don't for sure
[05:34] <psusi> and this is because the pci ide drivers load and probe for drives asycnrhonously, and have no method of signaling that they have completed their probe?
[05:35] <Kamion> psusi: that's more SCSI
[05:35] <Kamion> you load the driver, and at some later point the drive says "oh yeah, hi, I'm here"
[05:36] <psusi> and the problem is that the driver doesn't ever say "I have completed my scan, and found no drives" right?
[05:36] <Kamion> no - the problem is that if you load ide-generic during that period, it'll grab anything that hasn't been grabbed by a more specific driver; if it grabs say a SATA drive, performance will degrade lots
[05:37] <psusi> so if you are hoping that it will find a drive you just have to wait for an arbitrary period of time?  which isn't good...
[05:37] <Kamion> the driver *does* say that, it just takes a while, and we're doing other stuff in the meantime
[05:37] <Kamion> oh, sorry, it never says "no drives" AFAIK, right
[05:37] <Kamion> but it's not really the driver's fault, it's having to ask the SCSI bus
[05:37] <psusi> right... that's what is needed then... the driver needs to signal when it has completed it's scan so if it found no drives, you can then fall back to ide-generic, right?
[05:38] <Kamion> as I understand it, the driver has no way to know
[05:38] <Kamion> it's not scanning, it's standing up and shouting "hello, is anyone there?"
[05:38] <psusi> sure it does... it knows how it is scanning for drives and when it is done it scans no more
[05:38] <mjg59> Kamion: Well, there's two issues there
[05:38] <mjg59> Kamion: The drivers won't start probing for disks before they've registered the interface, so there's no race with ide-generic there
[05:38] <psusi> well, if we're talking about scsi disks, then it issues a scsi INQUERY command to each possible bus/target
[05:39] <psusi> once it has done that for all busses/targets, it knows it is done scanning
[05:39] <mjg59> Kamion: But you have no idea how long they're going to take scanning
[05:39] <mjg59> Kamion: On the other hand, loading a PCI driver doesn't instantly bind it to the PCI device, and even then it doesn't instantly bind it to the IDE layer
[05:39] <mjg59> And so ide-generic can grab it if it's loaded at the same time and you get unlucky
[05:40] <psusi> there has to be some signal you can watch for to see that the pci driver has bound to the device and ide layer right?
[05:40] <mjg59> psusi: Ngh. Well, ish.
[05:40] <psusi> something in /proc
[05:41] <mjg59> When it's bound to the PCI device, there'll be a device link in /sys/bus/pci/drivers/foo
[05:41] <mjg59> But foo isn't necessarily related to the module name
[05:41] <Diziet> FFS!  This `recipe' for conffile-mangling in the preinst script _reads /var/lib/dpkg/status_ for the md5sum of the conffile ?!
[05:42] <Diziet> And it renames things to .dpkg-tmp and  FFS!!
[05:44] <psusi> you mean the driver name and module name could be different?
[05:44] <psusi> anyone who does that should be slapped
[05:44] <mjg59> psusi: Yes
[05:44] <psusi> with a few phone books
[05:49] <Kamion> Diziet: I blame Scott
[05:50] <Kamion> dpkg could really do with a few more built-in ways to work with conffiles though
[05:50] <Diziet> Amongst the bizarre effects is that it does one thing if you   dpkg --unpack a.deb b.deb   and a different thing if you   dpkg --unpack a.deb && dpkg --unpack b.deb
[05:50] <Diziet> It could do with having fewer bugs in corner cases.
[05:51] <pitti> Diziet: what's the prefered way of determining whether a conffile is unmodified?
[05:52] <pitti> Diziet: whenever a package wants to remove an old confile, it needs to go through this grep/md5sum dance right now
[05:52] <BenC> pitti: is changing the lock default to 0 really the best thing in the case of cdroms?
[05:52] <BenC> I saw one report that it caused some weird problems when a second cd was inserted
[05:52] <pitti> BenC: alternative solutions would be modifying /etc/sysctl.conf, or adding an udev rule, but both were considered evil
[05:52] <BenC> also, just because "windows does it" doesn't make it right
[05:53] <BenC> pitti: for instance, macosx doesn't let you just hit eject, you have to do more :)
[05:53] <Kamion> pitti: I think he means doing at at all, not where it's done?
[05:53] <pitti> BenC: oh, other distros seem to do it as well, according to the bug reports
[05:53] <pitti> Kamion: I know that moving conffiles to other packages is not nice, but it just happens from time to time...
[05:53] <BenC> it seems that gnome-v-m doesn't really handle the cdrom being ejected out from under it all to well
[05:53] <pitti> erm, Diziet ^
[05:54] <Diziet> pitti: No package should ever do anything of this kind.  If dpkg doesn't do it right then we should fix dpkg.
[05:54] <pitti> BenC: right, we need to umount -l the CD after ejection
[05:54] <wftl> I've checked out https://wiki.ubuntu.com/LiveCDPersistence regarding the creation of a persistent home directory on Dapper live, but it's far from user friendly. Is there any plan (with the extention on the release date) to create some kind of friendly front end for persistence.
[05:54] <Diziet> There is no reliable way for a package to tell what's going on, let alone safely interfere.
[05:54] <wftl> Some kind of easy to use GUI.
[05:54] <BenC> pitti: what if someone ejects the liveCD? :)
[05:55] <pitti> BenC: then they are doomed, I guess :)
[05:55] <Kamion> Diziet: as I understand it it is a design decision in dpkg that it doesn't remove conffiles. Packages need to have a way to tell dpkg that this file is now definitely redundant (or even harmful) and should go away now damnit.
[05:55] <Kamion> I mean, doesn't remove old conffiles except on purge
[05:55] <Kamion> where "go away now" may certainly include "leave a backup somewhere, but get rid of it from its former location"
[05:56] <pitti> Diziet: so far packages tend to rm unmodified connfiles, and mv foo foo.dpkg-old modified ones
[05:56] <Diziet> kamion: Ah, I see.  Yes, there should be a way to tell it that.
[05:56] <Kamion> also, packages need a way to tell dpkg "this conffile needs to be renamed", and there's no way to do that without maintainer script hackery at the moment (if you leave out the maintainer script hackery, then admin changes in the old file will not be preserved)
[05:56] <mjg59> Ah, good
[05:56] <mjg59> Even with elilo installed, it's possible to get the macs to boot macos
[05:57] <Diziet> If I get rid of the postinst and preinst from postgresql-common_46 then everything works just fine.
[05:57] <BenC> pitti: I'm a little skeptical of the lock=0 thing, I think the argument that "newbies wont know" is not a good one, because Mac users are definitely newbie types and they deal with it all the time
[05:57] <Kamion> mjg59: hold down some magic key?
[05:57] <pitti> Diziet: oh, funny
[05:57] <Diziet> Let me try it with a modified file.
[05:57] <pitti> Diziet: so dpkg complains about a conflict if the file is not actually present, and works if it is?
[05:57] <Kamion> holding down Option at startup would get you the usual menu, I suppose
[05:57] <BenC> of course, most mac users have a keyboard eject button as opposed to one on the drive
[05:58] <BenC> pitti: I'll give it some thought
[05:58] <pitti> BenC: right, on ppc you need to eject with software anyway
[05:58] <pitti> BenC: ok, thanks
[05:58] <Diziet> pitti: Your maintainer script creates *.dpkg-tmp !
[05:59] <Diziet> *.dpkg-tmp is for the use of dpkg, not maintainer scripts !
[05:59] <mjg59> Kamion: Yeah
[05:59] <pitti> Diziet: ok, I can rename that to .dpkg-migration, or whatever
[05:59] <Diziet> No, just get rid of all of this stuff.
[05:59] <mjg59> kamion: Hold down alt and then hit enter
[05:59] <Kamion> right, figures
[05:59] <Diziet> What goes wrong if you don't have it ?
[05:59] <pitti> Diziet: if the conffile is modified, then dpkg asks silly questions
[05:59] <Diziet> I just tried that and it worked just fine.
[06:00] <Diziet> (I haven't tried it with breezy's dpkg.)
[06:00] <pitti> Diziet: also, if the replacing package's version of the conffile is different from the replaced one, it'll ask as well
[06:00] <Diziet> I think that case is also covered but I will test it now.
[06:00] <pitti> Diziet: that was a huge problem in hoary and breezy, we had to apply this hackery to a lot of packages to avoid dpkg conffile questios on upgrades
[06:00] <pitti> Diziet: if dapper's dpkg gets that right now, so much the better :)
[06:01] <Diziet> pitti: Yes, that case works just fine.
[06:01] <Diziet> That's the conffile migration bugfix.
[06:01] <pitti> Diziet: i. e. a conffile was in gimp in hoary, and breezy moved it to gimp-common, but it had a different version of that file
[06:01] <Diziet> But the workaround is completely broken in about three separate ways.
[06:01] <Diziet> pitti: That works just fine now.
[06:01] <pitti> Diziet: cool
[06:02] <pitti> Diziet: sorry, I didn't test it with modified conffiles without the magic, since it was necessary up to a few months ago
[06:03] <Diziet> Three ways: 1. stupid approach; should fix dpkg instead (now done).  2. doesn't get the right hash because /var/lib/dpkg/status is not definitive.  3. uses a private-to-dpkg filename.
[06:03] <Diziet> So shall I upload postgresql with the hack removed ?
[06:03] <pitti> Diziet: I'll do that for Debian myself
[06:03] <pitti> Diziet: and that version isn't in Ubuntu yet
[06:03] <Diziet> I'm going to grep the archives for similar idiocy and see if I want to do a mass bug filing.
[06:03] <Diziet> Right, OK.
[06:03] <pitti> Diziet: yep, you'll probably find lots of packages with that approach
[06:04] <Kamion> Scott added similar code to a number of packages; I know it appeared in pcmciautils
[06:04] <Diziet> Debian's dpkg has the fix too (not sure if it's in sarge, but Debian's dpkg maintainers accepted my patch).
[06:04] <pitti> Diziet: thanks for checking this out
[06:04] <Diziet> What a huge amount of effort compared to the day or two it took me to fix the problem in dpkg !
[06:04] <Diziet> pitti: No problem.
[06:05] <Kamion> Diziet: pcmciautils is probably another good test case for you; in that case it's dealing with an obsolete conffile
[06:05] <Diziet> Does the file have to be deleted to avoid causing trouble ?
[06:05] <Kamion> the code was added in version 010-0ubuntu8; I'll fish the .debs out of the morgue
[06:05] <Diziet> morgue> Don't bother.
[06:06] <Kamion> I think we could survive if it's not removed, but it would confuse people (since users often go wandering around in /etc/udev/ to try to figure out why hardware detection isn't working)
[06:06] <Diziet> You could replace it with an empty file or a comment saying `this file is obsolete'.  Not ideal, I know.
[06:07] <Diziet> Oh, it turns out that my own archive doesn't go back as far as 010-0ubuntu8.
[06:07] <Kamion> True
[06:07] <pitti> Diziet: but that would again trigger a dpkg conffile question if it is modified
[06:07] <Diziet> Yes, but then the user probably wants to know that they modified this now-obsolete file and have to do something to make their changes in the new arrangements.
[06:07] <Kamion> hmm, looking at it, strictly speaking the conffile was moved ...
[06:08] <Diziet> Renamed, you mean ?
[06:08] <Kamion> yeah, we used to install it in /etc/udev/pcmcia.rules and make a symlink to /etc/udev/rules.d/85-pcmcia.rules; now we install it in /etc/udev/rules.d/85-pcmcia.rules directly
[06:09] <Diziet> I can't remember what dpkg does if you're naive about this but it's probably not good.
[06:09] <Kamion> but I initially did it very crudely (because the package was very new, not installed on many systems, and frankly I didn't care); then Scott came along and added code to remove the obsolete file that was now hanging around
[06:09] <Diziet> Do you want me to look into it ?
[06:10] <Diziet> Anything that messes with *.dpkg-* or /var/lib/dpkg in a maintscript is probably broken.
[06:10] <Kamion> If you want all examples of such code to go away, then you're welcome to treat it as another test case, but it's not critical for breezy->dapper upgrades or anything (since that package didn't exist in breezy)
[06:10] <Diziet> Right.  OK, well, I'll just deal with it in my grep results then just as soon as I've written the grep script :-).
[06:11] <Kamion> I would like to know what the code should now be replaced by though (and if the answer is "nothing", all the better)
[06:11] <Diziet> Quite so.
[06:14] <janimo> jdub, any specific gnomey stuff you want to see in xubuntu ;) ?
[06:15] <sivang> janimo: xubuntu is in main now? :)
[06:15] <janimo> not yet
[06:43] <dholbach> mdz, Kamion: are you ok with an update from gthumb 2.7.5 -> <IP_ADDRESS> (you gave your ok on 2.7.5 and the update fixes an issue, we were going to fix in a patch, which now can be dropped) - or you want another mail for that?
[06:44] <mdz> dholbach: yes
[06:44] <pitti> dholbach: does that fix the 'absolute path' bug?
[06:44] <dholbach> mdz: 'yes' ok or 'yes' mail? :)
[06:44] <dholbach> pitti: you mean the broken importing?
[06:44] <mdz> dholbach: yes, if it's only one patch and it's appropriate, go ahead
[06:44] <pitti> dholbach: yes
[06:45] <dholbach> mdz: merci
[06:45] <dholbach> pitti: yes
[06:45] <pitti> dholbach: rock :)
[07:13] <Tonio_> hello everyone
[07:13] <Tonio_> _ion: heard you asked for me ?
[07:15] <LaserJock> Seveas: ping?
[07:15] <Seveas> LaserJock, yes?
[07:16] <LaserJock> Seveas: I was just reading the backlog, did \sh get taken care of?
[07:16] <Seveas> don't know - still have to poke ogra
[07:16] <Seveas> let's move to -motu
[07:21] <setuid> I'm trying to rebuild a patched version of ibm_acpi in 2.6.15-18... I've pulled the source for the kernel, but how do I build _just_ this module, using the Ubuntu process? I'm used to doing "make modules SUBDIRS=drivers/acpi".
[07:22] <Treenaks> Why are you doing this?
[07:22] <setuid> Because I need a patched version running on my Thinkpad
[07:22] <setuid> I need the fan speed to go 2000rpm higher
[07:22] <setuid> I have a full-speed option that I pass to it
[07:23] <Treenaks> setuid: We're trying to make everything work out of the box, so this is a bug, please file it.
[07:23] <setuid> Its not a bug, its just an option not in the standard ibm_acpi code
[07:23] <Treenaks> setuid: That's a bug. EVERYTHING should work correctly out of the box.
[07:23] <setuid> There's 'enabled' and 'disabled', but I have a 'full-speed' option which brings the fan from 3,000 rpm to 5,000rpm
[07:23] <setuid> Its a feature, not a bug
[07:24] <Treenaks> setuid: So if your laptop doesn't, please file this as a bug so it can be integrated in the stock kernel
[07:24] <setuid> See above
[07:24] <Treenaks> setuid: Features are wishlist bugs.
[07:24] <setuid> semantics
[07:24] <Kamion> lamont: ia64 systems running 2.4 are guaranteed to have /proc/efi, right?
[07:25] <Kamion> or no?
[07:25] <setuid> Treenaks: So that still doesn't answer my questiuon
[07:25] <Treenaks> setuid: you're not asking the right question, that's what I'm saying
[07:25] <setuid> I need to rebuild ibm_acpi using the Ubuntu "standard" build process, but *JUST* this module, not all the kernels for all the architectures
[07:25] <Kamion> what goes wrong when you issue the command you mentioned?
[07:25] <setuid> So how do I use the Ubuntu-provided kernel sources, patch the ibm_acpi module, and rebuild _JUST_ this module
[07:26] <lamont> Kamion: uh...
[07:26] <lamont> 2.4... hrm.
[07:27] <lamont> Kamion: "if the module is loaded"
[07:27] <Kamion> which module?
[07:32] <setuid> Treenaks: http://rafb.net/paste/results/EgL6nE60.html
[07:35] <setuid> Treenaks: Was my question not succinct enough?
[07:35] <dholbach> ogra: yet another dia for you :)
[07:35] <setuid> debuild? dh-make? What is the process for properly building this module, in a way that puts the right EXTRAVERSION and such in
[07:36] <Kamion> setuid: your question didn't specify (a) what went wrong when you did what you did, (b) whether you got the source using 'apt-get source' or by installing the source .deb
[07:37] <setuid> Kamion: I pulled the source with apt-get source
[07:37] <Kamion> dh_make is for creating packages from scratch and is not appropriate here
[07:37] <Kamion> Treenaks: come on, "bugger off to gentoo" isn't a fair answer for somebody who wants to make a small tweak to their kernel
[07:37] <setuid> Treenaks: Don't be a troll, I've been running Debian for 8+ years, I know the drill... but Ubuntu is a very different beast.
[07:37] <setuid> I typically do 'debuild' in the unpacked source tree
[07:38] <setuid> but doing that here will take 1-2 days, since it builds every kernel for every arch
[07:39] <Kamion> setuid: give me a minute to grab the source over wireless and duplicate the problem
[07:39] <Treenaks> Kamion: I know, but he doesn't seem to want to even TRY to add this to malone and be helpful for other people
[07:39] <setuid> Treenaks: You clearly don't understand the development/testing process. I can't add it to the 'malone' thing, until I verify that it ACTUALLY WORKS here.
[07:39] <Kamion> Treenaks: you don't seem to want to try to help him, either ...
[07:39] <setuid> Ok, I managed to get it working now
[07:39] <Treenaks> nevermind
[07:40] <setuid> Built it standalone, outside the tree
[07:40] <setuid> Works great
[07:40] <setuid> # cat /proc/acpi/ibm/fan
[07:40] <setuid> status:         disabled
[07:40] <setuid> speed:          5312
[07:40] <setuid> commands:       enable, disable, full-speed
[07:40] <Kamion> setuid: so what actually went wrong when you tried to do what you did?
[07:40] <Kamion> you gave a command you ran, but not the actual problem
[07:40] <setuid> Kamion: debuild builds a kernel that doesn't match the one I'm running from the upstream package
[07:40] <setuid> I had to hack the top-level Makefile and some files below to fool it
[07:41] <Kamion> the Ubuntu kernel's ABI is indeed not the same as that of the upstream kernel
[07:41] <Kamion> unless you mean something different by "upstream package"
[07:41] <setuid> There's some magical mojo with .configs and such, right?
[07:41] <Kamion> sure, but debian/rules takes care of that
[07:41] <setuid> upstream package in this context == the .deb that installed the kernel in /boot
[07:42] <setuid> hrm, looks like there's a config in /boot and others in debian/config/i386/
[07:42] <Kamion> if unpacking the source and running debuild doesn't get you essentially the same thing (not perhaps md5sum-identical, but at least compatible) as the .deb, that's (a) a bug and (b) very odd since the buildds essentially just do debuild (well, dpkg-buildpackage, but who cares)
[07:42] <setuid> I think I want the one that matches the one I'm actually running
[07:43] <Kamion> if you're hacking it about and then running debuild, that's a different story
[07:43] <setuid> I had to hack it about just so it would build a kernel that matched the one I'm running
[07:43] <Kamion> debian/config/i386/ has config fragments for each of several different kernel builds; debuild builds them all
[07:43] <setuid> # uname -a
[07:43] <setuid> Linux angst 2.6.15-18-686 #1 SMP PREEMPT Thu Mar 9 15:29:22 UTC 2006 i686 GNU/Linux
[07:43] <Kamion> building on current dapper?
[07:43] <Kamion> because the buildds really do not do anything magic here
[07:43] <setuid> $ grep EXTRAVERSION Makefile
[07:43] <setuid> EXTRAVERSION =.5-ubuntu1
[07:43] <Kamion> they're just a current dapper installation, and they run dpkg-buildpackage
[07:43] <Treenaks> doesn't dapper have -19 now?
[07:44] <setuid> So if I build with the unpacked kernel source from Ubuntu, it'll build a kernel which is different from the running kernel
[07:44] <setuid> Treenaks: major bugs with -18 and -19, can't boot the system if its docked, or if any other hard drives are plugged in except /dev/hda
[07:44] <setuid> And some sound-related issues
[07:44] <setuid> Have to run: amixer sset 'Headphone Jack Sense' off && amixer sset 'Line Jack Sense' off
[07:44] <setuid> Breezy has no problem in this same situation
[07:44] <Kamion> if you debuild the kernel source package, it will give you several linux-image packages, not just one kernel
[07:45] <setuid> Right, and I don't need the other 8 architectures
[07:45] <setuid> Can I pass it a flag to build just 386/686
[07:45] <Kamion> they aren't architectures BTW, they're flavours - knowing the right term will help you find what you need
[07:46] <setuid> well, 6 architectures that is
[07:46] <setuid> sparc, amd64, etc. are 'flavors'? In my vernacular they're chip architectures.
[07:46] <Kamion> setuid: move the files for the flavours you don't want in debian/config/i386/ to foo.disabled
[07:46] <Kamion> setuid: debuild does not cross-compile to sparc, amd64, etc. if you're building on i386
[07:46] <Kamion> sparc, amd64, etc. are architectures
[07:46] <Kamion> 386, 686, k7 etc. are flavours
[07:47] <setuid> Ideally, that would allow me to pass the 'flavor' I want to build, but renaming them is a hacky solution I suppose.
[07:48] <Kamion> (either that or hack debian/rules)
[07:48] <Kamion> (the configs := bit)
[07:48] <setuid> True, either way requires manual editing ;)
[07:49] <Kamion> it would be possible to implement an environment variable that let you specify a subset of flavours, I'm sure; BenC would know whether that's sane
[07:50] <Kamion> the boot problems you mentioned above were discussed here earlier, I think, and will be handled by some fun initramfs-tools hacking
[07:51] <Kamion> not strictly a kernel issue as such, though kernel changes might happen to avoid it
[07:51] <Kamion> (as far as I know, anyway)
[07:56] <setuid> building now...
[07:57] <blacking> sorry for my intrusion here..
[07:57] <blacking> probably my post is OT..
[07:57] <pitti> blacking: as long as you stay on topic, you aren't intruding :)
[07:57] <pitti> oh
[07:58] <blacking> i found resources link or other as install a minimal ubuntu into an usb pen drive..
[07:58] <blacking> for ppc platform..
[07:59] <blacking> https://wiki.ubuntu.com/Installation/FromUSBStick
[08:01] <LaserJock> blacking: you should probably try #ubuntu or we can keep talking in #ubuntu-doc
[08:37] <Pygi> infinity: ping
[08:37] <Mithrandir> Kamion: bah, silly me.  Did you retarget it or should ?
[08:37] <Mithrandir> I, even.
[08:38] <Mithrandir> Pygi: you're being optimistic that infinity is around at 06:38 in the morning? :-)
[08:38] <Pygi> Mithrandir: ah, sorry ^_^ Didn't knew it was that time in his country ^_^
[08:39] <Mithrandir> Pygi: I doubt he minds, he's probably asleep, but I wouldn't expect a response for a few hours.
[08:39] <Mithrandir> Pygi: he lives in Australia
[08:39] <simira> Mithrandir: you expect everyone to know?
[08:40] <Tonio_> _ion: ping
[08:40] <Mithrandir> simira: no, I tell Pygi that he's slightly optimistic and I assume he didn't know (or he wouldn't have tried).
[08:40] <Mithrandir> Pygi: anyway, he'll probably respond to your question if you just ask your thing, when he gets around.
[08:41] <simira> :-)
[08:41] <Pygi> Mithrandir: kk, thanks ;)
[08:41] <Pygi> infinity: would you be so kind to build new l-r-m modules with patch on this new kernel build? thanks ^_^
[09:17] <psusi> Mithrandir: still not heard anything back from upstream about the e2fsprogs kernel header conflict on amd64?
[09:17] <Mithrandir> psusi: no, I should probably ping them again
[09:18] <Mithrandir> psusi: if you send me a mail (tfheen@ubuntu.com), I'll do it in the morning
[09:18] <psusi> ok
[09:20] <Toadstool> ping seb128
[09:21] <dholbach> Toadstool: he went away for a bit, can I help you?
[09:22] <Toadstool> that was to ask him if it is possible to create an ubuntu-l10n-fr mailing-list, as he is the team owner
[09:22] <dholbach> Toadstool: you can ask jdub (list-super-admin) or smurf (loco super chief)
[09:23] <Toadstool> that's a little off topic here I know :/
[09:24] <dholbach> Toadstool: no it's not necessarily off-topic, but that's all I can say :)
[09:24] <Toadstool> ok :)
[09:26] <seb128> Toadstool: there is a such list already<EMAIL_ADDRESS>[09:26] <seb128> Toadstool: https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr-l10n
[09:26] <Toadstool> ah really ? I didn't find it :/
[09:26] <Toadstool> sorry :)
[09:27] <seb128> np
[09:33] <psusi> so how is this ide-generic problem not a bug in the sata driver?  if the sata driver detects the controller, then it should claim the hardware so ide-generic can't... not go ahead and talk to the controler anyhow without claiming the ports while it detects the drives
[09:33] <mjg59> psusi: It's not clear that there actually is a problem now
[09:34] <psusi> heh
[10:00] <bddebian> Yeah, ya bum :-)
[10:00] <Burgwork> some of us were up at the crack of 8:45am
[10:00] <CarlFK> installer still has problems with grub and /boot being on a raid - it should prevent that from being done, but it tries, fails and you end up with a box that won't boot.
[10:01] <bddebian> CarlFK: What kind of problem?
[10:01] <CarlFK> is this worth messing wiht, or would fixing it be... adding a feature which isn't going to happen now
[10:01] <infinity> Burgwork: Bah, it's 8:00am right now..
[10:02] <CarlFK> bddebian: grub won't install to /dev/md0
[10:02] <CarlFK> the "easy" fix would be to not allow /boot to be on a raid or lvm
[10:03] <bddebian> CarlFK: It worked fine for me on a Compaq array controller.  Though cpqarray wasn't in initramfs
[10:03] <blacking> hello dev..
[10:03] <CarlFK> this is software raid
[10:03] <bddebian> Ah
[10:03] <bddebian> Software raid sucks anyway :-)
[10:04] <CarlFK> you can make it work with some extra steps, you can get grub on a raid1, but I think that should be done outside the Ubuntu installer
[10:04] <_ion> tonio: Hi
[10:04] <tseng> putting grub on software raid isnt a great idea
[10:04] <CarlFK> yeah yeeh - I am looking for redundancy, not performance
[10:04] <tseng> if its possible at all
[10:04] <tseng> i mean, /boot
[10:04] <CarlFK> it is, you just have to trick it (which is why I dont think the installer should do it)
[10:04] <tseng> the mbr obviously isnt in software raid
[10:05] <CarlFK> as long as hda1/boot and md0/boot are the same thing, (which they are in raid1) the it will work
[10:05] <CarlFK> for the mbr, you just install it to hd0 and hd1
[10:05] <tseng> thats pretty gross
[10:06] <CarlFK> one you get it all setup, you can pull any drive and it will still boot
[10:06] <CarlFK> agreed
[10:06] <_ion> But it works. :-)
[10:06] <Tonio_> _ion: heard you were asking for me today ?
[10:06] <CarlFK> it would be nifty if the installer would do it all, but for now I think it should just prevent you from even trying
[10:06] <_ion> tonio: Yep. Did you get my email? I sent some updates to the n-m package last night.
[10:07] <CarlFK> but if the "prevent from trying" isn't going to happen for dapper, I wont bother with it now
[10:07] <blacking> is it possible install ubuntu onto an usb drive ppc filesystem?
[10:07] <_ion> tonio: Would it be possible for me to get write access to the repository? I could send updates and also sign the repo.
[10:08] <CarlFK> so back to my question - how does "prevent from trying" relate to feature freeze?
[10:08] <Pygi> _ion: he got the updates...
[10:08] <Tonio_> _ion: hum, yes of course :)
[10:09] <Tonio_> _ion: but we removed the signing function
[10:09] <Tonio_> _ion: honnestly, that's not really usefull for a testing one
[10:09] <Tonio_> _ion: apart from the patches, do you have others modifications to apply ?
[10:10] <Pygi> Tonio_: please drop that patch I've gave you in kubuntu-devel
[10:10] <LaserJock> blacking: like I said before try #ubuntu or lets keep our conversation in #ubuntu-docs. This really isn't an support channel
[10:10] <Tonio_> Pygi: why ?
[10:10] <Pygi> Tonio: or perhaps ... fix the patch?
[10:10] <_ion> tonio: Nothing new since my last email.
[10:10] <Tonio_> I found the problem :)
[10:10] <Pygi> well, the package refuses to build?
[10:10] <Pygi> ah,kk
[10:11] <Pygi> great ;)
[10:11] <dholbach> good night guys
[10:11] <Tonio_> _ion: well, if you have any modification to apply, ask me foor ftp access, the repo is auto updated every 15 minutes
[10:11] <Pygi> night dholbach
[10:11] <Tonio_> dholbach: nite ;)
[10:11] <dholbach> *wave*
[10:12] <_ion> tonio: The behavior of the /etc/network/interfaces blacklist thing should be modified somewhat, i'll do that maybe tomorrow.
[10:13] <_ion> pygi: Btw., i have updated http://johan.kiviniemi.name/ubuntu/nm-bugs
[10:13] <mdke> jdub, "fascist proxy"? It's for my own good *hugs proxy*
[10:16] <mdke> jdub, as for 'cocksmoking', I have no idea. We should test it.
[10:16] <_ion> tonio: Oh, i just noticed your mail. If the package version in the repository stays the same even though it's updated, nobody will get the updates when apt-get upgrading.
[10:17] <_ion> tonio: That's why used -0ubuntu0.$X style version numbers for development. That < -0.ubuntu1 which would be the first "official" Ubuntu package version.
[10:18] <Tonio_> _ion: if md5sum changes, you still get updates :)
[10:18] <Tonio_> no problem with this
[10:18] <Kamion> Mithrandir: I haven't retargeted it; please do
[10:19] <Mithrandir> Kamion: 'k, I'll just have to find my desk first.
[10:19] <Mithrandir> (it's buried under a pile of paper)
[10:20] <_ion> tonio: Oh. I didn't know that. I thought apt-get only upgrades packages if the package's version number is increased.
[10:21] <Tonio_> _ion: I thought too before testing this a few month ago :)
[10:21] <_ion> :-)
[10:21] <Tonio_> _ion: I'm trying to apply a patch
[10:21] <Tonio_> but fails for a strange reason
[10:21] <psusi> apt-get does only upgrade packages if the package's versionn number is increased, which is why we use -0ubuntu1 for packages that aren't in debian
[10:21] <Tonio_> _ion: I'm not espacially a coder, which you seem to be more than me ;) can you have a look ?
[10:22] <_ion> tonio: Sure.
[10:22] <Tonio_> psusi: well, when I'm changing the package on my personnal repo, without changing the version name, it works.....
[10:22] <psusi> and why upstream beta packages are named like foo-0.99+1.00beta3
[10:22] <Kamion> psusi: that's not quite correct; it will upgrade if the version number stays the same but something else about the package changes
[10:22] <Tonio_> psusi: I'm doing that for tests since months
[10:22] <Kamion> psusi: it will not upgrade if the version number *decreases*
[10:23] <psusi> oh... right.... if it stays the same..
[10:23] <Tonio_> _ion: http://mail.gnome.org/archives/networkmanager-list/2006-January/msg00141.html
[10:24] <Tonio_> _ion: two patches possible, but the first one causes problems, cause will need to be changed if madwifi is updated....
[10:24] <Tonio_> _ion: I'm trying to apply the second one, but build fails....
[10:24] <Tonio_> there should be something to change or add, but I can't do that myself :)
[10:25] <_ion> tonio: Ok, i'll try to fix+apply it tomorrow.
[10:25] <Tonio_> _ion: thanks very much ;)
[10:25] <_ion> np. :-)
[10:26] <Tonio_> _ion: when you put my name, can you plz you tab ? because I will not see you pinged me when another channel ;) the icon will not blink
[10:26] <Tonio_> tonio vs Tonio_ ^^
[10:26] <_ion> tonio_: I have binded the tabulator to another purpose. :-)
[10:26] <_ion> tonio_: Maybe /hilight tonio
[10:26] <Tonio_> _ion: ah ? ;)
[10:27] <Tonio_> k
[10:27] <_ion> For example i have /hilight -regexp \<ion
[10:27] <_ion> So this hilights "ions" but not "lion".
[10:27] <_ion> In irssi.
[10:28] <Tonio_> I'm not using irssi, I prefer graphical tool like konversation for IRC ;)
[10:28] <_ion> Ok. It probably has a similar feature.
[10:29] <Tonio_> but I will make a highlight rule for this, no pb :)
[10:29] <Tonio_> it can of course ;)
[10:30] <_ion> tonio: Could you rename the knetworkmanager package as network-manager-kde, btw.?
[10:31] <_ion> Oh, i forgot the _ again. :-)
[10:32] <Tonio_> _ion: hehe
[10:32] <Tonio_> _ion: we should get the latest source version by the end of the week, I'll apply the changes then :)
[10:32] <_ion> Ok, thanks.
[10:33] <Tonio_> _ion: already on my TODO list
[10:35] <pitti> fabbione: oh, btw, I reviewed git-core today
[10:35] <pitti> fabbione: http://wiki.ubuntu.com/MainInclusionReportGitcore, it needs a security fix
[10:45] <Keybuk> Mithrandir: what kind of seeding of /etc/iftab do we do on the Live CD ?
[10:45] <Keybuk> sivang: ping
[10:46] <Mithrandir> Keybuk: none
[10:47] <Keybuk> Mithrandir: ok.  as long as it's "none" or "the same as netcfg" that's fine
[10:47] <Mithrandir> Keybuk: casper at least doesn't touch iftab
[10:47] <Keybuk> yeah, there's no reason that it should; we seed it in the installer so the installer and real system have roughly the same idea about network card order
[10:48] <Keybuk> as there's no installer component to the live cd, I wouldn't expect that to be necessary
[10:48] <Mithrandir> agreed.
[10:48] <Keybuk> and we ship n-m by default on the live anyway
[10:48] <Keybuk> so it doesn't particularly matter whether they change orders
[10:48] <sivang> Keybuk: pong
[10:49] <Keybuk> sivang: 100 lines of "I shall not patch debian/* in debian/patches" on my desk by the morning please
[10:49] <sivang> did I do that?
[10:49] <Keybuk> yes, initscripts
[10:50] <Keybuk> syndicate sysvinit-2.86.ds1% diffstat -p1 debian/patches/100_mountall_fix_output.dpatch
[10:50] <Keybuk>  debian/initscripts/etc/init.d/mountall.sh |    4 ++--
[10:50] <sivang> Keybuk: how many copies of that punishment paper?
[10:50] <_ion> tonio, pygi: Currently the blacklisting works this way: if (interface NOT listed in /etc/network/interfaces) { blacklist = FALSE } else if (interface is "auto" and "inet dhcp") { blacklist = FALSE } else { blacklist = TRUE }. mjg59 proposed it would be changed to: if (interface IS listed, and IS "auto") { blacklist = TRUE } else { blacklist = FALSE }. Do you agree? (I do.)
[10:50] <Keybuk> just the one <g>
[10:51] <sivang> Keybuk: okay, other that that, will a fixed source help?
[10:51] <Keybuk> _ion: that would reverse the blacklist
[10:51] <_ion> tonio, pygi: Should i modify the patch to work that way?
[10:51] <Keybuk> which would be wrong
[10:51] <Keybuk> sivang: s'ok, I'm uploading a new one anyway
[10:51] <Tonio_> _ion: sounds good said like that, yes
[10:51] <Pygi> _ion: lemme check, sec pls
[10:52] <_ion> keybuk: Why should it work the way it does now?
[10:52] <sivang> Keybuk: bah so sorry, /me takes a mental note not to work on critical packages after the pm has switched to pm
[10:52] <Keybuk> _ion: because the way it works now is "a device is blacklisted if there is manual configuration for it"
[10:52] <Keybuk> you're proposing doing the exact opposite
[10:52] <sivang> that jsut proved what I said :) s/pm$/am/
[10:52] <Keybuk> auto *; iface * inet dhcp; is "automatic" configuration
[10:52] <sivang> Keybuk: thanks btw :)
[10:53] <_ion> keybuk: Someone might want to let n-m manage the interfaces at the workplace and run "ifup eth0" at home with "inet static" configuration.
[10:53] <Keybuk> _ion: explicitly out of spec for dapper
[10:53] <Keybuk> the spec in fact says we won't support that
[10:53] <Keybuk> to support that without ignoring a user's attempts to stop n-m running on an interface requires changing ifupdown
[10:54] <pitti> hi zyga
[10:54] <_ion> keybuk: Ok, i won't touch the patch.
[10:54] <Keybuk> for dapper+1 I actually quite fancy getting rid of ifupdown entirely
[10:54] <zyga> pitti: hey :-)
[10:54] <Tonio_> Keybuk: hum, yes, that's right
[10:54] <Keybuk> and instead applying the logic that all interfaces are brought up with DHCP unless explicitly stated otherwise
[10:54] <HrdwrBoB> n-m has worked perfectly for me with the exception of the airo driver biting it
[10:54] <zyga> pitti: do you happen to know if flight 5 has broken installer?
[10:54] <zyga> ppc version doesn't see any partitions on my disk
[10:54] <pitti> zyga: I doubt it :)
[10:55] <Tonio_> HrdwrBoB: I think that's a known issue
[10:55] <Tonio_> HrdwrBoB: many users complaining with the airo driver
[10:55] <Pygi> Tonio_: yes, it is ...
[10:55] <zyga> pitti: which version of OS X do you have?
[10:55] <pitti> zyga: the flights are tested on all platforms, so while there are certainly bugs, it's not broken for everyone
[10:55] <HrdwrBoB> Tonio_: airo drive has been dodgy since forever, it used to change interfaces on suspend
[10:55] <HrdwrBoB> *driver
[10:55] <pitti> zyga: uh, I don't know; the one that was current in July 2004, when I bought the machine...
[10:55] <pitti> zyga: I never use it :)
[10:55] <zyga> pitti: well I tried all possible combinations and dapper just dones't see the osx partitions (and vice versa)
[10:55] <zyga> hmm
[10:56] <zyga> strange
[10:56] <Keybuk> *sigh*
[10:56] <zyga> pitti: if you manage to boot osx someday please let me know
[10:56] <pitti> zyga: yes, that works fine
[10:56] <Keybuk> sweet
[10:56] <pitti> zyga: it never broke
[10:56] <Keybuk> SEEEEEEEEEB!
[10:56] <_ion> Patching debian/patches/* in debian/patches would be pretty. ;-)
[10:56] <HrdwrBoB> Keybuk: how would that work (f-e) on a bonded connection
[10:56] <pitti> seb128: flee!
[10:56] <HrdwrBoB> i can use ifupdown to bring up bond0, which is great
[10:57] <zyga> pitti: I'd love to run some quality tests if I knew what to look for
[10:57] <Keybuk> HrdwrBoB: you'd supply a configuration for it
[10:57] <Keybuk> HrdwrBoB: my intent is that all interfaces have *A* configuration
[10:57] <pitti> zyga: I don't know what's broken for you :)
[10:58] <Keybuk> where as at the moment some interfaces don't :)
[10:58] <HrdwrBoB> ah :)
[10:58] <Keybuk> seb128: X-Chat core dumps
[10:58] <Keybuk> if you e.g. /whois _ion :)
[10:58] <seb128> xchat or xchat-gnome?
[10:58] <Keybuk> xchat
[10:58] <seb128> I don't care about that one :p
[10:58] <zyga> pitti: installing flight 5 on ppc doesn't see existing partitions and allows to repartition the drive (only)
[10:58] <Keybuk> I'll make you care
[10:58] <Keybuk> with a spoon!
[10:58] <pitti> Keybuk: WFM
[10:58] <seb128> backtrace?
[10:59] <Keybuk> seb128: I'll get you one later when I'm not trying to do some work <g>
[10:59] <seb128> :)
[11:01] <lamont> pitti: on the subject of screwed up configs, I'd like my dapper machine (maybe 2-3 days out-of-date now...) to automount removable media.... what got trashed where, I wonder?
[11:01] <pitti> lamont: hm, I don't know a general recent breakage
[11:01] <lamont> nah - iz more breakage on my machine
[11:01] <lamont> and not particularly new
[11:01] <pitti> lamont: can you please do http://wiki.ubuntu.com/DebuggingRemovableDevices and open a bug or mail the logs to me?
[11:02] <pitti> lamont: hello, btw :)
[11:02] <Keybuk> sivang: it's after supper time, and we're clearly all bored with nothing better to do this evening
[11:02] <lamont> pitti: thanks
[11:02] <lamont> and yeah, hello there.
[11:03] <lamont> pitti: that'll be in several hours, fwiw
[11:06] <sivang> Keybuk: fine by me, as long as I was included in the happening :)
[11:21] <zyga> night guys :-)
[11:21] <zyga> have fun
[11:23] <Burgwork> Gwynn, please turn off your public away messages
[11:24] <Gwynn> burgwork: done, sorry
[11:24] <Burgwork> Gwynn, no problems, thanks
[11:31] <Keybuk> man, I love /dev/raw1394
[11:31] <Keybuk> it's my all-time favourite device
[11:32] <sivang> fast ?
[11:32] <Keybuk> muahahaha
[11:32] <Keybuk> sivang: it's equivalent to inventing a "/dev/usb" device
[11:32] <desrt> erm
[11:32] <Keybuk> that lets you read and write whatever you like to any connected usb hub or device
[11:32] <desrt> doesn't kino, etc require raw1394 access?
[11:33] <Keybuk> and even better, the Firewire spec allows devices to execute code on the host system in a privileged state
[11:33] <sivang> oh oh goody
[11:33] <desrt> how does that work, exactly?
[11:33] <desrt> some bytecode or does it send native x86 and hope for the best?
[11:33] <Keybuk> desrt: yes, see all the "why raw1394 owned by root/root and not root/video" bugs
[11:34] <sivang> I thought it was only for trasnferring data as on USB devices, but in outrageous speeds
[11:34] <Keybuk> bytecode I think, a bit like ACPI
[11:34] <desrt> wonky
[11:34] <desrt> have you see the firestarter demo?
[11:34] <Keybuk> sivang: no, because there's just one /dev/raw1394 device for the entire stack
[11:34] <Keybuk> where as with USB, we have /dev/usb/XXX/YYY - one device for each real device
[11:35] <sivang> yes, I see.
[11:35] <desrt> someone wrote this demo for macosx
[11:35] <desrt> it shows a burning fire on your screen
[11:35] <sivang> Keybuk: so how do you tell one device from the other ?
[11:35] <desrt> if you plug such a computer into any other mac via firewire then the fire spreads
[11:35] <sivang> (when there's more the one connected)
[11:36] <Keybuk> sivang: I've no idea, I guess that's what lib1394 is for
[11:36] <Keybuk> it's evil
[11:36] <sivang> heh , if it knows to do things like that, it must be :-)
[11:37] <HiddenWolf> Keybuk: ping
[11:40] <Keybuk> heh
[11:40] <Keybuk> join, ping, quit
[11:41] <Burgwork> Keybuk, evidentally it was not that important
[11:41] <Keybuk> indeed
[11:44] <Keybuk> HiddenWolf: you rang?
[11:44] <HiddenWolf> Keybuk: yes I did. Got a minute?
[11:44] <stewart> hi guys anyone know if there is a bug for hauppage tv cards in flight5
[11:45] <Keybuk> HiddenWolf: always
[11:45] <HiddenWolf> Keybuk: I'm confused about https://launchpad.net/distros/ubuntu/+source/udev/+bug/29789
[11:45] <Ubugtu> Malone bug 29789 in udev "tv card audio not working" [Wishlist,Needs info]
[11:45] <Keybuk> HiddenWolf: right
[11:45] <HiddenWolf> Keybuk: I've tried all sorts of blacklist combinations, but I keep having to manually modprobe to get audio for my card.
[11:45] <Keybuk> ok, so let me explain a bit how module loading works
[11:46] <Keybuk> for each device on your system, the kernel generates a string that looks a bit like pci:v1834d09214... etc.
[11:46] <Keybuk> for each driver, depmod generates a string that looks the same, but with wildcards in
[11:47] <stewart> under flight 3 my hauppage bt484 (I thnk) worked out of the box on a fresh flight 5 tvtime is not seeing it
[11:47] <Keybuk> modprobe can be given the first string, and match it against all the wildcard ones (in /lib/modules/*/modules.alias)
[11:47] <Keybuk> and thus get a list of modules to load
[11:47] <Keybuk> sometimes there may be two conflicting answers
[11:47] <Keybuk> the common example is where a soundcard is supported by OSS and by ALSA
[11:47] <Keybuk> so you can blacklist one of them
[11:48] <Keybuk> blacklisting means that when performing alias expansion, modprobe will ignore that one module
[11:48] <Keybuk> ok
[11:48] <stewart> ok wait a min mines a bt878
[11:48] <Keybuk> so for your tv card, there are two answers
[11:48] <Keybuk> snd_bt87x (ALSA) and bt878 (OSS)
[11:49] <Keybuk> and a cute bug where snd_bt87x won't work if bttv has been loaded first
[11:49] <Keybuk> bttv is a dependency of bt878
[11:49] <stewart> device manager is finding it just not tvtime
[11:49] <Keybuk> syndicate scott% modinfo bt878 | grep depends
[11:49] <Keybuk> depends:        bttv
[11:49] <Keybuk> unfortunately both of these drivers support a different set of devices; so we don't blacklist one or the other
[11:50] <Keybuk> and I think your card needs both loaded anywa
[11:50] <Keybuk> now, if you load them in the order
[11:50] <stewart> how come the no probs under flight 3? or are you talking to the other guy
[11:50] <HiddenWolf> seems like it.
[11:50] <Keybuk> snd_bt87x, bt878
[11:50] <Keybuk> things work
[11:50] <Keybuk> if you load them in the other order
[11:50] <Keybuk> things don't work
[11:51] <Keybuk> stewart: kinda talking to both of you; specifically answering HiddenWolf but delightfully this is your problem too <g>
[11:51] <HiddenWolf> :)
[11:51] <Keybuk> now blacklisting isn't actually useful here
[11:51] <stewart> :-)
[11:51] <Keybuk> because bttv is loaded by the dependency mechanism, blacklists aren't consultled
[11:51] <Keybuk> and there's no way to force modules to be loaded in a particular order
[11:51] <Keybuk> in fact, we've avoided creating on etoo
[11:51] <Keybuk> because it would still cause problems if you had two different cards
[11:52] <stewart> so this isnt a change from flight 3?
[11:52] <Keybuk> we think (and BenC - our kernel maintainer agrees) that it's a bug in the bttv driver
[11:52] <Keybuk> I'm not aware of any changes from flight 3 to 5, unless we have a different selection of modules
[11:52] <stewart> darn I was hoping to have some useful feedback for you :-(
[11:53] <Keybuk> stewart: there isn't anything useful other than a "this is what we know at this point"
[11:53] <Keybuk> we know it's a bug
[11:53] <HiddenWolf> Keybuk: was afraid of that.
[11:53] <Keybuk> we think it's a kernel driver bug
[11:54] <HiddenWolf> Keybuk: so it should be reassigned.
[11:54] <Keybuk> I just did that
[11:54] <stewart> thats cool then guys Im not chasing my telly just wanted to make sure you'd heard of it
[11:54] <HiddenWolf> I'm guessing it stands a good chance of being a dapper+1 bug?
[11:55] <stewart> you dont think its fixable for dapper?
[11:55] <Keybuk> it's "fixable for dapper" if a fix comes along
[11:55] <Keybuk> we're certainly a couple of months out from kernel freeze
[11:56] <HiddenWolf> *chuckle* No kiddin. :)
[11:56] <Keybuk> however we have no direct in-house experience of this, and it's not something that's ever worked anyway (ie. not a regression from breezy)
[11:56] <HiddenWolf> Hey, hold on, it worked since warty!
[11:56] <HiddenWolf> ;)
[11:56] <Keybuk> it did?  that's probably sheer fluke <g>
[11:56] <stewart> thats a shame when I saw dapper (flight3) with ootb v4l on my card I thought it would be cool addition
[11:57] <HiddenWolf> heh
[11:57] <Keybuk> the best way to get it fixed would be to get the kernel upstream to look into it
[11:57] <stewart> well on breezy I had to mess with module loading
[11:57] <Keybuk> and that way if a patch appears, we can merge it into our kernel repository
[11:57] <Keybuk> stewart: you can mess with module loading now
[11:57] <stewart> but flight 3 worked both sound an vid straigh away
[11:57] <HiddenWolf> Someone should set up a good website with supported hardware for dapper, just to tell me what hardware to buy. :)
[11:57] <stewart> yup
[11:58] <Keybuk> echo snd_bt87x >> /etc/mkinitramfs/modules
[11:58] <Keybuk> update-initramfs -u
[11:58] <Keybuk> (bit of an evil hack, but it works)
[11:58] <stewart> well if you're after an mp3/ogg player samsung yp just works
[11:58] <HiddenWolf> Keybuk: heh
[11:59] <Keybuk> or, less evil
[11:59] <Keybuk> echo blacklist bt878 > /etc/modprobe.d/blacklist-bt878
[11:59] <Keybuk> echo bt878 >> /etc/modules
[11:59] <Keybuk> (blacklist bt878 from auto-loading, but then load it later)
[12:00] <HiddenWolf> i'll remember taht
[12:00] <HiddenWolf> that, even
[12:01] <HiddenWolf> Well, that takes care of one of Dapper's annoyances.
[12:01] <stewart> is that the same issue as mine
[12:01] <Keybuk> stewart: as far as I know
[12:01] <stewart> mines not a sound issue
[12:02] <Keybuk> what's your issue?
[12:02] <stewart> tvtime doesnt see any tuner


[06:37] <cpaelzer> just stumbled over https://github.com/virt-manager/virt-manager/commits/cloudinit
[06:37] <cpaelzer> is that known or something you want to help with?
[10:34] <tribaal> blackboxsw: for the record: I built and booted an Eoan template with 19.2-13-g2f3bb764-0ubuntu1 on our preproduction environment, and all seems well :)
[13:33] <Odd_Bloke> tribaal: \o/
[13:36] <Odd_Bloke> cpaelzer__: I'm not aware of it, but it looks cool!  What help could we offer?
[13:36] <Odd_Bloke> (If you know!)
[13:45] <tribaal> I guess we're ready to have Eoan available on day one :P
[14:33] <cpaelzer> Odd_Bloke: I don't know what they work on or woudl need right now
[14:33] <cpaelzer> I just have seen the branch while cloning virt-manager for a fix
[14:33] <cpaelzer> and wondered if that is part of a community activity that you'd know of
[14:33] <cpaelzer> interesting ...
[14:34] <cpaelzer> waiting if rharper doesn't know it either ...
[14:40] <rharper> it's new to me as well; looks like virt-install adding support for installing their cloud images by prepping some in-image cloud-init ;
[16:58] <blackboxsw> Odd_Bloke: rharper Steve's suggestion to use debconf-loadtemplate adds a dependency on debconf-utils that cloud-init doesn't currently have. That adds about 57K of packages if we made this strict package dependency.  Would we want to avoid adding this package unless someone specified ubuntu-drivers cloud-config?
[16:58] <rharper> blackboxsw: let's check in #ubuntu-devel with vorlon for alternatives/thoughts
[16:59] <blackboxsw> sounds good
[17:10] <mator> hello
[17:10] <mator> how do i install a cloud-init server, not instance? for example, i have kvm server for vm deployment and want to use cloud init for cloud images VMs
[17:12] <mator> besides of .iso images with cloud file metadata settings, is there network way to init vm ?
[17:36] <rharper> mator: hi,  I'm not sure that I understand your questions; but it sounds like you'd be interested in Ubuntu cloud-images[1], which are Ubuntu server images with cloud-init already installed.  And if you aren't running these images on a cloud, you'll want to learn to use cloud-init's NoCloud datasource[2], which allows cloud-init to find configuration on secondary devices (like a cdrom);   1. http://cloud-images.ubuntu.c
[17:36] <rharper> om/daily/server/bionic/current/ 2. https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[18:59] <Odd_Bloke> rharper: blackboxsw: https://write.wrestle.town/oddbloke/dracut-findings-for-cloud-init <-- your thoughts would be appreciated
[19:58] <blackboxsw> Odd_Bloke: if we were to go down the route of extending dracut to emit a more friendly/standardized network configuration instead of cloud-init growing the ability to parse dracut's config, what is the  possibility that we have issues upstreaming dracut fixes for cloud-init if needed? If we have issues with dracut upstream, I'm not certain what *we* would do to host our own official yum repo, other than our dev
[19:58] <blackboxsw> copr repos
[19:59] <blackboxsw> with the option of  cloud-init proper growing dracut-parsing logic, we control the publishing of that feature, so if we have bugs, we can be certain that we fix them quickly and fast-track public releases of cloud-init that can cope
[20:02] <Odd_Bloke> blackboxsw: We won't be able to push any dracut changes back into the releases that people actually care about, I don't think.
[20:04] <Odd_Bloke> Getting dracut to emit v2 network YAML would be very nice, but we'd only be able to glean the benefits in several years, really.
[20:04] <Odd_Bloke> So we need something to bridge that gap.
[20:07] <blackboxsw> ohh /me misread "2. implement parsing in the dracut initramfs code"   as implementing it in dracut package.
[20:07] <Odd_Bloke> Ah, yes, that's confusing wording.
[20:07] <Odd_Bloke> Let me fix that up.
[20:08] <Odd_Bloke> blackboxsw: Is that clearer?
[20:09] <blackboxsw> +1 Odd_Bloke
[20:09] <Odd_Bloke> Thanks for the catch!
[20:10] <blackboxsw> I'd agree with path 2. Odd_Bloke until we have more use cases
[20:10] <blackboxsw> s/catch/getting confused myself/
[20:10] <Odd_Bloke> :)
[22:49] <blackboxsw> Odd_Bloke: rharper for tomorrow: just put up ubuntu-drivers v2 https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371546
[23:02] <rharper> blackboxsw: cool