[12:04] <Kamion> yes, there's a known bug about vmware disks IIRC
[12:08] <tepsipakki> which is a trivial fix
[12:09] <tepsipakki> s/fix/to fix/
[12:09] <tepsipakki> s/a // ;)
[12:18] <wasabi_> Curious: /etc/sudoers has $admin in it by default.
[12:18] <wasabi_> %admin I mean.
[12:18] <Kamion>  o mysql-client-4.1 mysql-server-4.1                          {mysql-dfsg-4.1}
[12:18] <Kamion> infinity: ok to demote to universe?
[12:18] <wasabi_> admin is uid 1000, there is also a group admin with gid 1000.
[12:18] <wasabi_> This was the first group I created during install.
[12:18] <Kamion> wasabi_: admin's only a uid if the initial user you create is called 'admin'
[12:18] <Kamion> which is a bit of a corner case :)
[12:18] <wasabi_> Ahhhh.
[12:18] <wasabi_> I was wondering if %bob would be in there in the case of that.
[12:18] <Kamion> I didn't expect anyone to do that ...
[12:19] <tseng> % denotes a group
[12:19] <wasabi_> My first (and only) user is always admin.
[12:19] <Kamion> hmm, that's pretty awkward to work around
[12:19] <wasabi_> adm seems more appropiate.
[12:19] <Kamion> I think I might just ignore it, it produces essentially the same result in your case anyway
[12:19] <wasabi_> %adm in there.
[12:19] <Kamion> no, adm is for viewing log files, it just has a crap name
[12:19] <wasabi_> Ahh.
[12:19] <wasabi_> Well hell.
[12:20] <Kamion> we went through all the possibilities when we introduced the admin group, and none of the existing groups seemed suitable
[12:20] <wasabi_> I'd be all right with establishing a default admin group in a system gid range.
[12:20] <Kamion> there is one
[12:20] <wasabi_> You introduced the group?
[12:20] <wasabi_> oh I just create the admin user.
[12:20] <wasabi_> What's the gid supposed to be?
[12:20] <Kamion> it just gets created after user creation
[12:20] <Kamion> adduser --system, no fixed gid
[12:20] <wasabi_> Hmm. So mine is 1000 because my user was named admin
[12:20] <Kamion> if an admin group already exists as a result of initial user creation, the system group won't get created
[12:20] <wasabi_> Ahh.
[12:20] <wasabi_> I see. That works out.
[12:20] <Kamion> I think that's better, it fails more gracefully in your case
[12:21] <wasabi_> Yeah.
[12:21] <wasabi_> I am now clear!
[12:21] <Kamion> in general we try to use adduser rather than fixed ids
[12:21] <wasabi_> Yeah, I follow.
[12:21] <wasabi_> I wish there was some way to prevent clashes in distributed user bases.
[12:21] <wasabi_> MS figured it out.
[12:21] <Kamion> theoretically most of the existing fixed ids can be phased out, but I haven't had the stomach for the necessary combo base-passwd / adduser hacking yet
[12:22] <Keybuk> there's probably a good wine for that
[12:23] <wasabi_> At some point in the future can we stop with this too: admin:x:1000:1000:Administrator,,,:/home/admin:/bin/bash
[12:23] <wasabi_> ,,,
[12:23] <Keybuk> I get asked silly questions from strangers in Tescos ... "which wine is good for chicken?"  "which wine is good for beef?"  "which wine is good for hacking on console-tools?"  etc.
[12:23] <wasabi_> Haha.
[12:24] <daniels> wasabi_: er, you do know what gecos is, right?
[12:24] <wasabi_> Nope. ;)
[12:26] <Kamion> wasabi_: try chfn
[12:26] <wasabi_> Oh. Heh.
[12:27] <Kamion> the fifth field of passwd is the gecos field and contains several comma-separated components
[12:27] <Kamion> Treenaks: brief description of promotion/demotion and main inclusion reviews now in DeveloperResources
[12:29] <wasabi_> Is it just me or is /var/run/nscd missing by default?
[12:29] <wasabi_> Nope, not just me.
[12:52] <schlomo> Hi sorry to bother you
[12:53] <schlomo> it's possible to load fglrx in 2.6.12-9-386 breezy ? *ERROR* Unable to the open some already present DRM kernel module! when load fglrx with modprobe
[12:54] <schlomo> I have to update kernel ? it's a known problem ?
[12:54] <schlomo> it's not possible sorry
[12:56] <schlomo> didn't find anything on bugzilla
[01:23] <infinity> Kamion: Yessir.  Demote away.
[01:27] <Kamion> infinity: done
[01:34] <StevenK> Oh crap.
[01:34] <StevenK> infinity: Look at jnethack on amd64!
[01:35] <StevenK> infinity: It's been reported as a Debian bug, too.
[01:36] <infinity> StevenK: Don't wanna! :)
[01:36] <infinity> StevenK: (Will look at it in just a bit, after I've settled into my morning routine)
[01:36] <daniels> mkfontdir segfaults
[01:36] <StevenK> Who has access to keyring RT? I've sent an e-mail to it, and the reply quoted my e-mail saying "This has no content"
[01:37] <StevenK> daniels: It seems that bdftopcf is throwing out crap mkfontdir can't understand, from my (limited) investigation.
[01:37] <daniels> score
[01:39] <swat_> hi guys, anyone about who knows about gstreamer/rhythmbox. i'm trying to figure out if i am experiencing a bug, or just something gone bad on my machine
[01:39] <HiddenWolf> swat_: cvs snapshot that dapper uses isn't fully ported yet.
[01:40] <swat_> HiddenWolf: i see - it could be a gstreamer problem though. basically if i tell it to play using my internal card on my laptop the standard intel one, all is fine. if i give it the usb creative card, it bombs out and goes mental
[01:40] <swat_> if this is to be expected at this stage of development fair enough, i was just wondering if it was worth filing a bug report for
[01:41] <HiddenWolf> swat_: please do.
[01:41] <swat_> it wasn't a problem in hoary, so i assume it is some sort of issue - rather than not being supported
[01:43] <HiddenWolf> swat_: new kernel, hotplug to udev transition, there has been messing with the default sink, and the gstreamer 0.8 -> 0.10 thing. It can be a lot of things.
[01:43] <swat_> so i should submit a bug to the rhythmbox thing anyway
[01:43] <swat_> and it'll get bounced around one assumes
[01:44] <HiddenWolf> right
[01:55] <dholbach> elmo: can you please remove evolution-caldav from Dapper?
[02:15] <daniels> elmo: fyi, x11-common should go into main, and when it does, xorg-common and xserver-common should be melanied
[02:16] <elmo> daniels: k
[02:18] <HiddenWolf> debian takes legality dead-serious. :/
[02:19] <HiddenWolf> Software. Daniel Carrera [23] wondered how he is
[02:19] <HiddenWolf> supposed to fulfil the source code requirement of the GNU [24] GPL when
[02:19] <HiddenWolf> he is handing out OpenOffice.org CDs during an exhibition. Andrew
[02:19] <HiddenWolf> Suffield [25] explained that the easiest way is to prepare copies of
[02:19] <HiddenWolf> the source and give them to anybody who asks for them.
[02:19] <HiddenWolf> odm
[02:19] <HiddenWolf> isn't that a bit, ehm, zealous?
[02:21] <daniels> argh
[02:21] <Kamion> people do get asked for source code when handing out CDs at exhibitions
[02:21] <Kamion> at least occasionally in the context of whether they're meeting licence requirements
[02:21] <Kamion> it's a lot easier to have your answer prepared than to be stumped
[02:22] <HiddenWolf> Shouldn't it be enough to have your awnser "sourcecode is published at XYZ location" ?
[02:23] <HiddenWolf> If it isn't, than isn't shipit in violation of the gpl?
[02:23] <Kamion> shipit includes a written offer last I checked
[02:24] <Kamion> (which I don't think anyone's ever taken up ...)
[02:24] <azeem> it does
[02:24] <Kamion> you have to either (a) accompany binaries with source (b) include written offer (c) if non-commercial, pass on the offer of source you received
[02:25] <Kamion> when I've handed out Debian CDs at exhibitions at the past, we went for (b)
[02:25] <Kamion> but that does require having a contact address of somebody willing to mail out CDs
[02:25] <Kamion> just pointing them to a web archive isn't sufficient, IIRC, because you can assume that a fair proportion of people who are wanting to get CDs from you rather than do the download themselves won't have the bandwidth to download the source either
[02:27] <Kamion> I'm not *entirely* sure the GPL says that straight out but it seems reasonable behaviour
[02:28] <daniels> i thought there was some form of media restriction on the source offer
[02:28] <daniels> being that you have to at least make it available through the same medium
[02:29] <daniels> but I could be mistaken
[02:29] <Kamion> "on a medium customarily used for software interchange"
[02:29] <Kamion> I think you could argue convincingly that archive.ubuntu.com plus the Internet is such a medium
[02:29] <Kamion> (e.g.)
[02:30] <Kamion> but I'm not sure everyone actually agrees with me there, so shrug
[02:30] <dholbach> night guys.
[02:30] <daniels> dude, we don't use the interweb for anything
[02:30] <daniels> night dholbach
[02:30] <Kamion> the last paragraph of GPLv2 section 3 does suggest that access to copy from a designated place is not quite the same as distributing on a medium, though
[02:31] <Kamion> so, whatever; it's easy enough to comply with the strictest reading in case anyone asks, and it makes the odd person happy and saves you aggro
[02:34] <ds> imo, it should be thought of as an honor to be able to have source CDs for people
[02:39] <Kamion> we kick out source CD images as part of our daily CD image build process
[02:39] <Kamion> (yes, we have been asked for them, too)
[02:40] <HiddenWolf> daniels: nice changelog on xorg. :)
[02:42] <HiddenWolf> daniels: xlibs-dev description: pac -> package
[02:45] <daniels> (oops)
[02:48] <infinity> daniels: Any urge to look at the mkfontdir 64-bit hatred?
[03:16] <tseng> infinity: awakeish?
[03:19] <infinity> tseng: Maybeish.
[03:19] <tseng> infinity: hardware detection on my desktop flight 3 install is pretty bunk, i seem to remember you are the guy
[03:19] <daniels> infinity: i'd be lying if I said yes
[03:19] <womble> Burgundavia: Go for it.  Please.  <grin>
[03:19] <daniels> infinity: i'll check it out if I get time after looking at a few xorg issues
[03:20] <infinity> tseng: Keybuk is the guy, actually.
[03:20] <tseng> ah, well its past his bedtime
[03:20] <infinity> tseng: Define "bunk".
[03:20] <tseng> its not loading modules
[03:20] <tseng> in single user, my nic module is not loaded for example
[03:21] <tseng> in a normal boot X goes totally bonkers and displays garbage on my dvi, seemingly hung
[03:21] <tseng> so not much clue from that angle yet
[03:21] <jdub> Burgundavia: i don't think that would be inappropriate
[03:22] <tseng> a startx in single user says "you have no devices, jackass!"
[03:22] <Burgundavia> jdub, yes, that is why I didn't do that
[03:22] <infinity> tseng: Hrm, S10udev is meant to catch all the devices that didn't get loaded in the initramfs.
[03:22] <jdub> Burgundavia: or backwards -> i think it would be appropriate
[03:22] <HiddenWolf> jdub: double denial is always tricky. :)
[03:22] <infinity> tseng: You'll definitely want to either file a bug or talk to Keybuk directly though.
[03:23] <tseng> infinity: indeed.
[03:23] <Burgundavia> HiddenWolf, jdub, gahhh! I give up
[03:23] <HiddenWolf> tseng: make startx sign the code of conduct. :)
[03:28] <LaserJock> what is the copyright/license for debian/* ?
[03:29] <daniels> LaserJock: generally debian/rules is licenced under the gpl (look in the file itself), and the rest isn't copyrightable
[03:29] <LaserJock> daniels: what does copyrightable mean exactly?
[03:30] <HiddenWolf> LaserJock: if you can claim copyright or not
[03:31] <LaserJock> so does that mean public domain?
[03:31] <Burgundavia> LaserJock, anything that is not copyrightable is not copyrightable. Effectively the same as PD
[03:32] <LaserJock> interesting
[03:32] <Burgundavia> PD is for things which have had their copyright lapse, but they are still technically under copyright
[03:32] <daniels> if I write 'the grass is green', that doesn't deserve copyright protection
[03:32] <HiddenWolf> daniels: not? ;)
[03:32] <daniels> HiddenWolf: ?
[03:32] <HiddenWolf> daniels: joke.
[03:32] <Burgundavia> daniels, that is debatable, depending on the country
[03:33] <Burgundavia> basically, you need to demonstrate that you actually did something
[03:33] <HiddenWolf> Burgundavia: of course you can claim copyright, to get it is a different story.
[03:33] <LaserJock> but packaging is a lot of work so I'm not sure why it would be non-copyrightable
[03:34] <Burgundavia> LaserJock, the descriptions are copyright, probably the same license as the program, as a derived work on the main body
[03:34] <Burgundavia> scratch that
[03:35] <Burgundavia> probably gpl, as part of the packaging, as daniels said
[03:35] <HiddenWolf> LaserJock: it's a lot of work, but it is not unique, your achievement specifically, or otherwise protectable
[03:35] <HiddenWolf> LaserJock: You're doing work following a guideline, the guideline might be copyrightable, the work itself not, afaik.
[03:35] <Burgundavia> LaserJock, however, if you quoting a small piece of the work, US copyright law has a thing called fairuse. This is what reviewers use
[03:36] <LaserJock> hmm, it seems pretty unique to me but the docteam has gotten me all paranoid about licenses ;-)
[03:36] <Burgundavia> LaserJock, you should be paranoid about copyright. It can and will bite you in the ass
[03:38] <LaserJock> It just seems odd to me that we don't have to say anything about the copyright of the actual packaging when we are packaging
[04:15] <psusi> what is the right way to go about getting something included in the initrd on the install cd?  how exactly is that built up from the udebs?
[04:16] <infinity> psusi: For testing, just rebuild debian-installer with your udeb in build/localudebs
[04:16] <infinity> psusi: For the "real thing", what gets included is defined by archive priorities.
[04:17] <psusi> infinity, so building debian-installer from source installs the udebs in build/localudebs to a chroot somewhere?  then snatches the kernel and initrd out of that chroot?
[04:21] <psusi> what I'm getting at is if the udeb's postinst adds scripts to /usr/share/initramfs-tools and calls update-initramfs, that will get the right stuff into the initrd for the install cd yes?
[04:26] <infinity> Erm, no.  I'm not positive how that all works, now that d-i has moved to initramfs.
[04:29] <Burgundavia> any idea why impilinux.org.za redirects to ubuntulinux.org?
[04:29] <psusi> for that matter, why don't I see any udebs in the archive?
[04:30] <HiddenWolf> Burgundavia: isn't impilinux the distribution that sabdfl bought, that'll put a paid ubuntu deriviate translated to za languages to market?
[04:30] <HiddenWolf> I'm sure I read something about it, once.
[04:30] <Burgundavia> HiddenWolf, yes, but impi should still have it own page
[04:31] <Burgundavia> http://mybroadband.co.za/nephp/?m=show&id=828
[04:31] <infinity> psusi: Err.. I do.. (http://archive.ubuntu.com/ubuntu/pool/main/b/binutils/ is an example)
[04:32] <HiddenWolf> Burgundavia: perhaps they'll put up a new site when they are ready?
[04:32] <infinity> psusi: If you mean "why don't I see them in Packages.gz", the answer to that should be reasonably obvious.  udebs shouldn't be installed on running systems.
[04:32] <psusi> ohh... I see
[04:32] <Burgundavia> HiddenWolf, no idea, but http://www.impilinux.org/ gives me a blank page
[04:33] <HiddenWolf> Burgundavia: well, you'd expect them to use launchpad and such, but there is nothing there either, afaik
[04:33] <HiddenWolf> Burgundavia: guess it's a ghost untill it's promoted.
[04:34] <Burgundavia> HiddenWolf, I met the impi guys at UBZ
[04:35] <daniels> surprisingly, yeah
[04:35] <psusi> what kind of sense does that make?
[04:35] <psusi> don't you build only one package at a time?
[04:36] <elmo> can't be INSTALLED at the same time as that package is being built
[04:36] <HiddenWolf> Burgundavia: *shrug* Can't imagine sabdfl sinking a lot of money into something without a good plan, but I'd have no clue as to the plan.
[04:36] <psusi> ohhh... wow... weird
[04:36] <Burgundavia> HiddenWolf, personally I think Impi might just fail, but hmm...
[04:37] <Burgundavia> 3 versions, 3 different base packages does not confidence build
[04:37] <Burgundavia> 2 different DEs
[04:37] <infinity> elmo: Can you NEW neon24, please?  (Yes, this is IncreasingDuplication, go me, it should be hammered out in the next few weeks/month)
[04:37] <HiddenWolf> Burgundavia: I'd expected to see those guys active in the ubuntu world, links everywhere and such, but that hasn't happened yet. Who knows.
[04:38] <Burgundavia> HiddenWolf, one of the impi guys was in #ubuntu-motu toda
[04:38] <elmo> infinity: new for what?  main or universE?
[04:38] <infinity> elmo: main, sorry.
[04:39] <infinity> psusi: "Having this package in the build chroot completely hoses MY build" is a pretty common case, actually, but one that isn't tripped on enough (due to build chroots usually starting "clean") for people to add Build-Conflicts very often.
[04:39] <psusi> wackey
[04:40] <infinity> No.
[04:40] <infinity> psusi: udebs follow a different policy.
[04:41] <psusi> I mean for testing ;)
[04:43] <HiddenWolf> Burgundavia: *shrug* One guy, no website, big plans. Time will tell seems to be the correct saying for the matter.
[04:43] <Burgundavia> HiddenWolf, I think it is two
[04:45] <psusi> infinity, btw... you DID say you had no idea why that dmraid bug was assigned to you, and I should reassign it to fabio right?  or did I imagine that?
[04:46] <infinity> psusi: Yes.
[04:46] <psusi> good
[04:49] <Burgundavia> jdub, are there trademark issues with nUbuntu?
[04:52] <kent> regarding trademarks this seems to be a violation in some way. www.ubuntu.se  Its in english so you can read it.  Its a commersial company I think.  (given that ubuntu is trademarked and it applies to swedish law - which i think it does..)
[04:54] <Burgundavia> kent, remember that ubuntu also means something and that appears to have nothing to do with comoputers
[04:54] <Burgundavia> kent, see also ubuntu.org
[04:54] <HiddenWolf> kent: shees, what a philosophical babble. :)
[04:55] <Burgundavia> HiddenWolf, awful. All this loving stuff
[04:55] <kent> Burgundavia, ah :)
[04:55] <HiddenWolf> Burgundavia: ahaha. :)
[04:55] <kent> ahahah^2
[04:55] <Burgundavia> kent, however, nUbuntu is a derived distro
[04:55] <HiddenWolf> Burgundavia: the idea is good, but it's a tad much. :)
[04:58] <HiddenWolf> Burgundavia: read ubuntu.org
[04:58] <HiddenWolf> Canonical Go Ahead
[04:58] <HiddenWolf> Today I received an email from Canonical about using the Ubuntu name and logo. We have got permission from them to use the name "Ubuntu" and Ubuntu logo. So people having doubts about us using the Ubuntu name and logo, you can stop worrying. :)
[04:59] <Burgundavia> HiddenWolf, yes, but what are you using it for?
[04:59] <HiddenWolf> Burgundavia: I'm not using it. I just found out it existed 10min ago. :)
[05:00] <Burgundavia> HiddenWolf, where is that quote from?
[05:00] <HiddenWolf> Burgundavia: nubuntu.org
[05:00] <Burgundavia> ah
[05:00] <Burgundavia> jdub, nevermind then
[05:01] <HiddenWolf> Burgundavia: google does wonders. ;)
[05:01] <Burgundavia> HiddenWolf, I haven't checked their page is several days
[05:01] <Burgundavia> they did hit the front of digg
[05:02] <HiddenWolf> hm
[05:02] <dilinger> oh man
[05:02] <dilinger> so what on earth is udevplug actually doing in dapper?
[05:02] <dilinger> mkdir("/dev/.udev/queue", 0755)         = -1 EEXIST (File exists)
[05:02] <dilinger> nanosleep({0, 10000000}, NULL)          = 0
[05:02] <HiddenWolf> I'd rather see that energy move into ubuntu proper, but I guess it's good to have a healthy set of derivs to work with.
[05:03] <dilinger> i see *tons* of those in strace output, until finally:
[05:03] <infinity> dilinger: What's it do, or what's it supposed to do?
[05:03] <Burgundavia> HiddenWolf, sabdfl is  right about derivs
[05:03] <dilinger> nanosleep({0, 10000000}, 0)             = ? ERESTART_RESTARTBLOCK (To be restarted)--- SIGALRM (Alarm clock) @ 0 (0) ---
[05:03] <dilinger> exit_group(1)                           = ?
[05:03] <dilinger> infinity: yes
[05:04] <infinity> dilinger: It's supposed to do bus scans and generate hotplug events for coldplugged hardware.
[05:04] <infinity> dilinger: I'm not sure if that's what it IS doing for you. :)
[05:04] <dilinger> 30% of the way through the 2.5M strace file, it starts w/ those
[05:04] <dilinger> that's the entire rest of it
[05:05] <infinity> Well, I guess you've just volunteered to talk to Kebuk about it. :)
[05:05] <infinity> Keybuk, too.
[05:05] <dilinger> where is he?
[05:05] <HiddenWolf> in bed.
[05:05] <dilinger> d'oh
[05:05] <HiddenWolf> I should hope
[05:05] <dilinger> any idea what 's up w/ udev permissions, too?
[05:05] <dilinger> crw-rw---- 1 root root 1, 3 2006-01-17 22:57 /dev/null
[05:05] <infinity> dilinger: He should be around in a few hours...
[05:05] <dilinger> ok
[05:06] <HiddenWolf> dilinger: it's crack, up to you to decide if it's a good or a bad trip. :)
[05:06] <infinity> My /dev/null is fine.
[05:06] <dilinger> what's really strange is that once i added the strace to udevplug, it booted faster
[05:06] <dilinger> before, it was hanging for like 10 minutes
[05:06] <psusi> infinity, I'm getting the feeling from reading the README that localudebs/* are just tagged on to be installed during bootstrap, but won't be used for building the initramfs
[05:08] <infinity> psusi: Stuff in localudebs should end up in your mini.iso and be useable.
[05:09] <infinity> psusi: (The mini.iso is basically just isolinux, a kernel, and the d-i initrd, and not much else)
[05:09] <psusi> infinity, yea... it will end up in the iso and it will be installed by anna during the setup bootstrap, but dmraid needs to be installed when the initrd is built, and I don't think it will be if placed in there
[05:10] <infinity> psusi: Oh, I see what you're saying.  I also think you don't quite understand how d-i hardware detection works.

[05:10] <infinity> psusi: At any rate, why would you care about dmraid running RIGHT AWAY?  It just needs to run before partman.
[05:11] <infinity> psusi: Up to partman, we don't even care if we have a local disk at all.
[05:11] <psusi> the problem is most udebs are just installed by anna during the bootstrap... but dmraid has to be there when the initrd is built for it to be included... just having it installed after bootup won't work
[05:11] <psusi> because it doesn't "run" when installed anymore... I changed it to only set the initrd hooks, and it is expected to run in the initrd
[05:12] <psusi> of course... I suppose I could have the udeb built such that it runs dmraid when it is installed...
[05:12] <infinity> Fine for an installed system, probably a broken assumption for d-i.  But you'd want to talk to Kamion about that further.
[05:12] <psusi> rather than setting the mkinitramfs hooks
[05:13] <psusi> hrm... yea.. that sounds like the right thing to do... have the normal deb just set the initramfs hooks, and have the udeb just run when installed
[05:13] <psusi> because anna can load some udebs that might be required to access the hardware after the initrd stuff has already run
[05:13] <infinity> psusi: Right.
[05:14] <psusi> then again, that could be the beer
[05:14] <infinity> psusi: It will need to be run after (or as a part of) hw-detect.
[05:15] <psusi> ok... so I'm thinking it will need to be added to pkg-lists/access
[05:16] <psusi> and it's postinst should just run dmraid -ay, and the package itself should only include the executable... screw the docs and the mkinitramfs hook scripts
[05:16] <infinity> Right.
[05:16] <psusi> ok... cool... shouldn't be too hard to do..
[05:16] <infinity> And, if you can futz with the build system enough to build the binary twice, the dmraid binary in the udeb should be compiled with -Os
[05:17] <infinity> Actually, if it's meant to end up in the iniramfs on installed systems, it might not be a bad idea to just compile the whole thing -Os anyway, and only do one pass.
[05:17] <infinity> Small initrds make people happy.
[05:18] <psusi> it's usually a good idea to use -Os anyhow as half the time it generates code that runs faster as well, due to fitting in the cpu cache better
[05:18] <psusi> ;)
[05:19] <psusi> but... that is another thing I've been wondering about initrds... early on in the live of that bug, Fabio mentioned klibc...
[05:19] <psusi> as far as I can see, klibc is NOT being used in ubunutu initrds
[05:19] <infinity> It is, but so is glibc.
[05:19] <infinity> In other words, it's bloated.
[05:19] <psusi> heh, yea, having both is stupid ;)
[05:20] <infinity> I'm rewriting bits of initramfs-tools to now select one or the other, based on your installed package set.
[05:20] <psusi> so I don't see any point in klibc then
[05:20] <psusi> especially since it seems to be a general practice to statically link to it
[05:20] <psusi> I say  just put libc.so in there and everyone use it
[05:20] <infinity> (ie: we check to see if anything in your hooks requires glibc, if so, copy in the glibc-linked klibc-utils, and don't use klibc at all... If you don't need glibc, we use klibc exclusively, and get a smaller initrd)
[05:20] <infinity> That's the plan, anyway.
[05:21] <psusi> when it uses klibc, is it -shared?
[05:21] <psusi> and how much smaller is klibc.so anyhow?
[05:21] <infinity> The idea that klibc and EVERYTHING YOU MAY POSSIBLY WANT IN AN INITRD!! will be able to get along is a pipe dream we've given up on.
[05:21] <infinity> It's shared, and it's tiny.
[05:21] <psusi> like how much smaller than normal libc?
[05:21] <psusi> 5k?  25k? 1 MB? ;)
[05:22] <infinity> -rwxr-xr-x 1 root root 17020 2006-01-17 07:18 /lib/klibc-t2jM36h7OcxUNTDzncfER2p7kd4.so
[05:22] <infinity> -rwxr-xr-x 1 root root 1138716 2006-01-14 01:22 /lib/libc-2.3.6.so
[05:22] <psusi> WHOA!?!@#
[05:22] <psusi> how the hell they do that?
[05:22] <infinity> It's kinda featureless. :)
[05:23] <infinity> (or glibc is kinda feature-bloated, pick one)
[05:23] <psusi> haha, so it's not really usable then? :)
[05:23] <psusi> that's what I'm saying... is glibc just that bloated, or is klibc so stripped to the bone as to be hardly usable?
[05:23] <daniels> both
[05:23] <psusi> heh
[05:23] <infinity> It works well enough for the purpose of "tiny initrd, if you need it"  Which was the point.
[05:23] <psusi> true... if all you need in there is busybox and a few kernel modules
[05:24] <psusi> so should I then have a klibc and non klibc deb and udeb?
[05:26] <infinity> I thought dmraid and klibc didn't get along right now anyway..?
[05:26] <psusi> don't get alone?  the only thing about mixing them that I know of is it is rather stupid to add a smaller libc unless you can remove the larger
[05:27] <infinity> At any rate, for the forseeable future, we'll probabl have glibc in the initramfs, so I wouldn't bother.
[05:27] <psusi> ok
[05:28] <infinity> If you can test that it does build and work with klibc, that's cool too, I don't mind. :)
[05:28] <psusi> the upstream package has a --with-klibc configure option
[05:28] <psusi> also dietlibc I think
[05:28] <infinity> Having it doesn't mean it works.
[05:29] <psusi> it has some other options to you can use to strip out some less needed features for the udeb
[05:30] <psusi> btw.. is there a reason for using isolinux instead of grub on the cd?
[05:33] <infinity> Yes, it works better.
[05:33] <psusi> how so?
[05:34] <psusi> doesn't grub umm... totally kick ass?
[05:34] <infinity> Not for CD booting, apparently.
[05:34] <infinity> syslinux (and by extension, isolinux) is the king of booting removable media on braindead PC hardware.
[05:34] <lifeless> psusi: AFAIK grub does not have a iso support module.
[05:34] <psusi> what difference does the medium make?
[05:35] <infinity> psusi: How the BIOS chooses to try to boot it makes a big difference.
[05:35] <infinity> psusi: And isolinux deals with a lot more broken BIOSes than grub does.
[05:35] <HiddenWolf> infinity: and syslinux looks prettier. :)
[05:35] <lifeless> psusi: you need a standalone driver for the fs and the ability to understand what the BIOS is expecting of you
[05:35] <psusi> lifeless, so it can't boot el-torito native mode, put it and the kernel and initrd into a hd image and build it to use hd emulation boot
[05:35] <lifeless> syslinux is king.
[05:35] <infinity> psusi: Back in "the day", grub was tried on the CD images, failed miserably in certain cases, and isolinux was used instead.
[05:37] <psusi> those broken bioses will get you every time... when I was working on ReactOS I ran into a problem with the boot loader because it was written to use the bios disk number stored in the boot sector instead of the number the bios passes in CL
[05:37] <psusi> and in my case, the boot sector had 0 since mtools figures it's formatting a floppy
[05:38] <psusi> only the drive was 80
[05:38] <psusi> turned out the reason the number exists in the first place and was being used from the boot sector is because a lot of bioses are broken and don't pass the boot disk number in CL
[05:39] <psusi> that was about as annoying as when I was working on the floppy driver and found out that no drives ever made actually support the detect disk command the standard called out for, which is why you have to tell the bios what kind of floppy you have, and the kenrel has to get that info from the bios and run with it... even if it is wrong
[05:41] <mjg59> psusi: It's not "a lot", but yeah. grub only just started dealing with that
[05:42] <psusi> it pissed me off that because some idiot wrote a broken bios somewhere, the boot loader couldn't auto detect the boot medium on my machine, and had to rely on the hard coded value in the boot sector
[05:43] <psusi> I don't know how windows manages to boot from drives other than the primary master... or can it?
[05:43] <psusi> because fat boot sectors ALLWAYS say bios disk 80... unless it's on a floppy, then it's 0
[05:44] <infinity> ntldr can chain to other partitions, but ntldr itself needs to be either on BIOS 0x80 (and on an active partition), or it needs to be chained from elsewhere (like grub)
[05:45] <psusi> and for grub to chain it, grub hooks int 13 to trick ntldr into thinking it's on disk 80 doesn't it?
[05:45] <infinity> Yes.
[05:45] <infinity> And that's all ntldr needs to be able to read far enough to read its config file (boot.ini), and from there it can start loading device drivers and boot "properly".
[05:45] <psusi> wait... does it hook int 13 and fake disk 80, or does it write 81 into the boot sector?
[05:46] <psusi> if you change the disk number in the boot sector to the correct value, it would probably work too
[05:46] <psusi> it's just that dos/windows allways formats hard disks with an 80 in there
[05:46] <infinity> If grub rewrites boot sectors when chaining, that's a bug, IMO.
[05:46] <infinity> (And I'm pretty sure it doesn't)
[05:47] <psusi> another stupid thing it does apparently is store the absolute lba sector number of the partition in the boot sector, and so the boot loader uses that rather than adding local offsets to the starting sector of the partition according to the MBR
[05:47] <psusi> so if you move the partition, you have to change the hidden sectors field in the boot sector for it to still boot
[05:48] <psusi> I seem to remember seeing some command in grub that has it rewrite the boot sector to switch active partitions
[05:49] <infinity> I'd have to look at my girlfriend's computer, where such an icky setup is in place.
[05:53] <wasabi> Trying to find a suitable vmnet module for your running kernel.
[05:53] <wasabi> The module bld-2.6.12-9-i686up-Ubuntu5.10 loads perfectly in the running kernel.
[05:53] <wasabi> UNF!
[05:54] <infinity> WMware distributes pre-built modules for Ubuntu now?
[05:54] <infinity> Neat.
[05:54] <daniels> yay proprietary software
[05:55] <HiddenWolf> infinity: yeah, all we need is a .deb for player.
[05:55] <infinity> elmo: I suppose neon24 will need binary NEW as well, since those binaries were removed yesterday. :/
[06:25] <wasabi> Hah. VNC breaks because it can't find xfonts-base.
[06:25] <wasabi> Because it got moved out of /usr/X11R6
[06:25] <wasabi> How in the heck to change this.
[06:31] <wasabi> Ahh I see. It pulls it's config from /etc/X11/xorg.conf if it exists.
[06:34] <daniels> hi janew
[07:05] <psusi> wow... I think I've udebified this package
[07:06] <psusi> hrm...probably should validate the depends...
[07:15] <psusi> hrm... when I try to build debian-installer it says it can't find libdebian-installer4
[07:17] <psusi> well, it's late... I'll pick this up tomorrow...
[07:24] <JaneW> hi daniels
[08:07] <Den> Anyone know if today's dapper live iso built properly, no errors, etc?
[08:08] <HiddenWolf> Den: check the timestamp, if it hasn't built, it'll not be of today
[08:08] <HiddenWolf> Den: if it's workable / usable, no clue.
[08:09] <Burgundavia> Den, there is an error log somewhere, maybe under people.ubuntu.com/~cjwatson
[08:10] <Den> HiddenWolf: Thanks - the time stamp is new, but yesterday Mithrandir  told me it didn't build properly, even though there was an updated time stamp.  Thats why I asked. Thanks!
[08:10] <dieman> aruuugh. default dupload host is ubuntu ;)
[08:10] <dieman> thats what i get for using my ubuntu box to sign a debian upload
[08:11] <dieman> (i did build and test on my unstable box, yes)
[08:11] <HiddenWolf> ahaha
[08:11] <Burgundavia> dieman, oops, but what did you expect?
[08:11] <HiddenWolf> dieman: don't let d-devel hear. ;)
[08:11] <dieman> heh
[08:12] <dieman> lots of people know i use ubuntu a bit more now
[08:12] <dieman> its sort of how i get paid
[08:12] <HiddenWolf> heh, yeah, but people can be touchy. :)
[08:12] <dieman> omfg you signed on ubuntu?
[08:12] <dieman> if people are that sensitive they need to take a quick reality check :)
[08:13] <dieman> its not like im stupid enough to build it in the wrong place :)
[08:14] <Den> Burgundavia: Thanks - Hey, there's a lot of stuff there - any clue as to where the error log might be?
[08:14] <dieman> christ, katie already emailed me
[08:14] <dieman> just caught the run
[08:14] <Burgundavia> Den, start digging, no idea
[08:14] <dieman> (into the queue, that is)
[08:15] <dieman> the big issue is that my private key is on an efs on a usb disk
[08:15] <Burgundavia> dieman, I have heard of a few cases either way
[08:15] <dieman> Burgundavia: heh.
[08:15] <Den> Anyone - is there an automatic way to search down the tree of a web site for, say , any text that says "error" or "log"?
[08:16] <infinity> dieman: I've removed the default_host completely from dupload.conf on my machine, so I'm forced to use either "--to anonymous-ftp-master" or "--to ubuntu"
[08:16] <Den> Like, some firefox plugin, perhaps?  Or, even easier than that?
[08:16] <dieman> infinity: yeah, that seems best.
[08:16] <dieman> ive not even explored motu stuff yet, haven't had to modify any of the packages yet.
[08:16] <dieman> of the universe packages, that is
[08:17] <dieman> and my boxes are still on hoary, anyhow.
[08:17] <infinity> Slacker.
[08:17] <dieman> heh
[08:17] <dieman> no, just dont want 3-4 distributions around
[08:17] <HiddenWolf> You only need one. Dapper. :)
[08:17] <dieman> its confusing enough to have woody and hoary machines
[08:17] <dieman> to the users
[08:17] <dieman> (woody is going away very fast)
[08:17] <infinity> Yeah, I think I have woody, sarge, sid, breezy, and dapper in the wild right now.
[08:18] <infinity> No warty or hoary, though.
[08:18] <dieman> hoary is pretty good
[08:18] <dieman> ive been ok with it
[08:18] <dieman> worst problem is having to backport some x stuff
[08:18] <dieman> for i945 graphiucs
[08:18] <infinity> I liked it well enough, but hoary->breezy was smooth enough that I just upgraded stuff and was done with it.
[08:18] <dieman> and kernel drivers for intel hd audio on amd64/xeon
[08:19] <infinity> The woody machine still in the wild is being reinstalled from scratch, since it was far too customised to be sanely upgraded to sarge or breezy.
[08:19] <dieman> ive got 236 i686 hoary machines, and 33 amd/em64t hoary machines
[08:19] <infinity> Instead, I have a parallel installation, and am hand-porting configs over, one-by-one.  Ugh.
[08:19] <dieman> and 79 woody machines left.
[08:20] <dieman> so im nearly up to 350 machines
[08:20] <infinity> Student labs?
[08:20] <dieman> labs, desktops, clusters.
[08:20] <dieman> just got a 10x 1u dual opteron 270 cluster
[08:20] <dieman> 4gb of memory for each box
[08:20] <infinity> Sexy.
[08:21] <dieman> need to get PBS setup on those still.
[08:21] <dieman> we've been using condor for the most part, but they want to go to PBS since thats what the big iron at the supercomputer center runs
[08:21] <dieman> and its easier to teach the grads one interface
[08:22] <dieman> im excited about dapper though, thats for sure
[08:23] <dieman> basically i freeze to what i put in the student labs, unless we have insane hw issues
[08:23] <dieman> (ie: dell/intel screw us over with a completely new platform)
[08:24] <HiddenWolf> dieman: what university do you work at?
[08:24] <infinity> UMN
[08:24] <HiddenWolf> ah
[08:24] <dieman> university of minnesota, twin cities
[08:25] <dieman> in the computer science department
[08:25] <HiddenWolf> google thinks it's University of New Mexico. :)
[08:25] <dieman> unm != umn :)
[08:25] <HiddenWolf> heh
[08:25] <HiddenWolf> right.
[08:25] <HiddenWolf> allnighter. :)
[08:25] <HiddenWolf> hey pitti 
[08:25] <pitti> Good morning
[08:25] <infinity> Yo, pittster.
[08:26] <dieman> i'll definately be asking my boss to go to the next ubuntu conf/meeting though..
[08:27] <dieman> i acquired some more help at work, so ive been working on offloading tasks when i can
[08:27] <pitti> hey infinity 
[08:27] <pitti> moin HiddenWolf 
[08:28] <bytee_> does there exist a package list of the various Ubuntu releases, or must I install them individually to find out ?
[08:29] <HiddenWolf> bytee_: packages.ubuntu.com
[08:30] <bytee_> HiddenWolf: thanks
[08:36] <pitti> eek, wvdial asks me for a telephone number
[08:36] <pitti> I don't even have a modem in this box
[08:36] <dieman> heh
[08:38] <infinity> pitti: Yes, I know.  Debconf priority too high.  I've filed a bug in Debian, and if I don't get a reponse ASAP, I'll just fix Ubuntu.
[08:39] <infinity> (I fear the Debian maintainer will response with "well, if you don't have modems, why are you install wvdial anyway?", in which case I'll just patch ours to use a lower prio..)
[08:39] <infinity> s/response/respond/
[08:43] <Mithrandir> isn't it part of the laptop task in Debian, or something?
[08:48] <infinity> Mithrandir: If so, then I suppose Debian would have the same complaint as us about the priority.
[08:48] <Mithrandir> yes. :-)
[08:50] <ajmitch> changelogs not being updated on packages.u.c at the momentw?
[08:51] <infinity> ajmitch: That's a longstanding issue (we don't control package.u.c)... Just s/packages/changelogs/ in the URL, and it'll magically work.
[08:51] <StevenK> changelogs on packages.u.c haven't been updated for quite some time.
[08:51] <ajmitch> ok
[08:51] <infinity> (Same layout, different host, which we do control)
[08:53] <ajmitch> who does control it?
[08:53] <StevenK> Frank Litchenheld
[08:53] <StevenK> djpig
[08:53] <ajmitch> ok
[08:54] <StevenK> Kick him for me. :-P
[08:54] <ajmitch> ah, I was blind
[08:54] <StevenK> Was? :-P
[08:54] <mdke> i mailed him about the missing css too, no reply as of yet
[08:54] <ajmitch> be nice :P
[08:55] <mdke> perhaps he is not around
[08:55] <StevenK> According to /whois, he's been sleeping for 22 hours.
[08:55] <ajmitch> last status update on the frontpage is very recent
[08:56] <mdke> oh yeah, he's fixed the css ;)
[09:06] <Mez> jdub: ping
[09:14] <sivang> Morning all!
[09:16] <Treenaks> Google Talk is open :)
[09:16] <sivang> Treenaks: in what sense?
[09:16] <Treenaks> sivang: it can talk to non-google jabber servers now
[09:18] <pitti> hi sivang 
[09:26] <nnonix> update-notifier taking 100% cpu after latest update
[09:27] <pitti> bah, where are dholbach and seb128 when I want to hit them? bonobo or sth. is totally broken
[09:28] <sivang> hey pitti , 'sup?
[09:30] <pitti> sivang: dunno, first nautilus complained about a bonobo error, and after restarting gnome nothing works any more
[09:31] <sivang> oh man, I'm dist-upgrading. I'll let you know if I ecnounter this as well
[09:33] <pitti> interesting to work without a WM :)
[09:36] <StevenK> pitti: Still VM-less?
[09:37] <sivang> oh, nice, wvdial debconf question on dist-upgrade
[09:37] <sivang> but I don't have modem nor use dial up :)
[09:37] <pitti> StevenK: no, seems to work fine now
[09:38] <pitti> sivang: known bug, infinity deals with it
[09:39] <\sh> hmmm..can wvdial detect first if a modem is connected, and then ask for the rest like username, dialupnumber etc?
[09:39] <Treenaks> \sh: I have a modem in my PC; I don't want wvdial to ask me for dialup-parameters as the modem is not connected  to a phone line
[09:40] <Treenaks> (as I don't have those)
[09:40] <\sh> Treenaks: well..so it's better to detect it first, and then eventually ask: do you want to configure your dialup. 
[09:40] <Treenaks> \sh: maybe
[09:41] <sivang> \sh: pitti said that infinity works on that :)
[09:41] <\sh> sivang: ah nice...I didn't see it, don't have a backlog :)
[09:41] <sivang> Treenaks: we need another question, "Do you want to configure dial up connection settings"
[09:41] <sivang> \sh: actually , pitti told me :)
[09:42] <sivang> nice, last upgrade made gnome-terminal a bit slower to fire up.
[09:43] <pitti> and the tabs ridiculously big
[09:43] <Treenaks> sometimes gnome-term starts eating 100% CPU time and I have to kill it
[09:43] <Treenaks> but I haven't figured out what triggers it yet :(
[09:53] <pitti> infinity: hm, for adding the sudo help, do you think I should rather change the conffile /etc/bash.bashrc, or change base-files to change /etc/profile if it's unmodified? (IMHO changing bash is enough, though)
[09:53] <sivang> pitti: for a fix like that , https://launchpad.net/distros/ubuntu/+source/irssi-text/+bug/26106. Do we sync to upstream version , or include the patch ourselves?
[09:53] <Ubugtu> Malone bug 26106: "segfault when /quit'ing irssi-text" Fix req. for: irssi-text (Ubuntu), Severity: Normal, Assigned to: Debian Bug Importer, Status: Unconfirmed
[09:54] <pitti> sivang: if there is a new upstream version that fixes it, today is a very good day to upload it
[09:54] <pitti> sivang: tomorrow is UVF
[09:54] <pitti> Kamion: ^ smae question as to infinity
[09:55] <sivang> bah, ok, I will take a look , if not we need to get that patch it - it's un-nice to have irssi quit with a core dump
[09:55] <sivang> (except for those who like core dumps)
[10:04] <Mithrandir> pitti: you're touching all the shells now, or are you already done?
[10:05] <pitti> Mithrandir: sudo is done, and I'm currently tinkering with /etc/bash.bashrc
[10:05] <pitti> Mithrandir: I can move the code to /etc/profile if we decide to modify base-config (and its postinst) instead
[10:06] <pitti> Mithrandir: too bad that /etc/profile is not a conffile
[10:06] <Mithrandir> pitti: I am going to nuke the PATH setting out of all the shells and base-files (as well as adding a dep on libpam-modules (>= 0.79-3ubuntu3), but if you're already touching the shells, I'd love if you could do it.
[10:07] <pitti> Mithrandir: oh, that means you need to touch /etc/profile anyway?
[10:07] <Mithrandir> pitti: yes, but if you're already going to do that..
[10:07] <Mithrandir> :-)
[10:09] <pitti> Mithrandir: I could add code to base-file's preinst to remove an unmodified /etc/profile, so that the postinst restores it again, but that seems non-transactional and hackish to me
[10:09] <pitti> Mithrandir: yes, I can do the PATH change together with that, no big deal
[10:09] <pitti> hi seb128 
[10:09] <seb128> hey pitti
[10:09] <pitti> Mithrandir: it just sucks that profile is no conffile, so I'm a bit lost how to change it properly
[10:10] <Mithrandir> pitti: just copy over the new one if the md5sum matches the old file?
[10:10] <pitti> Mithrandir: hm, I could determine the md5sum in the preinst and store it somewhere, right
[10:10] <pitti> Mithrandir: or just store the flag whether it can be nuked
[10:10] <maswan> pitti: btw, suggestion: in the usn:s mailed, how about putting in a link to the webpage (http://www.ubuntu.com/usn/usn-244-1) to make it easier to refer to it to people not getting the mails?
[10:11] <pitti> maswan: and how do the people see the link in the email if they don't read it?
[10:11] <Mithrandir> pitti: uh, just md5sum it in the postinst, rather?
[10:11] <pitti> maswan: ah, sorry
[10:11] <maswan> Of course, now that I know there are those urls, I could probably guess my way through to them, but I just found out and I've wanted to link to them previously and then poked around in the list archive
[10:11] <pitti> maswan: I mixed up 'to' as 'for'
[10:12] <pitti> maswan: yes, I can do that
[10:12] <pitti> Mithrandir: md5sum against what?
[10:12] <pitti> Mithrandir: it's not a conffile
[10:12] <Mithrandir> pitti: if you look at the postinst, you see the "install_from_default" function, right?
[10:12] <maswan> pitti: thanks. mostly collegues etc ("hey, you're the kernel guy, are we safe against this?")
[10:12] <pitti> Mithrandir: sure
[10:13] <Mithrandir> pitti: it could easily be extended to get a (list of) md5sum(s).
[10:13] <pitti> Mithrandir: this could check a flag created in the preinst
[10:13] <Mithrandir> why do you care about preinst?
[10:13] <pitti> Mithrandir: oh, you mean statically put the md5sums into the postinst
[10:13] <Mithrandir> yes.
[10:13] <pitti> *shudder*
[10:13] <pitti> oh well
[10:13] <Mithrandir> where else would you have them?
[10:14] <Mithrandir> you could have the static list in preinst, but the effect would be exactly the same.
[10:14] <pitti> Mithrandir: in the preinst we would still have the old template file in /usr to check it against the one in /etc
[10:14] <Mithrandir> you probably want to upgrade the file if it's not the newest but the second-to-newest too.
[10:15] <mdke> elmo, Znarl, docteam svn repo new members, please. At least respond to my pings if there is a problem.
[10:15] <Mithrandir> pitti: or just make that flag file, it should be innocent enough.
[10:15] <Mithrandir> (my example is _very_ corner-case-ish)
[10:15] <pitti> Mithrandir: ok, I'll write something and show it to you for a peer reviwe
[10:15] <dholbach> hello developers!
[10:15] <pitti> hi dholbach 
[10:15] <Mithrandir> pitti: great. :-)
[10:16] <mdke> hi dholbach 
[10:16] <pitti> Mithrandir: and apart from that I rip out the PATH setting?
[10:16] <dholbach> hey pitti, mdke
[10:16] <Mithrandir> pitti: yes, please.
[10:16] <pitti> ok, no problem
[10:16] <Mithrandir> pitti: what shells will you be touching?
[10:17] <pitti> Mithrandir: profile should cover the ash-like shells, that should already be good enough
[10:17] <Kamion> pitti: considering that doing an upgrade for most people involves successfully using sudo, I think it's only important to make this work on new installs, not on upgrades
[10:17] <pitti> Mithrandir: I can change tcsh, too
[10:17] <Kamion> pitti: so changing the first creation of /etc/profile should be fine
[10:17] <pitti> Kamion: and for Mithrandir's $PATH change?
[10:17] <Kamion> pitti: that needs to be done on upgrade
[10:18] <pitti> hm, so it would actually be more difficult to do $PATH on upgrade and the sudo hint not
[10:18] <Mithrandir> heh.
[10:18] <pitti> *scratching head*
[10:19] <Mithrandir> pitti: ok, I'll need to touch zsh and bash since they set PATH in their rc files.
[10:19] <pitti> Mithrandir: oh, you mean /etc/skel/.bash_profile ?
[10:19] <pitti> it's not in /etc/bash.bashrc
[10:20] <Kamion> if PATH is only in skel dotfiles now, we can't fix it all the way on upgrade
[10:20] <Mithrandir> pitti: I'm wondering if that skel/.bash_profile is ok.
[10:21] <Mithrandir> Kamion: it's just an "add ~/bin if it exists"
[10:21] <pitti> Mithrandir: it should be
[10:21] <pitti> Mithrandir: that's why I wonder which file bash you need to change
[10:21] <pitti> s/bash/in bash/
[10:21] <Mithrandir> pitti: I probably won't need to change bash, then. :-)  Just zsh and zshbeta
[10:21] <Mithrandir> and /etc/crontab
[10:21] <pitti> Mithrandir: where will PATH be set?
[10:22] <Mithrandir> pitti: pam_env
[10:22] <pitti> Mithrandir: as soon as I upload this, people won't have PATH set any more
[10:22] <pitti> is that already in place?
[10:22] <Mithrandir> pitti: they will, as long as you add the versioned dependency on libpam-modules.
[10:22] <Mithrandir> yes
[10:22] <Mithrandir> I uploaded it last night.
[10:22] <pitti> cool
[10:22] <Mithrandir> gdm needs to change
[10:23] <pitti> so, Depends: libpam-modules (>= 0.79-3ubuntu3), right?
[10:23] <Mithrandir> yes
[10:24] <pitti> if /usr/bin/getent group admin | grep -q "\<$USER\>"; then
[10:24] <pitti>     if [ -x /usr/bin/sudo -a ! -e $HOME/.sudo_as_admin_successful ] ; then
[10:24] <pitti>         echo
[10:24] <pitti>         echo 'To execute a command as root, run "sudo <command>" and enter your password.'
[10:24] <pitti>     fi
[10:24] <pitti> fi
[10:24] <pitti> does that look sane?
[10:24] <Mithrandir> I'd rather use "if groups | grep -q admin; then"
[10:25] <Mithrandir> it also isn't i18n-ised. :-P
[10:26] <pitti> if groups | grep -q "\<admin\>"; then
[10:26] <sivang> pitti: ok, just talked to upstream, I we need to make it a local patch, shall I roll on a package and send you a link to the debdiff for review?
[10:26] <pitti> Mithrandir: we also have lpadmin, so we need the boundary checks
[10:26] <sivang> pitti: (context: irssi core dump)
[10:26] <pitti> sivang: sure, that would be nice
[10:26] <sivang> pitti: k
[10:27] <Mithrandir> pitti: true.
[10:27] <pitti> Mithrandir: cool, I didn't know 'groups' yet. There seems to be half a million way to get user/group info :)
[10:28] <Mithrandir> pitti: heh. :-)
[10:30] <triceratops> are there any plans to bind NIC MAC addresses via udev? I'm asking this because I have a computer here which always mixes up the NIC apearence (eth0 is mostly not the same nic after reboot).
[10:31] <Mithrandir> triceratops: the installer writes out a /etc/iftab which is used by nameif
[10:31] <triceratops> AFAIK there are two ways to bind a NIC address to a certain name, nameif and udev
[10:32] <triceratops> Mithrandir: Hhhm, it's a breezy box upgraded to dapper. May be I should add a /etc/iftab by myself.
[10:32] <Mithrandir> triceratops: it has been added in /etc/iftab since warty, iirc
[10:33] <triceratops> Mithrandir: But having a closer look to udev the udev way looks smarter to me..
[10:33] <Kamion> pitti: grep -qw to save you having to do word-matching in the regex
[10:33] <Kamion> Mithrandir: I'd like to change that to generate udev rules
[10:33] <Kamion> I understand the SuSE installer does that
[10:33] <Kamion> (which should answer triceratops' question)
[10:34] <pitti> nice, thanks
[10:34] <triceratops> Kamion: Yepp, perfect... :-))
[10:35] <pitti> I learn new little improvements every day :)
[10:35] <triceratops> Kamion: It might be an idea to have some update-NICname script to do so after installation
[10:35] <Kamion> triceratops: not my problem :)
[10:36] <Kamion> but yeah, I guess it could be done in the udev maintainer script on upgrade or something - not sure that's wise, it'll be up to Scott
[10:36] <triceratops> Kamion: Not my problem having this or not my problem/job to do this ;)
[10:38] <Kamion> the latter
[10:39] <Mithrandir> seb128/dholbach: would either of you like to patch out the setting of PATH from gdm or should I?
[10:39] <seb128> Mithrandir: to change what?
[10:39] <seb128> I was going to upload a gdm package this morning
[10:39] <Mithrandir> seb128: don't set PATH in the config.
[10:39] <seb128> I've 2.8.0.5 ready on my disk
[10:39] <seb128> why?
[10:40] <Mithrandir> seb128: because it's now done by pam.
[10:40] <seb128> it has been asked during warty or hoary for a reason IIRC
[10:40] <seb128> oki
[10:40] <seb128> will change that for the upload
[10:40] <Mithrandir> seb128: and add a dependency on libpam-modules (>= 0.79-3ubuntu3)
[10:40] <seb128> that works
[10:40] <Kamion> seb128: (this is one-true-path)
[10:40] <Mithrandir> excellent, thanks.
[10:40] <seb128> np
[10:51] <Kamion> pitti: ispell-et looks like it's obviously ok to promote?
[10:52] <pitti> Kamion: yes, I also wrote a report
[10:52] <Mithrandir> doko: thanks for doing whatever magic you did to make ooo2 installable
[10:52] <pitti> Kamion: hrm, I forgot to link it from the queue page, my bad; I put it into promoted
[10:53] <doko> Mithrandir: use the neon sources from OOo ;-P
[10:53] <Kamion> pitti: ok, just leave it there
[10:53] <Mithrandir> doko: ^^ :-P
[10:53] <pitti> Kamion: I added it now
[10:54] <doko> Mithrandir: yeah, but fine enough as a short term fix
[10:54] <pitti> doko: yay code duplication :)
[10:54] <Mithrandir> doko: sure.
[10:54] <Kamion> pitti: mozilla-locale-* are ok to demote now, right?
[10:54] <Mithrandir> pitti: you should put him against the wall for crimes against ReducingDuplication. :-)
[10:54] <Kamion> doko: (neon24's back ...)
[10:54] <pitti> Kamion: yes, we'll demote mozilla soon
[10:55] <doko> pitti: please fix mozilla before demoting
[10:55] <pitti> doko: ?
[10:55] <doko> Kamion: will it stay?
[10:55] <doko> pitti: try to install mozilla-dev
[10:56] <Kamion> doko: it'll disappear before dapper release, according to the changelog
[10:56] <pitti> doko: do I really have to? Dependcies are ok, and I don't really want mozilla
[10:56] <pvanhoof> err
[10:56] <pvanhoof> installing x11-common wants to remove  ...
[10:56] <Mithrandir> seb128: file a bug.
[10:56] <pvanhoof>  vncserver x-window-system-core xorg-common xserver-common xserver-xorg xserver-xorg-core etc etc etc
[10:56] <pvanhoof> is that normal?
[10:57] <Mithrandir> pvanhoof: there's something funky in the dependencies there, but I haven't had the time to track it down just yet.
[10:57] <pvanhoof> I think it's trying to remove all xorg related packages
[10:57] <Mithrandir> (and apparently, nobody else has either)
[10:57] <seb128> Mithrandir: the libc crash has quite some dups already (on differents apps), for malone query there is a bunch of bugs too
[10:57] <pvanhoof> ok, will not upgrade x11-common then ;)
[10:57] <HiddenWolf> pvanhoof: Mithrandir daniels went loose on the x packages earlier. :)
[10:58] <doko> pitti: I think this way of demoting packages is rather unfriendly. it breaks all universe packages b-d on a package which we just let fall down
[10:58] <pvanhoof> okay, tell us when it's safe to upgrade :)
[10:58] <pitti> doko: ENOCLUE - what's broken with m-dev?
[10:58] <pitti> ooh, btw, mvo
[10:59] <doko> pitti: it has an = dependency on the nspr and nss packages ...
[10:59] <pitti> mvo: I got this 'failed to contact gamin/fam' dialog box again this morning, and it looks as if it was from update-notifier
[10:59] <mvo> pitti: interessting, I kicked fam out and switched to gnome-vfs instead
[10:59] <mvo> pitti: I'll have a look
[10:59] <pitti> doko: oh, I see; I still have the old libnspr-dev installed, that's why it works for me
[11:00] <Kamion> mozilla-locale-* demoted
[11:01] <mvo> pitti: do you know what version it was?
[11:01] <pitti> mvo: hm, the one from yesterday's dist-upgrade
[11:02] <pitti> mvo: I dist-upgraded again this morning, so if I get it again, I'll poke you
[11:02] <mvo> pitti: thanks, for all I care gamin/fam can go away now :)
[11:02] <pitti> mvo: yes, I'm pretty sure that I still had the previous version this mornig
[11:03] <mvo> ok, thanks
[11:03] <Kamion> seb128: should something depend on python-gobject?
[11:04] <seb128> Kamion: if you mean "should something be change to Depends on it",no
[11:04] <seb128> pygtk Depends on it
[11:04] <seb128> but some app may drop the pygtk Depends in favor of pygoject
[11:04] <seb128> (like flumotion)
[11:04] <Kamion> seb128: no I actually mean the metapackage, not python2.4-gobject
[11:04] <Kamion> nothing depends on that at the moment
[11:05] <seb128> oh
[11:05] <Kamion> (and so anastacia wants to drop it)
[11:05] <Kamion> I think python-gtk2 should probably depend on python-gobject; if you have the first metapackage then you probably want the second too
[11:05] <seb128> hum
[11:05] <seb128> I'm not sure there is a main app using it and not pygtk atm
[11:05] <Kamion> (will file a bug if you want, otherwise the seeds need to be changed)
[11:06] <seb128> should python-gtk2 Depends on python-gobject?
[11:06] <seb128> I was not sure
[11:06] <seb128> python-gtk2 Depends on python2.4-gtk2 which Depends on python2.4-gobject
[11:07] <seb128> but python-gtk2 could also Depends on python-gobject
[11:07] <seb128> will do that change
[11:08] <Kamion> seems simplest, if you don't mind that' thanks
[11:08] <Kamion> s/'/;/
[11:09] <pitti> oh, shit, why doesn't bash read /etc/profile for X shells...
[11:10] <Mithrandir> seb/dholbach: either of you doing a rebuild of evolution-exchange?  I'd like to get -desktop installable.
[11:11] <infinity> pitti: sudo help, say what?
[11:11] <pitti> infinity: nevermind, this decision just sorted itself out since /etc/profile is not read in x terminals
[11:12] <pitti> infinity: so I have to alter /etc/bash.bashrc anyway to add a note about sudo in terminals
[11:12] <infinity> pitti: You're talking about having something spew "to become root, do 'blah'" when a shell is spawned?
[11:12] <pitti> yes
[11:12] <infinity> pitti: Since new installs will all have bash as the default shell, no reason to do it for all shells.
[11:12] <pitti> we discussed this in yesterday's TB
[11:12] <pitti> infinity: sure, just for completeness
[11:13] <ptlo> pitti: profile is read for "login" shells, (can be forced with -l option to bash), and afaik x session is regarded a login shell, the terminals spawned in it aren't
[11:13] <pitti> well, tcsh and zsh are pretty popular, too, so maybe we should change them, too
[11:13] <infinity> pitti: <shrug>... Anyone who can figure out how to change their shell with "passwd -s" can probably figure out sudo. :)
[11:14] <pitti> infinity: chsh might be easier, but probably true
[11:14] <Mithrandir> infinity: is daniels going to fix the xorg-server FTBFS or should  I investigate?
[11:14] <infinity> pitti: And most people will change their shell... From the shell.  So they'll see the help at least once.
[11:14] <pitti> heh, true :)
[11:14] <infinity> Mithrandir: No idea.
[11:14] <Mithrandir> infinity: 'k, I'll poke it, then.
[11:14] <doko> dholbach: do you still intend to update bittorrent?
[11:14] <dholbach> Mithrandir: seb128 is going to upload a new version.
[11:15] <dholbach> doko: yes, any objections or do you have it prepared already?
[11:15] <seb128> ups, forgot that yesterday evening
[11:15] <seb128> Mithrandir: yeah, new version coming in a few min
[11:15] <dholbach> doko: if not, i'll take care of it later.
[11:15] <infinity> Mithrandir: Yeah, rebuilding evo-exchange doesn't work, it needs a new version for new e-d-s API changes, apparently.  (I already tried)
[11:15] <Kamion> pitti: yeah, I agree with infinity, no need to fork all shells for this
[11:16] <pitti> Mithrandir: ok, so I'll change base-files entirely for you :)
[11:16] <doko> dholbach: no obejctions at all :)
[11:16] <dholbach> doko: ok, cool.
[11:16] <infinity> dholbach: While you're at it, do you want to LSBify that init script (I was going to, but hadn't done it yet)
[11:16] <dholbach> infinity: i'll take a look at it.
[11:17] <infinity> dholbach: If not, don't worry.  I can do it sometime after UVF.  It's not urgent.
[11:17] <dholbach> infinity: there are some other things to fix as well - i'll do it in one upload.
[11:17] <pitti> Mithrandir: http://paste.ubuntu-nl.org/7313
[11:21] <infinity> pitti: Do you intend for that md5sum thing to become pseudo-conffile-like?
[11:21] <pitti> infinity: yes, see the debdiff
[11:21] <infinity> pitti: Cause if so, you could auto-generate new sums in debian/rules, and keep that file up to date.
[11:21] <pitti> true
[11:22] <pitti> well, it changed once in the whole ubuntu history
[11:22] <infinity> Yeah, but if it changes again, someone will forget to update the md5sums file, so may as well automate it.
[11:22] <infinity> Fire-and-forget changes are good.
[11:22] <pitti> true, I'll add it to the clean rule
[11:26] <seb128> Mithrandir, infinity: evolution-exchange uploaded
[11:27] <Mithrandir> seb128: thanks
[11:27] <seb128> np
[11:28] <Mithrandir> pitti: thanks a lot. :-)
[11:28] <pitti> hehe :)
[11:35] <pitti> Mithrandir, infinity: http://paste.ubuntu-nl.org/7314 (if you would like to do an eyeball check)
[11:36] <Mithrandir> pitti: uh
[11:36] <Mithrandir> echo "`md5sum share/profile | cut -f 1 -d\  | cat share/profile.md5sums - | sort -u`" > share/profile.md5sums
[11:36] <Mithrandir> that kinda nukes profile.md5sums first.
[11:36] <pitti> Mithrandir: it avoid a temporary file
[11:37] <Mithrandir> you can't know the execution order, share/profile.md5sums might be truncated before the ` ` command is done
[11:38] <pitti> hm
[11:38] <pitti>         LIST="`md5sum share/profile | cut -f 1 -d\  | cat share/profile.md5sums - | sort -u`"; \
[11:38] <pitti>         echo "$$LIST" > share/profile.md5sums
[11:39] <Mithrandir> sure, that should work.
[11:39] <Kamion> ($$? is this in a makefile?)
[11:39] <infinity> if [ ! grep -qw `md5sum share/profile` share/profile.md5sums ] ; then echo `md5sum share/profile` >> share/profile.md5sums; fi
[11:39] <Kamion> infinity: ew, don't use [ ]  for that
[11:39] <infinity> Err, with the appropriate cut/awk to extract it.
[11:39] <Mithrandir> Kamion: yes, makefile.
[11:39] <infinity> Err, minus the test.
[11:39] <infinity> Kamion: Yeah, I was thinking out loud, shoot me. :)
[11:39] <Mithrandir> md5sum < share/profile >> share/profile.md5sums
[11:40] <pitti> Kamion: it's debian/rules, so yes
[11:40] <Kamion> one of these days I'll get sponge into coreutils :)
[11:41] <pitti> sponge?
[11:41] <Kamion> then '(cat share/profile.md5sums; md5sum < share/profile) | sort -u | sponge share/profile.md5sums' would work
[11:41] <Kamion> soaks it all up and *then* squeezes it all out
[11:41] <Mithrandir> heh
[11:41] <pitti> lol
[11:42] <Kamion> http://riva.ucam.org/svn/cjwatson/bin/sponge
[11:42] <pitti> so, this damn thing works fine now, I won't touch it any further
[11:43] <sivang> Kamion: ah it's not packaged?
[11:43] <pitti> Mithrandir: if you want to do any aestnetic change to the postinst, feel free :)
[11:43] <Kamion> sivang: no, too trivial to be worth its own package
[11:43] <sivang> Kamion: right :) I glanced at it now
[11:43] <Kamion> as I say, I keep meaning to ask the coreutils folk whether they'd accept it, but I'd need to rewrite it in C for that
[11:44] <Mithrandir> Kamion: should be trivial to rewrite in C, though.
[11:44] <Kamion> yeah
[11:44] <pitti> Mithrandir: well, indefinitively large buffer handling :)
[11:44] <Mithrandir> 'cept the coreutils folk will want to make it i18n-ised and able to read mail.
[11:44] <Mithrandir> pitti: malloc, dude.
[11:45] <Kamion> pitti: no more than sort
[11:45] <Mithrandir> :-)
[11:45] <pitti> Mithrandir: realloc(), sure
[11:45] <Mithrandir> Kamion: well, your current version doesn't use temporary files or anything.
[11:45] <Mithrandir> pitti: that too.
[11:50] <Kamion> oh, yeah, sort uses tempfiles, forgot that
[11:50] <teroedni> Does The Mac G5 work in Ubuntu
[11:50] <teroedni> ?
[11:51] <teroedni> anyone knows?
[11:51] <teroedni> :)
[11:52] <infinity> teroedni: Yes.
[11:52] <teroedni> so a 2.5GHz Quad-core PowerPC G5 would work with smp ?
[11:52] <teroedni> in Ubuntu?
[11:54] <teroedni> That would be infinitiv power:) guess it could compile pretty good:)
[12:05] <infinity> teroedni: No, the quad-core machines are still a little bit unsupported, AFAIK... I was thinking of ordering one to see about fixing that.
[12:05] <infinity> teroedni: Though, perhaps that is old news, and 2.6.15 fully supports them now.  I might be out of touch.
[12:05] <teroedni> wow if you do
[12:06] <teroedni> i really envy you;9
[12:06] <teroedni> I really wants to order it myself
[12:06] <teroedni> but my economy wouldnt let me yet:D
[12:07] <teroedni> infinitiv:You got money to order a such achine?
[12:07] <teroedni> machine
[12:14] <theine> Is anybody working on this: https://launchpad.net/malone/bugs/28544 ?
[12:14] <Ubugtu> Malone bug 28544: "kernel BUG at net/ieee80211/ieee80211_geo.c:81! (2.6.15-12.17)" Fix req. for: network-manager (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
[12:15] <theine> Ubugtu, that bug is not network-managers fault!
[12:16] <theine> The bug is actually entirely in Dapper main.
[12:16] <Kamion> don't talk to a bot
[12:16] <theine> Kamion, I just realized that ;)
[12:17] <theine> Nice bot though
[12:26] <Znarl> Weekly graph
[12:28] <Kamion> elmo: please sync silo-installer, overwriting Ubuntu changes
[12:34] <Lathiat> hrm, how could i get a count of main and universe packages?
[12:35] <siretart> Lathiat: use grep-dctrl on Packages.gz or Sources.gz, depending on what you want
[12:39] <mvo> Lathiat: you could also use python-apt
[12:41] <Diziet> How can I tell whether my upload's build is wedged somehow ?  I wasn't expecting to find it still listed as `building'.  (firefox, uploaded at 2000Z last night.)
[12:42] <AlinuxOS> pitti, ?
[12:43] <mvo> Diziet: this upload here: http://people.ubuntu.com/~lamont/buildLogs/f/firefox/1.5.dfsg-4ubuntu1/ ?
[12:44] <pitti> hi AlinuxOS 
[12:50] <Diziet> mvo: Ah, I should have gone up a directory.  Thank you.
[12:50] <Kamion> Diziet: "Building" unfortunately just means "buildd admin hasn't confirmed it as failed yet".
[12:51] <Kamion> this can be somewhat irritating; I think next week's Soyuz rollout will make the build logs more visible though ...
[12:51] <mvo> Diziet: cheers
[12:52] <Diziet> Harmpf.  POSIX ate my Makefile.  Nearly all of my Makefiles that I have ever written by the looks of it.
[12:53] <Kamion> Perhaps this change ought to have been hidden behind POSIXLY_CORRECT.
[12:54] <Diziet> sed -e 'stuff \\\n\t\tother stuff\\\n\t\tmore stuff\\\n\t\t'  is not allowed any more AFAICT.
[12:54] <Diziet> I just read a rant about this on debian-devel and it was very inconclusive.  And it seems that there is no way to express it in a way that works with both the old and new formats.
[12:55] <Kamion> sure there is, in this particular case
[12:55] <Kamion> sed -e 'stuff' -e 'other stuff' -e 'more stuff'
[12:55] <Diziet> Maybe we should have a .OLD_LINEBREAKING pseudo-target.
[12:55] <Diziet> Indeed.
[12:55] <Kamion> and I think shifting the command into a define works with both old and new, though I'm not sure about that
[12:55] <Diziet> Also, I've let my local building chroot get out of date, which is how I didn't spot it myself.
[12:56] <Kamion> (but that's ghastly)
[12:56] <Diziet> Do you have a good reference for the change ?  Make's syntax is very badly documented.
[12:56] <Diziet> If `no' I'll go looking myself.  Someone must have explained it at least semi-coherently on some mailing list at some point.
[12:57] <Kamion> info make Execution
[12:57] <Diziet> I've not got the new make installed here yet.  I was going to check there when it had arrived.  Thanks.
[12:58] <Kamion> relevantly:
[12:58] <Kamion>    A shell command can be split into multiple lines of text by placing a
[12:58] <Kamion> backslash before each newline.  Such a sequence of lines is provided to
[12:58] <Kamion> the shell as a single command script.  The backslash and newline are
[12:58] <Kamion> preserved in the shell command.
[12:58] <Kamion> and they're preserved even inside quotes, which of course sed doesn't like
[12:59] <Kamion> at least I think that's the problem, I haven't verified carefully
[12:59] <Diziet> Yes, almost certainly.
[12:59] <Diziet> The error message is a complaint from sed.
[12:59] <Kamion> It was mentioned in /usr/share/doc/make/NEWS.Debian.gz which is the only reason I was aware of it at all (due to apt-listchanges).
[01:03] <Diziet> It's extremely annoying of them to have retrospectively introduced hundreds of bugs into code I wrote years ago.
[01:20] <Mithrandir> mdke: I'm starting to look at your ubuntu-docs thingy now.
[01:23] <janimo> Kamion, I mirrored my seeds branch at http://startx.ro/jani/ubuntu/xubuntu-dapper/
[01:23] <janimo> and modified the update script in the meta package
[01:24] <janimo> does it have to be mirrored on chinstrap for CD image?
[01:25] <Kamion> not chinstrap, but it does have to end up on people.u.c
[01:25] <Kamion> hang on a moment, I'll deal with that
[01:27] <janimo> only http, no rsync access
[01:27] <Kamion> that's fine, pulling now
[01:30] <Kamion> ok, mirrored
[01:31] <Kamion> I'll pull it every 15 minutes
[01:31] <janimo> good, so should I change the update script to use your mirror instead of mine?
[01:32] <Kamion> yeah, just make it be like the other -meta packages
[01:32] <janimo> for consistency with the other metas
[01:32] <Kamion> I will get round to your suggestion to move that into germinate, just haven't done it yet
[01:32] <janimo> thanks
[01:33] <janimo> btw any idea wrt the 64M install OOM killings
[01:33] <Kamion> you now have germinate output at http://people.ubuntu.com/~cjwatson/germinate-output/xubuntu-dapper/
[01:33] <Kamion> no, that sort of thing is hard
[01:34] <janimo> would var syslog help?
[01:34] <Kamion> we may be able to tweak lowmemcheck to have different thresholds, but if the reality is that the installer requires more memory than that, then that's reality
[01:34] <Kamion> no, it wouldn't
[01:34] <Kamion> there's ongoing work upstream on cutting down memory requirements, and I poke things from time to time as well, but it's not something I can commit to solving I'm afraid
[01:34] <janimo> if it requires so much RAM is it still worth using busybox instead of a grownup shell?
[01:35] <Kamion> yes
[01:35] <Kamion> a lot of it is due to poor kernel module udeb splitting, I think
[01:35] <Kamion> I am *not* going to start on the huge divergence from Debian that switching to a different shell would be
[01:35] <janimo> for Debian then not ubuntu
[01:35] <Kamion> it would make my work very difficult, because I would no longer be able to trust that testing under Ubuntu is valid for commits to Debian even to the extent that I do now
[01:35] <Kamion> no, Debian absolutely will not do that
[01:36] <janimo> saving 1Mbyte with busybox but requiring 64 either way seems strange
[01:36] <Kamion> sorry
[01:36] <Kamion> the requirement is less than 64 in Debian
[01:36] <Kamion> as I say the increased requirements in Ubuntu are I think due to poor kernel module udeb splitting
[01:36] <janimo> ah so udebs are a local prob.
[01:36] <janimo> I remember it was last time too with the restricted modules
[01:37] <Kamion> and also using busybox is not just about memory, it's also (in Debian) about fitting on constrained-space media such as floppies
[01:37] <janimo> but now it crashes at when starting partitioning
[01:37] <Kamion> that does suggest we're relatively close to the limit
[01:38] <Kamion> there isn't that much that can easily go though
[01:39] <Kamion> not that's a non-trivial size anyway
[01:39] <janimo> why does it use so much memory? does not each installer step start with all mostly ram free
[01:40] <janimo> or does RAM increase with each stage?
[01:40] <Kamion> about the only thing we can do is fiddle around with partman to try to install some filesystem module udebs after setting up swap
[01:40] <Kamion> the entire installer runs out of RAM
[01:40] <Kamion> every feature added to the installer consumes some RAM
[01:40] <janimo> ah so it does not run from the CD?
[01:40] <Kamion> no
[01:41] <Kamion> the initramfs is loaded from the CD with the base of the installer, and then the rest is loaded at run-time
[01:41] <janimo> I suppose that with gtk it will be even larger then
[01:41] <Kamion> but the initramfs takes memory too
[01:41] <Kamion> yes
[01:41] <Kamion> not switching to that yet though
[01:41] <janimo> it would be ironic to be able to run xubuntu but not install it on a lowmem machine :)
[01:42] <Kamion> cdebconf frontends are structured such that we could easily still build a newt installer for that
[01:42] <Kamion> or even switch at run-time and udpkg --remove the ones we aren't using or something, though that's more fiddly
[01:43] <janimo> and drop some features of the current installer?
[01:43] <Kamion> *shrug* there aren't actually that many features you can drop before you start not being able to install
[01:44] <Kamion> most of the interesting features that you might consider optional (e.g. Kickstart support) are actually really small and not worth dropping
[01:44] <janimo> then I don;t understand what you meant by 'new installer for that'
[01:44] <Kamion> newt, not new
[01:44] <Kamion> it wasn't a typo
[01:44] <Kamion> newt is the user interface library we use in the current installer
[01:44] <janimo> but AIUI we are using newt now
[01:44] <Kamion> yes
[01:44] <Kamion> I'll look at lowmem, see if its thresholds can be fiddled to help out with the current problem
[01:45] <janimo> so what was 'for that' ? what could we build a newt installer for?
[01:45] <Kamion> in the event that we switch Ubuntu to a gtk installer sometime down the line
[01:45] <Kamion> then it would be reasonable to continue using the newt installer for Xubuntu
[01:45] <janimo> ah, ok
[01:46] <janimo> I understood a separte newt installer for xubuntu now, and was wondering what to drop from existing one to fit in the RAM
[01:46] <janimo> ok
[01:48] <Kamion> implementing the mmaping suggestions in http://bugs.debian.org/329743 would help too
[01:48] <Kamion> that's not entirely trivial work though
[01:53] <sladen> mvo: where's michael.vogt@ubuntu.com--2005/apt--pdiff--0 mirroed?
[01:55] <mvo> sladen: http://people.ubuntu.com/~mvo/arch/ubuntu/
[01:55] <mvo> sladen: sorry, I forgot to include that in my mail
[01:55] <Kamion> janimo: ok, we can support 64MB installs in lowmem mode at least
[01:55] <mvo> sladen: it's also available in debian/experimental
[01:55] <janimo> Kamion, does that mean d-i detects low mem and does some stuff differently?
[01:56] <Kamion> janimo: yeah, once I tweak the thresholds for Ubuntu
[01:56] <janimo> thanks
[01:56] <Kamion> janimo: it drops back to English-only
[01:56] <janimo> that's all that si different?
[01:56] <Kamion> few other things
[01:57] <Kamion> in HARDCORE lowmem mode (level 2) it skips loading some bits of the installer too
[01:57] <Kamion> so you get fewer filesystem options, that kind of thing
[01:57] <janimo> is there a link with all packages/source code archives involved in d-i?
[01:57] <janimo> just for reading :)
[01:57] <infinity> Kamion: How small did smarenka get lowmem in the end, for sarge/m68k release?
[01:57] <Kamion> easier to get that from upstream
[01:57] <janimo> upstream I mean
[01:58] <Kamion> svn+ssh://svn.debian.org/svn/d-i/trunk
[01:58] <infinity> Kamion: I don't suppose he actually managed to hit his target of supporting 8MB machines.
[01:58] <janimo> cool
[01:58] <Kamion> infinity: no, more like 25MB I think
[01:58] <infinity> Ouch.
[01:58] <infinity> Oh well.  Better than nothing.
[01:58] <Kamion> well, hmm
[01:58] <janimo> ahm, ssh? I hope there is anonymous too
[01:58] <Kamion> actually no, the level1 threshold is 25MB, I think he got lower than that in lowmem mode
[01:58] <Kamion> janimo: sorry, svn://svn.debian.org/svn/d-i/trunk
[01:58] <infinity> janimo: http://svn.debian.org describes all the access methods.
[01:59] <janimo> yep checking uout now
[02:07] <slomo_> elmo: please sync tomboy, libgdiplus, fatsort, libogg, pygame, taglib, njb-sharp from debian/unstable and banshee, ipod-sharp, libipoddevice from debian/incoming... ubuntu changes can be dropped
[02:10] <siretart> there are quite a lot of sync requests pending, is there a problem with the syncing script or just too overloaded people?
[02:13] <Kamion> janimo: should I try to find some way to skip restricted modules in lowmem mode?
[02:13] <Kamion> most of those are things like newer wireless cards, I'm guessing they're not massively useful on most 64MB machines
[02:13] <ogra> Kamion, thats what i do on thin clients ...
[02:13] <ogra> l-r-m takes up 15MB 
[02:13] <Kamion> well, this is in the installer
[02:14] <janimo> Kamion, I suppose so, although some smalish laptops may still have an USB wireless stick in them
[02:14] <ogra> but that also uses a tmpfs for them, doesnt it ?= 
[02:14] <janimo> but if that's what it takes to make it work with 64M sure
[02:14] <Kamion> nic-restricted-* is smaller, but still takes up a reasonable amount of space
[02:14] <infinity> janimo: LRM doesn't support any USB wireless devices anyway.
[02:14] <Kamion> ogra: the installer's *all* tmpfs
[02:14] <ogra> ah,k
[02:14] <ogra> lol
[02:14] <janimo> infinity, good then
[02:14] <Kamion> janimo: I can do it without that, but can get it lower if we kill the restricted modules too
[02:14] <janimo> Kamion, sure
[02:14] <infinity> janimo: Just ath_pci, which comes in MiniPCI and PCMCIA (PC Card, if you prefer) flavours.
[02:15] <janimo> if it won;t install poeple will file bugs so it's ok
[02:15] <janimo> and if this fix is going to be in the next daily I can test both laptops on which flight 3 failed, yay
[02:15] <Kamion> hmm, not quite sure how to do this though
[02:16] <Kamion> I could just take the sledgehammer approach of dropping the whole restricted component
[02:16] <Kamion> but that's a bit nasty
[02:16] <ogra> Kamion, depends 
[02:16] <infinity> Oh, actually..
[02:16] <Kamion> probably won't be in the next daily
[02:16] <Kamion> ogra: ?
[02:16] <ogra> Kamion, if you have a very lowmem machine its unlikely you use a nvidia 64MB card
[02:16] <Kamion> ogra: nvidia has nothing to do with nic-restricted-* which are the only restricted udebs
[02:17] <infinity> janimo / Kamion : nic-restricted-firmware (not modules) contains the firmware for the acxNNN cards, some of which are USB, and are supported.  The driver's already in the kernel, just not the firmware.
[02:17] <janimo> how large is this udeb?
[02:17] <Kamion> infinity: hmm, yeah, good point
[02:17] <infinity> janimo / Kamion : If that's valuable, you may want nic-r-f, but not nic-r-m
[02:17] <Kamion> -rw-rw-r--  1 cjwatson cjwatson 799332 2006-01-13 10:55 /mirror/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.15/nic-restricted-firmware-2.6.15-12-386-di_2.6.15.4-2_i386.udeb
[02:17] <Kamion> -rw-rw-r--  1 cjwatson cjwatson 195678 2006-01-13 10:55 /mirror/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.15/nic-restricted-modules-2.6.15-12-386-di_2.6.15.4-2_i386.udeb
[02:18] <Kamion> -rw-rw-r--  1 cjwatson cjwatson 508642 2005-12-15 02:15 /mirror/ubuntu/pool/main/b/binutils/binutils-static-udeb_2.16.1cvs20051214-1ubuntu1_i386.udeb
[02:18] <mdke> Mithrandir, great, I'll keep checking my email this afternoon in case you have problems
[02:18] <janimo> anyway most 64M machines won't have such hardware so dropping them is ok if this is the only easy way to solve the lack of mem prob
[02:18] <infinity> Right, and if you drop nic-r-m, you get to drop binutils too, AND drop the tempfs footprint of the linked objects.
[02:19] <mdke> Riddell, fixed the kubuntu-docs web builds. We need to get together and figure out why the path was changed at some stage tho
[02:19] <Kamion> janimo: we can get below 64MB without doing this, but we can get lower if we do this too.
[02:19] <Kamion> not sure how much lower, of course
[02:19] <janimo> Kamion, as you see fit
[02:19] <Mithrandir> mdke: it's mostly along of "wtf were people smoking here?" :-)
[02:20] <janimo> since machines come with ram sizes in powers of 2, 62M vs 55M may not make a difference
[02:20] <infinity> janimo: No, but 62 versus 46 is good (I've had a few 48MB machines). :)
[02:20] <janimo> I know that's why I said 55 ;)
[02:20] <janimo> so the smaller the better if it's not too much work
[02:20] <mdke> Mithrandir, ah
[02:21] <infinity> Dropping the restricted stuff completely could buy you close to 16MB.  Maybe.
[02:21] <infinity> No, maybe not.
[02:21] <infinity> But a fair whack, anyway.
[02:21] <Riddell> mdke: ok, cool
[02:22] <janimo> server install option does not affect the installer footprint at this stage right?
[02:22] <janimo> thinking that not only old desktops but quite some servers may have just 64M
[02:24] <Kamion> janimo: no
[02:24] <janimo> ogra, do they need to run D-i themselves?
[02:24] <Kamion> that's independent
[02:24] <ogra> janimo, nope
[02:24] <janimo> ogra, so it is not affected by d-i taking up over 64M
[02:25] <ogra> janimo, they boot from the network ... i only need a slimm installed system (kernel and X)
[02:25] <ogra> but even that wasnt easy to achieve ...
[02:25] <ogra> the default took about 96MB on breezy ...
[02:26] <ogra> you'll need to drop a lot of services we start by default ...
[02:26] <Mithrandir> ogra: it seems like your ubuntu-artwork package doesn't clean up the mess it made in breezy (wrt firefox home page)?
[02:26] <ogra> Mithrandir, i didnt upload one yet
[02:26] <Kamion> hmm, there's something wrong with lowmem, the udeb with most of the hacks in it isn't getting installed
[02:26] <Mithrandir> ogra: you didn't upload one what?
[02:27] <ogra> Mithrandir, infinity wanted to introduce alternatives for the ff page 
[02:27] <janimo> but there are quite a few 64M boxes running some risky redhat 7.0s I assume which could use some dapper love
[02:27] <ogra> Mithrandir, edubuntu-artwork  for breezy
[02:27] <Mithrandir> ogra: yes, I'm working on fixing that in breezy-updates.  I'm talking about dapper.
[02:27] <ogra> Mithrandir, huh ? 
[02:27] <ogra> works flawless here 
[02:28] <janimo> servers of course
[02:28] <ogra> janimo, yes, but you need to drop stuff from the default to not eat up all memory with useless processes 
[02:28] <Mithrandir> ogra: it won't work in the case of : install breezy, install edubuntu-artwork/dapper, remove edubuntu-artwork/dapper, you don't have a working ff home page.
[02:28] <infinity> ogra: This is xubuntu we're talking about here, it uses different seeds.
[02:29] <infinity> ogra: So, I assume he's installing fewer scary RAM-eating things by default.
[02:29] <ogra> infinity, even for minimal and standard ? 
[02:29] <ogra> Mithrandir, i was relying on the change to alternatives in breezy 
[02:29] <Kamion> minimal is shared between all derivatives; standard currently is but doesn't have to be
[02:30] <infinity> ogra: You can't rely on the breezy fix to fix dapper, that's just broken.  What if a breezy user doesn't have -updates in their sources.list?
[02:30] <Mithrandir> ogra: that still leaves index.html.orig on the file system.
[02:30] <infinity> ogra: Or goes straight from a breezy CD to a dapper upgrade?
[02:30] <ogra> Mithrandir, hmm, right 
[02:30] <ogra> infinity, understood ...
[02:31] <ogra> but nothing i'll care for now, one day before UVF :)
[02:32] <Mithrandir> ogra: also note that I filed bug 28885 against you a short while ago.  _Please_ read the debian policy manual on what you're allowed to do in maintainer scripts and what you aren't.
[02:32] <Ubugtu> Malone bug 28885: "changes other packages' conffiles in maintainer scripts" Fix req. for: ubuntu-artwork (Ubuntu), Severity: Major, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/28885
[02:33] <ogra> Mithrandir, err, thats according to seb128 the only way to change a gdm theme 
[02:34] <seb128> hum
[02:35] <ogra> grmpf ... why am i not allowed to change that bug ...
[02:35] <Mithrandir> ogra: then gdm needs to grow a new way for you to change the theme.  You must not ever change conffiles in maintainer scripts.
[02:35] <seb128> for the record I never said to edit a conffile 
[02:35] <janimo> seb128, ogra I am interested in a way to change the default gdm theme too
[02:35] <ogra> could someone whi is allowed change it to edubuntu-artwork and assign it to me ? 
[02:35] <seb128> I just said gdm.conf is where the theme are defined
[02:36] <ogra> its hard to get aware of bugs if i'm not ever subscribed to them
[02:36] <ogra> seb128, you told me its the only way 
[02:36] <seb128> grrrrr
[02:36] <seb128> I said gdm.conf is the place for that
[02:36] <janimo> seb128, one way would be to use gdm.conf-custom but I am not sure it is a clean way to override the default gnoem them
[02:36] <Mithrandir> ogra: what's your LP username?
[02:36] <seb128> I didn't said to sed it with a maintainer script!
[02:36] <ogra> Mithrandir, ogra iirc
[02:36] <seb128> I changed the bug
[02:36] <ogra> thanks
[02:37] <ogra> seb128, thats not what i said ...
[02:37] <seb128> Mithrandir: usually IRC nicknames work for the distro team people
[02:37] <Mithrandir> uh, wtf?
[02:37] <infinity> seb128: Really?
[02:38] <seb128> infinity: it's my experiance with mvo pitti ogra dholbach 
[02:38] <seb128> experience
[02:38] <seb128> maybe I'm just lucky :)
[02:38] <Mithrandir> ogra: anyway, it's assigned to you now.
[02:38] <seb128> keybuk works too
[02:38] <ogra> yup, saw that, thanks
[02:38] <infinity> seb128: Maybe those just happen to be their launchpad logins too?  (Mine is definitely not infinity)
[02:39] <mvo> seb128 knowns them all, because he likes assigning his bugs to us :P
[02:39] <seb128> infinity: probably :)
[02:39] <seb128> mvo: I like to share :)
[02:39] <ogra> Mithrandir, am i allowed to divert a gdm.conf ? 
[02:39] <seb128> mvo: isn't that nice ? :)
[02:39] <Mithrandir> ogra: no, you can't divert conffiles.
[02:39] <mvo> seb128: :)
[02:39] <ogra> grmpf
[02:40] <Riddell> ogra: but you already edit it don't you?
[02:40] <ogra> Riddell, yes
[02:40] <Riddell> so why divert?
[02:40] <seb128> Riddell: because 2 packages can't ship the same file
[02:40] <ogra> Riddell, to not edit it in the future 
[02:40] <seb128> Riddell: atm it sed the gdm conffile on install to modify it
[02:41] <ogra> but if thats no option either, i have no idea how to do it 
[02:41] <Kamion> ogra: you need to get gdm to provide a proper way for you to do it
[02:41] <ogra> yes
[02:41] <seb128> ogra: patch gdm to teach him an alternative way
[02:41] <mdke> Mithrandir, one last thing, can you email me a link to a binary once you've done so I can check it, really quickly? would appreciate it
[02:41] <Kamion> you can't just go storming in doing whatever seems to kind of work (until you consider upgrades)
[02:42] <Kamion> I realise that making things work now is a valuable thing to do, but there's also doing it in a way that doesn't need major cleanup later :)
[02:42] <Riddell> ogra: what's wrong with editing the file?
[02:42] <Kamion> Riddell: maintainer scripts must never edit conffiles; it causes dpkg prompts on upgrade
[02:43] <Kamion> when the user never edited the file and will be totally confused about what to say to this prompt
[02:54] <sivang> dooglus: are you Chris Moore ?
[02:54] <sivang> ah, he's away
[02:59] <sivang> pitti: http://muse.19inch.net/~sivan/fix_irssi_segfault.diff
[02:59] <sivang> pitti: let me know if to upload the source 
[03:17] <Kamion> right, lowmem level2 can handle 48M installs at least; trying lower
[03:18] <pitti> re
[03:18] <sivang> pitti: you lost connection or osmething?
[03:19] <pitti> sivang: no, I was at lunch
[03:19] <pitti> sivang: patch looks fine
[03:19] <pitti> sivang: did you send it to Debian, too?
[03:19] <pitti> sivang: would be nice to just sync the package
[03:20] <pitti> sivang: oh, it's already for Debian
[03:20] <sivang> pitti: what do you mean? :)
[03:20] <pitti> +irssi (0.8.10-2) unstable; urgency=low
[03:22] <sivang> pitti: ah , right :)
[03:22] <sivang> I will email the maintainer, how much time can we wait for the sync?
[03:22] <sivang> until tomorrow ?
[03:22] <pitti> sivang: no, we can sync until maybe a week before release
[03:22] <pitti> sivang: for such trivial patches at least
[03:23] <sivang> pitti: so there is enough time for me to contact him , then
[03:23] <pitti> sivang: (of course not for new upstream versions, and stuff)
[03:23] <sivang> pitti: debian is also considered upstream in the UVF sense?
[03:23] <pitti> yes
[03:23] <sivang> so how come we sync until week before release?
[03:23] <pitti> sivang: well, we will stop autosyncinc
[03:23] <jdub> sivang: in large part, debian *is* the U in UVF :-)
[03:23] <pitti> but we can manually request syncs after checkign them 
[03:23] <sivang> jdub: :)
[03:23] <ogra> sivang, we can still cherrypick trivial fixes
[03:31] <Tm_T> known issue? there's some md5sum mismatch in repositories
[03:31] <Tm_T> atleast in se. mirror
[03:34] <Tm_T> I'll check what fi. mirror gives
[03:34] <Tm_T> yes, only se. mirror has that mismatch issue
[03:35] <Kamion> 32MB install!
[03:36] <jjesse> infinity: i have a question on wv-dial, just did an apt-get update && apt-get dist-upgrade today on dapper and it asked for a phone #, username, and password but i don't have a modem installed
[03:36] <pitti> jjesse: known bug, and lots of complaints already :) we'll fix that ASAP
[03:36] <jjesse> pitti: awesome thanks
[03:36] <Kamion> it's been fixed in dapper already
[03:37] <\sh> pitti: you are our security pope :) and I think you know debsecan...would you like to remove it from the archives, or should we try to make it working for ubuntu?
[03:38] <\sh> .oO(to have a nice utility for ubuntu server :))
[03:38] <pitti> no, I never tried it
[03:38] <ogra> \sh, whats wrong with using it with the debian database ? 
[03:38] <pitti> \sh: no idea how it works, but ubuntu-cve already provides something that coudl be utilized for sth like that
[03:39] <ogra> it will at least give you indicators to look for in the ubuntu usn list
[03:39] <\sh> ogra: I checked it with a sid chroot and an actual dapper system...there are differences
[03:39] <\sh> ogra: and I have to check what's inside this http://secure-testing.debian.net/debian-secure-testing/project/debsecan/release/1/ database (sid e.g.) and check the data..
[03:40] <ogra> i think you are still able to check debian security as it is in ubuntu now ...
[03:40] <ogra> i dont think thats wrong ..
[03:40] <ogra> and i wouldnt remove it ...
[03:41] <\sh> ogra: it's actually very usefull. but I wonder what's the difference (despite the fact of different package version numbering)
[03:41] <ogra> additionally i wouldnt put time into it one day before UVF if there are not a lot of bugs (iondicating that many users use it)
[03:42] <\sh> ogra: it hasn't to do with bugs in the package...the request was: "it's not useful for ubuntu, please can you remove it" I say, it can be useful for server admins and others, so we leave it and make it work somehow.
[03:42] <\sh> ogra: the only change we have to do is "adding ubuntu releases" and "updating a external database" (the database we have to analyse)
[03:43] <\sh> ogra: which is propably something for dapper +1
[03:43] <ogra> yes
[03:43] <\sh> but very reasonable for the ubuntu server project (imho)
[03:44] <ogra> "can be useful" is not really something i'd look at short before UVF, "is used by many users" would rather be my goal
[03:46] <\sh> ogra: apt-get install debsecan ; man debsecan it's very useful...and how can u measure "used by many users" ?
[03:47] <ogra> \sh, many bugs filed == many users that care for it
[03:47] <Kamion> janimo: ok, down to 32MB should now work fine, at least on i386
[03:47] <\sh> ogra: then it's worth to not remove it :)
[03:48] <Kamion> below 52MB you'll go into lowmem level 2 where you have to select udebs yourself; I measured 32MB by selecting none of them
[03:48] <ogra> \sh, does it have many bugs ? 
[03:48] <\sh> ogra: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=src&data=debsecan&archive=no&version=&dist=unstable (i think it's enough)
[03:49] <ogra> where are the bugs in ubuntu ? i dont care about debian bugs for a ubuntu rewrite/fix 
[03:49] <doko> Kamion: how's the installer package called, that lets you choose the timezone?
[03:50] <ogra> do a s/users/ubuntu users/ in my above sentences
[03:50] <\sh> ogra: ok...then it's not usable, because it doesn't support ubuntu correctly...so would you like to request the removal then? ;)
[03:50] <Kamion> doko: tzsetup
[03:50] <Kamion> well, tzsetup-udeb is the binary
[03:51] <ogra> \sh, i really have other probs to care for atm we have UVF tomorrow ... decide yourself ...
[03:51] <\sh> ogra: you see :) i think it's worth it...let's see what we can do about it...it's not an urgent project
[03:52] <ogra> as long as you can use it to detect debian USN from a ubuntu system it might be helpful 
[03:54] <\sh> ogra: yagisan just found the database structure...and we can add our security stuff to it..let's see
[03:54] <doko> Kamion: thanks
[04:00] <sivang> whoopsy, just saw the sudo message, before I read it to end, I was afraid something went wrong in the terminal :)
[04:03] <mhz> jdub: ping
[04:11] <doko> hmm, what's a reliable criterium to filter launchpad bug reports?
[04:12] <Mithrandir> doko: ^X-Generated-By: Launchpad  ?
[04:13] <doko> yeah, just found X-Launchpad-Bug: distribution=ubuntu
[04:15] <Mithrandir> Riddell: hmm, any reason why you're setting the priority of /usr/share/doc/kde/HTML/en/kubuntu/about-kubuntu/index.html to 40 and not something higher?
[04:16] <Riddell> Mithrandir: should it be set higher?
[04:17] <Mithrandir> Riddell: I would imagine it should be higher than ubuntu-docs, since if you have both ubuntu-docs and kubuntu-docs installed, the kubuntu should be preferred?
[04:18] <Mithrandir> Riddell: (based on the "ubuntu is the base, kubuntu builds on that, so if you install kubuntu stuff, you probably prefer that")
[04:19] <Riddell> Mithrandir: when it's been discussed here we decided it's impossible to tell which the user prefers when they have both installed, and I think I was trying to be polite to ubuntu by setting the priority the same.  I'm happy to have a higher priority of course :)
[04:20] <Mithrandir> Riddell: *shrug*, if it's already been discussed, I'd be fine with going with that.  Just wondering since I'm doing the breezy-updates stuff now.
[04:20] <Riddell> Mithrandir: bump it up to 45 or something then
[04:21] <Mithrandir> Riddell: sure.  It'll be more consistent with the previous behaviour (where you dpkg-diverted the file) too.
[04:31] <sivang> OMG evo is crashing on me, and I need an important email from IBM :p
[04:31] <sivang> and it's POP3 , so it's no longer on ther server. I'm screwed
[04:39] <Diziet> Given an Ubuntu bugzilla bug number, how do I quickly find the same bug in LP ?
[04:39] <Diziet> Oh, there's a weirdo URL in the transition announcement.
[04:39] <Kinnison> http://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/%s
[04:40] <Kinnison> is what I changed my "ubug" mozilla keyword to
[04:43] <Diziet> Now that I have the LP bug ID I want to know how to close it by sending email.
[04:43] <Diziet> But LP's ghastly web UI has no link (that I can find) to the email interface manual.  I found https://wiki.launchpad.canonical.com/MaloneCommandInterface but that doesn't seem to cover closing.
[04:44] <\sh> Diziet: give me one sec I give you an example
[04:44] <Diziet> Oh, it's here under `Noting a product release or source package release infestation'.
[04:45] <\sh> Diziet: affects /distros/ubuntu/%s status Fix Released
[04:45] <Diziet> Right.  Where did you get that ?
[04:45] <\sh> (if it's right with the last fix for malone) 
[04:45] <Diziet> But in fact the bug is invalid and I want to blow it off.
[04:45] <\sh> Diziet: from my tool :
[04:45] <Kamion> http://bugzilla.ubuntu.com/<bugzilla-id> gives you a link to the LP bug
[04:45] <Diziet> kamion: Oh, very useful, great, thanks.
[04:46] <Diziet> \sh: Your tool is the reference manual ?
[04:46] <\sh> Diziet: https://wiki.launchpad.canonical.com/MaloneEmailInterface?highlight=%28LaunchpadProposalTemplate%29%7C%28MaloneSpecification%29%7C%28%28Status%29%5B%3A%27A-z%2C%5Cs%5D%2A%28DraftSpecification%7CEditedSpecification%29%29%7C%28%28Status%29%5B%3A%27A-z%2C%5Cs%5D%2AMaloneSpecification%29
[04:46] <\sh> argls
[04:46] <\sh> wiki.launchpad.canonical.com/MaloneEmailInterface
[04:46] <Diziet> Oh, of course, I'm looking at the wrong page.
[04:46] <\sh> shiddy search function of moin
[04:46] <Kamion> 'status rejected' would presumably act to blow off the bug
[04:47] <Diziet> So is MaloneCommandInterface obsolete ?
[04:47] <Kamion> no, the link \sh gave links to MCI
[04:47] <\sh> Diziet: but be carefull..the status commands are not updated, when I checked the day before yesterday
[04:47] <Diziet> https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc seems to be what I'm supposed to be reading.
[04:47] <Kamion> I think you're basically supposed to do "No, this bug makes no sense at all.\n\n status rejected\n"
[04:48] <\sh> Diziet: so you have to adjusted them from the webpage like "fixed" is now "fix released" or "pending upload" is "fix committed" or something
[04:48] <Kamion> to nnnnn@bugs.launchpad.net
[04:48] <Diziet> What, just mix commands in with running text ?
[04:48] <Kamion> (the leading whitespace being significant)
[04:48] <\sh> Kamion: and gpg signed the mail must be :)
[04:49] <Kamion> I've noticed bradb introducing commands with leading whitespace
[04:49] <Diziet> Dammit, where is this DOCUMENTED ??
[04:50] <Diziet> GRRR.
[04:50] <Kinnison> Diziet: docs? *snort*
[04:50] <Kamion> aha, found it
[04:50] <Kamion> https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc
[04:50] <\sh> Diziet: for me it's my lpbugs.py but before...I just asked on #launchpad :) 
[04:50] <Kamion> the previous links were specifications, not documentation; that page is intended as documentation
[04:50] <Diziet> MaloneEmailInterfaceUserDoc isn't a reference manual, it's a pile of examples.
[04:50] <\sh> Kamion: but outdated
[04:51] <Kamion> Can't help you there ...
[04:51] <Diziet> Yes, yes, I'm not asking for _you_ to help me.  But GRRR.
[04:51] <Kamion> UserDoc does at least say that commands are introduced by leading whitespace, which appears to be mentioned nowhere else
[04:52] <Diziet> `#
[04:52] <Diziet> Status: BrainDump, MaloneDocumentation
[04:52] <Diziet> '
[04:52] <Diziet> Says it all really.
[04:52] <\sh> Diziet: you want to reject the bug right?
[04:52] <Diziet> Yes, yes, I'm trying to be taught how to fish, not be given a fish.
[04:52] <Diziet> We've got too much of a culture of giving out fish, round here.
[04:52] <Diziet> But in fact it turns out that the pond is dry.
[04:53] <\sh> ok...
[04:53] <Diziet> So I shall, erm, pour oil on it, thus mixing my metaphors beyond repair.
[04:54] <\sh> you write in the mail (beneath your text)<tab whitespace whatever space> affects /distros/ubuntu/<sourcepackage> status Rejected
[04:54] <Kamion> \sh: perhaps you should go and write a reference manual for it, so that we don't have to tell the next person who wants to know?
[04:54] <Diziet> Can I write it above my text and use `done' ?
[04:54] <Kamion> or somebody who can be authoritative on the syntax
[04:55] <\sh> Diziet: sign the mail and send it to <lp bugno>@bugs.launchpad.net
[04:55] <Kamion> I *believe* you can write it above the text and as long as your running text doesn't have leading whitespace you're fine. (No idea if it has a done command; it *should*, damnit.)
[04:56] <\sh> Kamion: well...it's all documented in this nice little documentation, before the change of malone..everything worked out of the box :)
[04:56] <\sh> but the right thing (tm) to do is to ask bradb i thinkl
[04:56] <Kamion> and hold him down until he writes better documentation and links it from the Malone UI ...
[04:58] <Mez> has katie been updated or something?
[05:00] <Diziet> I'm going to make myself very popular with the LP people I'm sure.  But this stuff isn't rocket science !
[05:01] <Kamion> don't worry, a lot of people are throwing bug reports at Malone just at the moment
[05:01] <Kamion> and it's exactly what it needs
[05:01] <\sh> Diziet: everything what can be improved, you should tell them :) 
[05:01] <Kinnison> And I expect those will be *really* ranty
[05:01] <HiddenWolf> Heh
[05:01] <\sh> Kinnison: ETA for soyuz? rumours said, next 2 to 4 weeks?
[05:02] <Kinnison> \sh: There's a deployment sprint next week
[05:02] <Diziet> You saw my rant about the godawful page layout, which mpt had written down since SEPTEMBER.  That's FOUR MONTHS ago.
[05:02] <Kamion> we are in a position where the distro team have a fair bit of influence over the Malone team's priorities right now, because they know our workflow depends on them; so we should take advantage of that
[05:02] <Kamion> (imo)
[05:02] <Diziet> That at least is something.
[05:02] <Kinnison> Kamion: yep, you should
[05:02] <\sh> Kinnison: cool :)
[05:02] <Kamion> (page layout does take second place to missing-but-required functionality, though)
[05:02] <Kinnison> also, iirc, daf has been assigned to help the malone UI for now
[05:03] <Diziet> But if getting us angry is the best way to motivate LP in the right direction, what does that tell us about the LP project's ability to take and believe external input ?
[05:03] <Kinnison> So they have more manpower
[05:03] <HiddenWolf> Kamion: push for an interface that is _easy_ to use for newbies. You want to take every hurdle you can out of the process.
[05:03] <Kinnison> Diziet: There's a huge issue here -- that the LP team worked essentially in isolation for a year to implement mark's vision
[05:03] <Kinnison> Diziet: and now we have to match that to everyone elses's expectations
[05:03] <Diziet> It's a BUG SYSTEM.  It's not for use by the ignorant, it's for use by DEVELOPERS.
[05:03] <ogra> Diziet, the ui is not *this* bad, you just need to open ff with the double of your window width and cnter it ;P
[05:04] <Kamion> HiddenWolf: the intent is for newbies to be steered towards filing support requests, not bugs
[05:04] <ogra> s/window/screen/
[05:04] <\sh> guy, sorry to say, working with LP and konqueror is just a nice thing to do :)
[05:04] <\sh> .oO(setting every font to monospace 8)
[05:04] <Kamion> so that those can be triaged a bit more effectively and avoid flooding developers with duplicates or poor bug reports
[05:04] <ogra> \sh, not if you need to scroll 3m because the text interface is to small
[05:04] <ogra> s/small/slim/
[05:04] <\sh> ogra: that's why I wrote a remote bug requester :) 
[05:05] <ogra> \sh, that doesnt fix the web UI
[05:05] <\sh> ogra: some magic regexp and I was happy :) 
[05:05] <ogra> the menus need to go from the right and left side
[05:05] <\sh> ogra: well it will fix sometimes my scrolling disability
[05:06] <Kamion> LP has a larval support system already. Look at the difference between the quality of the typical support request and the quality of the kind of bug we'd like to get. Consider that it may not always be worthwhile to educate users to the point where they can file the sort of bug we'd like to have; instead for some people it might be better to have them go through an intermediary.
[05:07] <\sh> Kamion: well...I like those bug reports very much...very informative https://launchpad.net/malone/bugs/28784
[05:07] <Ubugtu> Malone bug 28784: "KDE applications crash (Kontact, kicker, amarok etc)" Fix req. for: qt-x11-free (Ubuntu), Severity: Normal, Assigned to: Kubuntu Team, Status: Unconfirmed
[05:08] <\sh> just a good and shiny subject line...and a backtrace report without debug symbols and no explanation
[05:12] <Diziet> I think I'll let the bugs go hang and go and wrestle with firefox some more.  That's more fun.
[05:14] <Kinnison> Diziet: FYI, launchpad only supports v4 keys currently
[05:14] <pitti> Diziet: were you able to fix the ftbfs?
[05:14] <Kinnison> Diziet: this is a known issue
[05:14] <Kinnison> Diziet: I don't know the status though
[05:16] <Diziet> kinnison: OIC.  Niiice.
[05:16] <Diziet> pitti: The FTBFS is trivial and I will definitely fix it in my upload at the end of the day today.
[05:17] <pitti> cool
[05:17] <Diziet> Although I don't know if the fix will take on amd64.
[05:22] <sivang> pitti: the DD is going to include the patch together with some more fixes tonight probably, so we could sync it tomorrow , overriding ubuntu changes. (currently there are none)
[05:22] <pitti> sivang: then it'll be autosynced, unless that is deactivated earlier
[05:23] <pitti> sivang: thank you
[05:23] <pitti> sivang: (if that happens, just ask for a manual sync)
[05:23] <sivang> pitti: yes, I will look on it, as a heavy irssi user it's fun to take care for its bugs :)
[05:24] <sivang> pitti: bascially, all packages that do not contend with ubuntu local changes are un-manely autosynced?
[05:24] <Diziet> Bah, the metadata for 5 firefox trees won't fit in my buffer cache.
[05:24] <pitti> desrt: what's d-d-l?
[05:25] <Diziet> I think my fs must be misoptimising its use of cache.
[05:25] <sivang> desrt: yes, which ml is that?
[05:25] <desrt> pitti; desktop-devel-list.
[05:25] <sivang> oh
[05:25] <desrt> pitti; gnome discussion list for... everything, really
[05:25] <pitti> oh, I don't know that one
[05:26] <desrt> someone said something along the lines of "it's secure because it's in hal"
[05:27] <pitti> hm, depends in which hal :)
[05:27] <\sh> hal9000, dave
[05:27] <sivang> pitti: probably yours :)
[05:27] <desrt> in reference to the ability of any user to shutdown the system instantly by calling hal
[05:27] <pitti> desrt: btw, the gentoo maintainer replied to the long thread as well, he shares our opinion
[05:27] <desrt> pitti; that's very good
[05:28] <desrt> pitti; i'm fighting the proposal for g-p-m inclusion in the desktop on several points... one of them is the hal issue
[05:29] <pitti> hm, is there any possibility to jump to a particular bug in malone?
[05:29] <desrt> by number?
[05:29] <desrt> launchpad.net/bugs/### will forward you to the right place
[05:30] <\sh> lpbug:<bugno> is doing that for konqueror :)
[05:30] <\sh> would be cool to have something like this for ff as default :) but I don't know anything about those shortcuts in ff
[05:32] <pitti> desrt: hm, I meant a small input box like in bz
[05:33] <pitti> but yes, that's good enough
[05:33] <pitti> (a ffox search plugin would rock for that)
[05:33] <desrt> pitti; make a firefox keyword
[05:33] <desrt> pitti; very easy
[05:33] <sivang> pitti: https://launchpad.net/bugs "Jump to bugreport"
[05:33] <sivang> desrt: how do you do that?
[05:33] <desrt> sivang; add a 'quick search'
[05:33] <desrt> keyword 'lp'
[05:34] <desrt> like https://launchpad.net/bugs/%s
[05:34] <desrt> then you can type 'lp 1234' in the bar
[05:34] <sivang> ok cool, I will add those
[05:34] <Mithrandir> mdke, Riddell, ogra: please do look at the packages in http://people.ubuntu.com/~tfheen/doc-fixes/ ; those will be uploaded to breezy-updates unless there's something broken about them
[05:35] <\sh> desrt: do you think it would interesting to have those little things included in ubuntu? I'm doing it for kubuntu and konqueror by default..but I'm missing it as standard for ff in gnome 
[05:35] <sivang> \sh: I think it would 
[05:35] <sivang> it's working nicely in konqi
[05:36] <\sh> sivang: well for lazy people like me
[05:38] <mdke> Mithrandir, will test now, thanks
[05:38] <ogra> Mithrandir, why is the update-alternatives in the prerm, not postrm script ? 
[05:41] <ogra> Mithrandir, apart from that, it installs fine here 
[05:43] <Riddell> Mithrandir: looks good to me
[05:43] <Riddell> kubuntu that is
[05:46] <Diziet> *sigh*  I suppose I'll have to deploy a general-purpose V4 GPG key.
[05:46] <mdke> Mithrandir, what's the 5.10-7 stuff?
[05:47] <wasabi> Hey so I was thinking. Is there a swap daemon which could dynamically create swap files as RAM is needed?
[05:47] <wasabi> with some sort of upper limit, etc.
[05:49] <mdke> Mithrandir, works nice here. I'm just slightly confused by the tiny diff, did you do a diff on the breezy version? it should be huge
[05:51] <ogra> wasabi, ltsp has such a thing, you can probably adopt it for normal swap stuff
[05:51] <ogra> wasabi, look for ltspswapd at ltsp.org
[05:56] <infinity> pitti: Hrm, I think your sudo help text would look better with the blank line trailing it, not leading it. :)
[05:56] <infinity> pitti: (Stuff squished up against a prompt is hard to read)
[05:56] <pitti> infinity: hm, maybe both then?
[05:57] <pitti> infinity: before there is often motd, and a blank line looks better then
[05:57] <infinity> There's never an MOTD in an xterm/gnome-terminal, which is where I expect people will be watching for this.
[05:57] <infinity> (and the motd always has a trailing blank line too, no?)
[05:58] <pitti> infinity: ok, I'll swap that around then
[05:58] <infinity> Hah, and I can't actually find a system where I haven't replaced the stock MOTD.
[05:58] <infinity> So much for that data point.
[05:58] <pitti> mine hasn't a trailing blank, and I'm using the default one...
[06:01] <tepsipakki> what the heck happened to cdimages.ubuntu.com?
[06:01] <pitti> infinity: fixed
[06:02] <tepsipakki> now it shows the front page of "the bazaar project"
[06:03] <lionelp> tepsipakki: in fact, the url is http://cdimage.ubuntu.com/
[06:03] <lionelp> (with no "s" at the end of cdimage)
[06:04] <tepsipakki> both worked 5min ago =)
[06:04] <lionelp> someone played with apache conf' :)
[06:04] <tepsipakki> apparently
[06:11] <Kamion> cdimages.ubuntu.com is supposed to be a CNAME for cdimage.ubuntu.com, although I don't think we've ever guaranteed that the former will work
[06:12] <Kamion> cdimage is two hosts; I think it's more likely that only one of them is configured to deal with cdimages.u.c correctly than that somebody changed the Apache config
[06:13] <Riddell> pitti: a package in kubuntu main just released a version with qt4, how much would you object to an upload?
[06:13] <infinity> Are we not trying to avoid qt4 in main until post-dapper?
[06:14] <pitti> *sigh* two days later, and UVF would have saved us :)
[06:15] <Riddell> there really is no way to avoid the fact that we're going to have programs that use qt3 and some which use qt4 for some time to come
[06:16] <infinity> Riddell: Sure, but not in a release we have to support for 3 years sanely, pretty please? :)
[06:16] <jdub> ... after dapper ... :-)
[06:16] <infinity> Riddell: If we can avoid it for dapper, the floodgates open for dapper+1, and it's all good.
[06:16] <neuralis> infinity: which mysql did you end up deciding on?
[06:16] <Riddell> if we support qt3 there shouldn't be a problem supporting qt4
[06:17] <infinity> neuralis: 5.0
[06:17] <neuralis> infinity: good deal.
[06:17] <infinity> neuralis: With a rolling UVF exception, so we can get last-minute fixes.
[06:18] <infinity> Riddell: That's a nice theory, but as a man whose supported multiple upstream codebases at the same time, I can tell you it's a pain in the ass.
[06:18] <neuralis> infinity: excellent. they seemed to have fixed a great deal of the initial 5.0 bugs already.
[06:18] <infinity> neuralis: Yes, that's what I based my decision on.  Both the current stability, and their impressive responsiveness.
[06:18] <infinity> neuralis: I've no doubt it'll be as solid (or more) as 4.1 would have been for us.
[06:19] <infinity> neuralis: And I really, really, really didn't want to support more than 1 (see above)
[06:19] <Kamion> Znarl: 82.211.81.176 is part of cdimage.ubuntu.com but seems to give ECONNREFUSED to connections on port 80
[06:21] <neuralis> infinity: yes, it's a good decision, and supporting both is more or less out of the question.
[06:21] <infinity> neuralis: I also joined the Debian MySQL team in an effort to keep closer tabs on our pet bugs.
[06:21] <infinity> neuralis: So, it's (in my opinion) well maintained. :)
[06:23] <neuralis> infinity: they have 5.0 where, in experimental?
[06:24] <infinity> neuralis: Nope, we've shoved it into sid as well.
[06:24] <infinity> neuralis: 4.0 and 4.1 are both going/gone.
[06:24] <neuralis> cool. i, for one, welcome our new 5.0 overlords.
[06:26] <neuralis> infinity: still need to talk to malcolm and jane about server certification, as there seems to be serious confusion about it.
[06:32] <Znarl> Kamion : Ok, I'll take a look.
[06:32] <infinity> neuralis: I'm not surprised.  It was a bit confusing when we all sat down to discuss it the first time. :)
[06:32] <Kamion> Znarl: thanks
[06:33] <pitti> re
[06:47] <Kamion> yes; die 2.6.12, die
[06:48] <Kamion> we no longer need initrd-tools in main even, do we? since we supported initramfs-tools in breezy
[06:49] <ogra> we had a discussion about it ...
[06:49] <Kamion> nope, was still needed on hppa and ia64 until recently
[06:49] <Kamion> but now those are fixed
[06:49] <ogra> oh
[06:49] <ogra> kick it out then :)
[06:49] <Kamion> in process
[06:54] <Diziet> *blink*  Brad Bollenbach has just sent a 0.5Mb TIFF to the launchpad-users list.  Is this considered normal behaviour over there ?
[06:57] <Diziet> No, you stupid Emacs, I do not want to display the image in my Emacs frame !
[06:59] <ogra> Kamion, really ? 
[06:59] <Kamion> yes, was just waiting on the initrd-tools fix
[06:59] <ogra> Kamion, didnt we want to drop unused kernel sources to avoid confusion ? 
[06:59] <pitti> why not drop it completely?
[06:59] <Kamion> dropping is up to elmo
[06:59] <ogra> ah
[06:59] <Kamion> I tend not to do removals, much easier to get those wrong
[07:00] <Kamion> demotion is reversible
[07:02] <Kaloz> hmz
[07:03] <Kaloz> as noone else have an idea, I ask it here :P
[07:03] <Diziet> `Launchpad could not import this OpenPGP key, because  at http://keyserver.ubuntu.com:11371/pks/lookup?search=0x67F23500&op=get. Check that you published it correctly in the'
[07:03] <Diziet> etc.
[07:04] <Kaloz> so, it seems like hdparm and the kernel doesn't detect the cache on my notebooks hdd. anyone can give an idea where to look for fixing this problem?
[07:04] <Kinnison> Diziet: keyserver sync time issues
[07:04] <Kinnison> Diziet: there's a bug filed about it already
[07:08] <Diziet> Is keyserver.ubuntu.com not one machine then ?
[07:09] <Treenaks> Kaloz: the 'Write cache enabled' bit is writable, not readable, afaik
[07:10] <Kinnison> Diziet: *nod*
[07:10] <Kaloz> Treenaks: nah, i mean dmesg prints out the cache size in the hdd
[07:10] <Kinnison> ciau
[07:10] <Kaloz> Treenaks: but just googled around more, it seems some toshiba-specific problem.. or better call it lack of support
[07:11] <Kaloz> Treenaks: eg. hdparm says "BuffType=unknown, BuffSize=0kB"
[07:11] <Diziet> They're going to love https://launchpad.net/malone/bugs/28908 too.
[07:11] <Ubugtu> Malone bug 28908: "phishing vulnerability" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
[07:12] <Diziet> Thank you, stupid bot.
[07:12] <Diziet> I'm particularly impressed by "a??phishing vulnerabilitya??" (which is how it looks in my - admittedly prehistoric - IRC client.)
[07:12] <Treenaks> Diziet: it loves you too :P
[07:13] <Treenaks> Diziet: it looks fine in my UTF-8-enabled setup
[07:13] <Diziet> Oh, I, see, another Kuhn-
[07:13] <Diziet> induced braindamage.
[07:13] <Treenaks> with nice rounded quotes
[07:14] <Diziet> (To be fair, Markus Kuhn just vigorously promulgated the problem; he didn't actually introduce it in ISO646.)
[07:38] <mdke> what package is this a bug in: when my screen greys out (e.g. gksudo password prompt), after it comes back to normal it fades in but then flashes once.
[07:38] <mvo> mdke: gksu
[07:40] <mdke> mvo, thanks
[07:41] <Bicchi> what kernel version is going to be on dapper?
[07:42] <Burgwork> Bicchi, .15
[07:42] <mdke> mvo, i've confirmed https://launchpad.net/distros/ubuntu/+source/libgksu1.2/+bug/5970, which was assigned to you coincidentally :)
[07:42] <Ubugtu> Malone bug 5970: "Flicker when fading back in after password prompt" Fix req. for: libgksu1.2 (Ubuntu), Severity: Normal, Assigned to: Michael Vogt, Status: Confirmed
[07:43] <Bicchi> Burgwork: any chances on using .16
[07:43] <bddebian> Howdy
[07:44] <mvo> mdke: we fixed that in the past why removing the fadeout screen before the release :) I personaly like it because it shows that something pretty big is going on (you become root), but our usability team is not really keen on it. 
[07:44] <Burgwork> Bicchi, not by deafult
[07:44] <Kamion> Bicchi: no, will be too new
[07:44] <mvo> mdke: what is likely to happen is that we remove the fade-effect again
[07:44] <Kamion> we can backport individual targeted fixes if need be, but we need a bit more stability than we can count on for 2.6.16 at the point of dapper release
[07:44] <Kamion> as in, more time to stabilise
[07:45] <mdke> mvo, ah, how about using the fade but eliminating the irritating flicker
[07:45] <Bicchi> does anyone knows when the upgrade to mono will be on backports. from what i understand they are having problems building the 1.1.1X series
[08:48] <wftl> Hello all.  Other than the Evolution alarms applet and the sound level applet, are there any apps that get swallowed into the notification area in Dapper? Now that Sound Juicer replaces the CD player, I'm having trouble finding anything that is specific to the NA.
[08:48] <tseng> gaim, gajim, banshee, muine, blam, tomboy, beagle
[08:48] <tseng> (i could go on)
[08:48] <tseng> its used by many apps
[08:50] <tseng> wftl: the mixer applet isnt a notification applet, either
[08:50] <tseng> its seperate
[08:50] <wftl> tseng : Thanks, I just couldn't see to launch an app that wound up there. Appreciate the clarification on the mixer applet.
[08:52] <wftl> Of course, of the apps you mentioned, the only one in a default Ubuntu install is GAIM.
[08:52] <seb128> rhythmbox
[08:53] <wftl> seb128, excellent. I'll add that to the description. 
[08:53] <seb128> description of what? (just curious)
[08:53] <wftl> Sorry, my next book is on Ubuntu.
[08:54] <tseng> "next"?
[08:54] <wftl> tseng : http://www.marcelgagne.com/mybooks.html
[08:54] <wftl> I just like to make sure I keep my facts straight.
[08:55] <wftl> :-)
[08:55] <seb128> hehe
[08:55] <tseng> hm quite a few books
[08:55] <wftl> I like to keep busy.
[09:01] <wftl> tseng : seb128 : in case you are curious -- http://www.aw-bc.com/catalog/academic/product/0,1144,032142722X,00.html
[09:02] <seb128> wftl: nice!
[09:02] <tseng> ya
[09:03] <sivang> wftl: are you working with Marjan Bace, or Blace Bace ?
[09:05] <wftl> sivang, no, I'm not. 
[09:06] <wftl> I'm sorry to say I don't know either of them.
[09:06] <sivang> wftl: just a sec, I'll toss you the link of the publisher house, AFAICT they are also working on a book
[09:07] <wftl> Always good to know these things, sivang. :-)
[09:07] <sivang> wftl: http://www.manning.com/
[09:07] <wftl> As far as I know there are two other books being worked on right now, all due to appear before June.
[09:07] <sivang> cool :)
[09:07] <sivang> you have links?
[09:08] <Burgwork> sivang, there are many books in the works, inlcuding an oreilly one
[09:09] <sivang> Burgwork: nce to know that, the oreilly one is probably gonna be good
[09:10] <wftl> There's one by somebody named Keir Thoman, at APress, called "Beginning Ubuntu Linux : From Novice to Professional"
[09:10] <wftl> The Manning Press one is "Desktop Linux with Ubuntu" by Mark Stone.
[09:11] <Burgwork> sivang, not that I know of
[09:11] <wftl> Aside from my own "Moving to Ubuntu Linux", I don't know of any others.
[09:12] <Burgwork> http://www.oreilly.com/catalog/ubuntuhks/
[09:12] <jdub> wiki.ubuntu.com/UbuntuBooks
[09:13] <jdub> ha ha -> Tips & Tools for Humanizing Linux
[09:14] <Burgwork> sivang, Jono is writing a book?
[09:15] <ogra> grrr
[09:15] <ogra> crashy thing
[09:16] <sivang> Burgwork: wrote, it seems http://www.oreilly.com/catalog/linuxdeskhks/
[09:22] <Burgwork> sivang, ah
[09:28] <crimsun> elmo: please sync rxvt-unicode from Sid, discarding Ubuntu changes
[09:42] <Nafallo> giftnudel: your nick means poisonnoodle in Swedish :-)
[09:43] <mbreit> Nafallo: here in germany (and giftnudel seems to be german) it means the same ;)
[09:43] <giftnudel> that's what it's supposed to mean (although originated in german)
[09:44] <Nafallo> hehe, oki :-)
[09:45] <sivang> nice, how good shape is that in? http://doc.ubuntu.com/ubuntu/packagingguide/C/
[09:47] <sivang> Burgwork: ^^
[09:47] <Burgwork> sivang, being worked on actively, by LaserJock 
[09:47] <sivang> very , and I mean, very cool
[09:47] <LaserJock> oh, it will be better
[09:49] <LaserJock> sivang: I'm doing a complete rewrite right now
[09:50] <sivang> ah, I was sure http://debiansystem.info/ was open source book, that is downloadable somehwere
[09:50] <sivang> LaserJock: nice, the strucutre looks very good
[09:50] <LaserJock> sivang: the outline of what I'm doing is at wiki.ubuntu.com/UbuntuPackagingGuide
[09:51] <LaserJock> sivang: I didn't write what is on doc.ubuntu.com. That was Unfrgiven
[09:51] <kosmokramer> must go today 2 alienware laptops price 550 each including shippin case and wireless router, or 1 alienware desktop at 550 including shipping, monitor, speakers, keyboard and mouse and of course the tower. message me on aim at mikcomputing, msn at mcsltd3@hotmail.com or yahoo at mcsltd2 if interested and want to buy
[09:53] <Burgwork> any ops to kick the bastard?
[09:55] <sivang> heh
[09:55] <Burgwork> sivang, how goes home user backup?
[09:56] <sivang> Burgwork: stalled for the last 2 days, I'm still at work. suddenly we need to release after endless QA cycles...
[09:59] <Burgwork> sivang, isn't it midnight+ there?
[10:00] <sivang> Burgwork: yep :)
[10:02] <sivang> Burgwork: to see some code, you can visit http://mercury.linuxguru.net/~sivan/home-user-backup/utilities/
[10:02] <kosmokramer> must go today 2 alienware laptops price 550 each including shippin case and wireless router, or 1 alienware desktop at 550 including shipping, monitor, speakers, keyboard and mouse and of course the tower. message me on aim at mikcomputing, msn at mcsltd3@hotmail.com or yahoo at mcsltd2 if interested and want to buy
[10:02] <sivang> that's a week old snapshot , I have more I haven't push'd yet
[10:02] <sivang> oh bullocks,
[10:02] <sivang> .
[10:06] <wftl> I've noticed that Nautilus doesn't preview JPG files.  Is this a patent issue?
[10:07] <infinity> wftl: It does here.
[10:07] <infinity> wftl: Are you viewing them over a network?.. It won't do previews on samba shares and the like (to conserve bandwidth, and make the window not take 20 minutes to load)
[10:07] <wftl> infinity, they are local files on a Dapper system.
[10:08] <wftl> If I convert them to png, they display fine.
[10:08] <torkel> wftl: how big are they?
[10:08] <wftl> torkel, this one is 155K
[10:09] <torkel> wftl: that should be small enough :-)
[10:09] <wftl> a 62K file doesn't work either.
[10:09] <wftl> Interesting.
[10:27] <dholbach> doko, infinity, mdz: the problem with a newer bittorrent is debian bug 298814 - I
[10:27] <Ubugtu> Debian bug 298814: "New upstream version available" Package: bittorrent, Version: 3.4.2-3, bittorrent/3.4.2-5., Severity: wishlist, Maintainer: Michael Janssen  http://bugs.debian.org/298814
[10:27] <dholbach> doko, infinity, mdz: 'm not license expert enough to judge this.
[10:28] <Burgwork> dholbach, I wouldn't touch the new version
[10:28] <dholbach> Burgwork: oh?
[10:29] <Burgwork> dholbach, the mirror thing. The choice of venue is legal stuff I don't understand
[10:34] <infinity> dholbach: Looks problematic to me, yes.
[10:35] <dholbach> infinity: so I'll do just the LSBifying.
[10:37] <infinity> dholbach: Hrm.  The license at http://www.bittorrent.com/license/ doesn't seem to have the mirroring verbage... Or I can't find it.
[10:40] <dholbach> infinity: hrm.
[10:41] <Burgwork> infinity, seems to be fixed
[10:41] <infinity> dholbach: If the sources you download contain an exact copy of the license at that URL, it doesn't seem to have the same problems mentioned in the bug report.
[10:41] <infinity> dholbach: The source distribution clauses in that license are basically the same as the GPL, which is fine for us.
[10:41] <Burgwork> infinity, I am looking at a tarball of 4.5.3
[10:42] <infinity> Burgwork: Is it the same as http://www.bittorrent.com/license/ ?
[10:42] <Burgwork> infinity, I will diff it
[10:42] <infinity> Burgwork: If so, I'd say it's all good.
[10:42] <dholbach> We should follow up on the bug report, if the license is good and get exception for the sync.
[10:42] <infinity> Oh, wait.  It still has the choice-of-venue clause hidden at the end.
[10:43] <dholbach> He'll have to re-do big parts.
[10:43] <infinity> Section 13.
[10:43] <Burgwork> infinity, no difference, and the source for 12 months appears to be gone
[10:44] <dholbach> No bittorrent in main then.
[10:44] <infinity> dholbach: You might want to ping mdz to get his gut feeling on how Ubuntu feels about choice-of-venue.  Debian tends to consider it non-free, but it's a fairly pedantic view.
[10:45] <Nafallo> we DO have bittornado in main, no? :-)
[10:45] <dholbach> Nafallo: and gnome-btdownload
[10:45] <infinity> gnome-btdownload uses bittorrent as a backend.
[10:46] <mdz> infinity: context?
[10:46] <Nafallo> I wonder how hard it would be to have it use bittornado instead :-P
[10:46] <infinity> mdz: http://www.bittorrent.com/license/ -- Section 13.
[10:46] <infinity> mdz: Do we consider that non-free?
[10:46] <Burgwork> dholbach, why do we have bittorrent and bitornado  in main?
[10:46] <dholbach> mdz: concerning the bittorrent update before UVF - they changed the license in the meantime, which kept the Debian maintainer from packaging it.
[10:47] <infinity> Everything else in the license (granted, I was speed-reading) seems fine to me.
[10:49] <dholbach> Burgwork: no idea.
[10:49] <Burgwork> dholbach, as part of ReducingDuplication, we should throw one out
[10:50] <Kamion> desktop: * gnome-btdownload       # simple GNOME frontend for bittorrent downloads
[10:50] <Kamion> supported: * bittorrent             # rapid p2p download, for efficient large file distribution, perhaps for desktop
[10:50] <Kamion> supported: * bittornado             # used on the servers.
[10:50] <Kamion> yay seed comments
[10:50] <Burgwork> ah
[10:50] <infinity> I take it bittornado's tracker is superior to bittorrent's?  Or we just preferred it at one stage?
[10:51] <Nafallo> so we need a gui for bittornado so we can throw bittorrent out? ;-)
[10:51] <Burgwork> Nafallo, you should be able to rework gnome-bt to use it
[10:51] <Kamion> Burgwork: the seed comments *are* kind of hidden in a basement behind a sign saying "beware of the leopard", but anyway ...
[10:52] <Kamion> infinity: if it's superior to bittorrent's, I shudder to think what bittorrent's tracker must be like; the bittornado one apparently really sucks
[10:52] <Kamion> but it's possible it's still better for all that
[10:52] <Burgwork> Kamion, yes, I but I have looked at them before
[10:52] <Burgwork> Nafallo, if you relaly want to make me happy, finish http://www.amedias.org/~koke/gnome-torrent/ and get it installed by default
[10:53] <infinity> Kamion: Could have just been a case of "first tool we tried, and never switched"... Might be worth pinging elmo/Znarl about in the interest of ReducingDuplication.
[10:53] <ogra_> grrr
[10:53] <Nafallo> Burgwork: well, my sparetime starts to get limited atm :-/.
[10:53] <infinity> Kamion: Heck, most people weren't even aware that bittorrent shipped a tracked until the init script showed up a month ago.
[10:53] <ogra_> why is g-v-m crashing constantly for me on amd64 ? 
[10:53] <infinity> s/tracked/tracker/
[10:53] <j^> bittornado added support to share all torrents on one port first; bittorrent should be able to do that now too
[10:53] <dholbach> ogra_: it does on i386 too and pitti is investigating it.
[10:54] <ogra_> dholbach, g-p-m as well :/
[10:54] <ogra_> dholbach, but you will love me, i switched g-p-m to cdbs for consistency with the rest of the gnome pkgs
[10:55] <dholbach> ogra_: Wow! How did that happen?
[10:55] <j^> Burgwork did you look at freeloader?
[10:55] <dholbach> elmo: Could you please remove evolution-caldav from the archive? The code went into evolution-data-server.
[10:55] <ogra_> i guess it will be adopted by the debian gnome team one day, so i thought it should use the same packaging system
[10:56] <Burgwork> j^, nope
[10:56] <j^> Burgwork its in universe
[10:57] <Burgwork> j^, their screenshots show some suspicous download activity ;) http://www.ruinedsoft.com/freeloader/1.png
[10:59] <mdz> infinity: not clearly; only if we were to interpret it as discriminating against persons/groups/fields of endeavor
[11:00] <mdz> dholbach: if it's questionable, let's not force it
[11:00] <dholbach> mdz: my take too.
[11:00] <dholbach> So I'll just clean up the init script.
[11:01] <sivang> hey mdz 
[11:01] <Nafallo> daniels: thanks! :-)
[11:01] <daniels> Nafallo: hm?
[11:01] <Nafallo> daniels: re #28911 ;-)
[11:01] <daniels> oh, no worries
[11:03] <mvo> anyone interessted in testing the dist-upgrade feature of update-manager for the breezy->dapper upgrade? add "deb http://people.ubuntu.com/~mvo/update-manager /" to your sources.list and install update-manager then. it will offer you a dist-upgrade to dapper then.
[11:04] <seb128> mdz: do we want gaim 2.0 for dapper? They should have the 2.0 beta 2 out soon but no fixed calendar afaik (they planned 2.0 for december but delayed after feedback from beta 1)
[11:04] <seb128> s/calendar/schedule
[11:04] <ogra> soounds risky ...
[11:05] <Burgwork> mvo, anything we should be watching for in particular?
[11:05] <Nafallo> let's put gajim in main ;-)
[11:05] <Burgwork> shipping without it means bad PR
[11:05] <jdub> seb128: as gaim2 maybe :-)
[11:05] <ogra> jdub, in universe ?
[11:05] <dholbach> ogra: in dapper-backports :)
[11:06] <ogra> lol
[11:06] <mvo> Burgwork: it should (hopefuly) be self-explained. you can back-out, no worries :)
[11:06] <Burgwork> mvo, no, in a testing sense. Any place where you think it might break
[11:07] <seb128> jdub: hum, could do that ... but there is still the question to know if that's an UVF potential exception
[11:07] <mvo> Burgwork: I'm mostly interessted in seeing how it copes with "real" systems, not my test-systems (where it does a pretty good job calculating the upgrade)
[11:07] <OpsVentus> Right now I'm using Qt3 for GUI (in combination with c++) but now I'm thinking about updating to Qt4 but this is a large change, so I want to check if Qt4 is the way to go or if there's a better cross-platform(mainly KDE/GNOME/Windows/OSX) toolkit for small programs?
[11:08] <OpsVentus> So what's everybody's opinion?
[11:08] <Burgwork> mvo, ok
[11:08] <dholbach> OpsVentus: You'd better ask in #kubuntu.
[11:09] <OpsVentus> dholbach: but I program in GNOME and want the program's to work good in GNOME, still #kubuntu?
[11:09] <spacey> OpsVentus, wxwindows?
[11:10] <OpsVentus> spacey: why's wxWindows better?
[11:10] <dholbach> OpsVentus: If you ask about QT4, they might have more expertise with it.
[11:10] <OpsVentus> ok, gonna go there
[11:11] <spacey> OpsVentus, no idea, just know its crossplatform :p
[11:11] <mdz> doko: why internal neon for openoffice.org?
[11:11] <OpsVentus> yeah, so is qt
[11:11] <ogra> or gtk
[11:12] <mdz> doko: is it a big project to update it for new libneon?
[11:14] <mdz> seb128: if it doesn't have a credible schedule, I think we probably shouldn't
[11:14] <doko> mdz: it's temporary, just wanted OOo to be installable again
[11:15] <seb128> mdz: should we package it as gaim2 and switch it 2.0 comes soon?
[11:15] <seb128> s/it/if
[11:16] <mdz> seb128: if you have time to do the extra work, sure
[11:16] <Nafallo> gaim2 would have the benefits of testing and community love (atleast in #ubuntu.se).
[11:17] <seb128> mdz: hum, good point. I'll try to find somebody motivated to do it if possible ... :)
[11:18] <ogra> sivang, thanks i need it ..
[11:19] <sivang> ogra: you're welcome, always.
[11:19] <ogra> :)
[11:30] <Nafallo> daniels: did you ever upload the fixed x11-common? I can't see it on dapper-changes.
[11:32] <OpsVentus> I wrote a Sudoku game, any intressed to include this in (K)Ubuntu?
[11:32] <ogra> OpsVentus, #ubuntu-motu 
[11:32] <OpsVentus> ok
[11:33] <ogra> but given the fact that we have UVF tomorrow, its unlikely that you can get it in in time
[11:33] <daniels> Nafallo: 'fix committed', not 'fix released' ;) just sorting out clean chroot testing
[11:34] <OpsVentus> then next release or something
[11:35] <Nafallo> daniels: oh. I thought committed was uploaded :-P. but okey :-).
[11:36] <daniels> aiui, bugzilla -> malone terminology is PENDINGUPLOAD -> Fix Committed, RESOLVED/FIXED -> Fix Committed
[11:36] <daniels> er
[11:36] <daniels> the latter should be Fix Released
[11:36] <ogra> uploaded :)
[11:36] <daniels> i guess it assumes we're all using version control
[11:36] <lucas> problem is that malone sometimes considers that fix commited bugs are "fixed"
[11:36] <lucas> and doesn't display them in normal listings
[11:37] <lucas> (I opened a bug about this)
[11:37] <daniels> oh, cool
[11:38] <Nafallo> hehe, go bzr! :-)
[11:47] <theine> Are there any guide lines on when a certain bug is to be specified as minor,normal,major,etc...?
[11:48] <theine> I mean classified...
[11:49] <infinity> theine: If it's a small annoyance or typo or something, it's minor, if it's like 99% of most bugs, it's normal, if it seems like a bug that would affect EVERYONE and be a big hindrance, it's major, if it's OH MY GOD, THE WORLD IS CRASHING IN AROUND US, IF IT'S NOT FIXED, NO ONE CAN USE THEIR COMPUTERS, it's critical.
[11:49] <dooglus> sivang: I am.
[11:50] <dooglus> sivang: (in response to "14:54 < sivang> dooglus: are you Chris Moore ?")
[11:50] <theine> infinity, thanks, I didn't expect the bar for critical to be that high
[11:51] <daniels> theine: critical is HOLY SHIT YOU MUST DROP EVERYTHING NOW TO FIX THIS
[11:51] <theine> So a reproducible bug that leads to a system freezy every time on certain hardware is to be clasified as normal?
[11:51] <theine> daniels, ok, good to know...
[11:51] <daniels> theine: it's the bug equivalent of your boss calling you at 3am because a fortune 50 customer's site is down
[11:51] <Kamion> generally people shouldn't report bugs at critical; leave it to developers to do that triage
[11:51] <daniels> theine: probably major there
[11:51] <Kamion> otherwise we just get into the habit of downgrading critical bugs at sight, which of course has its own problems :)
[11:52] <infinity> theine: Depends on the popularity of the hardware and the driver in question, really.  If it's, say, a very common IDE controller, and it happens for everyone, that's major.  If it's an obscure USB wireless dongle that you and one other guy own, it's probably normal.
[11:53] <sivang> dooglus: oh hi :) I already updated the bug report, as you might have already seen
[11:53] <theine> infinity, I'm actually refererring to this: https://launchpad.net/malone/bugs/28544
[11:53] <Ubugtu> Malone bug 28544: "kernel BUG at net/ieee80211/ieee80211_geo.c:81! (2.6.15-12.17)" Fix req. for: network-manager (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
[11:53] <ogra> lol
[11:54] <ogra> we just discussed this one in #ubuntu-bugs :)
[11:54] <infinity> Well, it would be helpful if that wasn't filed against network-manager. :)
[11:55] <ogra> yup :)
[11:55] <theine> infinity, exactly, that leads me to my next question. How does one go about transferring the bug to linux-source or whatever?
[11:56] <theine> ogra, and I guess it was decided to classify it as having normal severity?
[11:56] <ogra> yes
[11:56] <sivang> dooglus: thanks for the patch. programs should never exit with a segfault/coredump.
[11:57] <theine> ogra, but the reason is not that network-manager is not in main, is it?
[11:58] <ogra> theine, the reason is that network-manager breakage is no reason to classify anything as critical
[11:58] <ogra> or major ...
[11:58] <infinity> theine: What version does your ipw2100 driver report in dmesg when it's loaded?
[11:58] <theine> ogra, well, it's actually linux kernel breakage
[11:58] <dooglus> sivang: yes, I saw thanks.
[11:58] <ogra> theine, thats the prob ...
[11:58] <theine> infinity, 1.1.3 and I guess that's the problem. it should be 1.1.4
[11:59] <infinity> theine: Yup.  1.1.4 resyncs with ieee80211-1.1.7
[12:00] <infinity> theine: Bugged BenC about it.  Should be fixed in the next kernel upload.
[12:00] <dooglus> sivang: it was a strange one.  I hadn't looked into glib before, but the memory allocation is strange.  the call to "free" actually changes the contents of the memory it's freeing.
[12:00] <theine> infinity, cool, thanks
[12:01] <ogra> theine, change the bug to fix pending ;)
[12:01] <theine> ogra, okidoki
[12:01] <Burgwork> theine, transfering a bug is a beast in LP
[12:02] <ogra> ARGH....