[12:07] <thully> Just tried new live CD - my X problems are fixed (in fact I'm typing from it now)
[12:07] <thully> downloading install cd now
[12:08] <amu> thully: .7 ? 
[12:08] <thully> .6, actually
[12:08] <mdz> sladen: ping?
[12:08] <thully> there is already a new one!
[12:09] <mdz> .6 was an i386-only build to test whether the X fix worked
[12:09] <mdz> it did, so I built .7 for i386/amd64/powerpc/ia64
[12:09] <thully> is there any difference?
[12:09] <mdz> no functional difference on i386, no
[12:09] <thully> Also, is there a chance that .7 will be array 4?
[12:09] <mdz> there is a chance, yes
[12:09] <mdz> if all tests succeed
[12:10] <thully> I'm downloading install cd build now
[12:18] <AndyR> lo ppl
[12:40] <dholbach> i'm off to bed guys... my thighs, my lower legs... everything hurts :-) *wave*
[01:12] <bluefoxicy> you know
[01:12] <bluefoxicy> that could really piss someone off.
[01:12] <bluefoxicy> I upgraded to 2.6.10-2-amd64-generic or something
[01:12] <bluefoxicy> and upon loading 8139too
[01:12] <bluefoxicy> the kernel breaks
[01:12] <bluefoxicy> junk is spewed to the terminal
[01:13] <bluefoxicy> and the root filesystem (xfs) gets corrupted.
[01:13] <bluefoxicy> miiiiiiiiight want to not do that.
[01:13] <bluefoxicy> but I've reinstalled now, manually, breaking the install process and now I don't know how to set my default console keymap to dvorak
[01:13] <bluefoxicy> also I don't know how to generate the prettified/automated /boot/grub/menu.lst since grub-install (in the installer) never works.
[01:14] <bluefoxicy> anyone know how to fix my keymap and timezone up?
[01:14] <mdz> grub is broken on amd64 at the moment, but there is a known workaround
[01:14] <mdz> this is all in bugzilla
[01:14] <bluefoxicy> I know how to make grub work manually (grub, root (hd0,0), setup (hd0)
[01:15] <bluefoxicy> mdz:  how about keymap?  that in bugzilla?  (I broke that, not you, so I'd imagine not)
[01:15] <mdz> that's fallout from the installer breaking
[01:15] <bluefoxicy> yeah
[01:15] <mdz> so if you go back and use the workaround, that'll take care of itself
[01:16] <bluefoxicy> Can I get a hint on what ot search bugzilla for?
[01:17] <Kamion> mdz: there isn't a known workaround that works when booting from CD, unfortunately
[01:17] <Kamion> bluefoxicy: grub doesn't work manually like that right now, AFAIK; it's being hit by a kernel bug, it's not an installer bug
[01:18] <elmo> oh dear god, what's mdz done to the seeds
[01:18] <mdz> elmo: oo.o2
[01:18] <mdz> and thereby kdelibs
[01:18] <Riddell> oh goody
[01:18] <mdz> how bad is it?
[01:19] <bluefoxicy> Kamion:  I just installed grub like that
[01:19] <bluefoxicy> Kamion: problem is ubuntu still stops and doesn't installa  proper menu.lst
[01:19] <Kamion> bluefoxicy: that's surprising, since it doesn't work for me
[01:19] <bluefoxicy> I forgot how to trick it into thinking it worked (I killed a certain process and it did it)
[01:19] <Kamion> it is grub's 'install' command (called by 'setup') that triggers the segfault
[01:20] <bluefoxicy> hum.
[01:20] <mdz> perhaps you used a different grub
[01:20] <elmo> mdz: only 7 new source packages; it's just the biggest change in a while, shocked me
[01:20] <mdz> though, that wouldn't help, would it
[01:20] <Kamion> although grub-install may use somewhat different arguments, actually
[01:20] <bluefoxicy> mdz:  hoary amd64 install cd
[01:20] <Kamion> mdz: no, that would imply that it was grub's fault, which it isn't
[01:20] <bluefoxicy> Kamion:  I just use setup (hd0)
[01:20] <Kamion> unless you count using nested functions as "fault"
[01:20] <bluefoxicy> after using root
[01:21] <bluefoxicy> o_o
[01:21] <bluefoxicy> nested functions are the children of satan
[01:21] <Kamion> grub-install does setup --stage2=/boot/grub/stage2 --prefix=/boot/grub (hd0)
[01:21] <Kamion> or similar
[01:21] <mdz> bugzilla is hiding it
[01:21] <lamont> ok. so, no matter how well you swim, everyone where PFD's while you're in a boat.  'k?
[01:22] <lamont> mdz: ia64 cloop runs 40-50 min, iirc
[01:22] <mdz> maybe fabbione WONTFIXed it :-P
[01:22] <lamont> mdz: flushing it is easy - just tell me when you want to pay the pain... Do you want to flush all 4, or just ia64/amd64?
[01:22] <pitti> night everybody
[01:22] <mdz> pitti: night
[01:22] <mdz> lamont: I think RC would be a good time
[01:22] <Kamion> bluefoxicy: there is no workaround that works on the install CD, as far as I'm aware.
[01:22] <mdz> Kamion: the noexec=off or whatever doesn't help?
[01:23] <Kamion> bluefoxicy: somebody who actually understands this nx bit crap needs to look at it
[01:23] <bluefoxicy> Kamion:  what about regenerating /boot/grub/menu.lst
[01:23] <Kamion> bluefoxicy: update-grub does that
[01:23] <Kamion> mdz: that works around the bug in an installed system, but for some reason not when booting from CD
[01:23] <mdz> bluefoxicy: #6082
[01:23] <Kamion> mdz: I have absolutely no idea why
[01:23] <bluefoxicy> Kamion:  yeah an NX-bit may kill nested functions
[01:23] <Kamion> bluefoxicy: it bloody well shouldn't, that's what PT_GNU_STACK is for!
[01:23] <bluefoxicy> mdz:  thatnks, I was on 5059 or such
[01:24] <tseng> bluefoxicy: emuplt?
[01:24] <Kamion> the entire design of all of that was to *prevent* it killing nested functions
[01:24] <bluefoxicy> tseng:  emutramp?
[01:24] <tseng> bluefoxicy: yes.
[01:24] <tseng> that.
[01:24] <Kamion> and /sbin/grub correctly has an executable bit set in its PT_GNU_STACK program header, which is being correctly read by the kernel
[01:24] <bluefoxicy> tseng:  yeah, better design than PT_GNU_STACK for nested functions, but I didn't want to bring PaX into this
[01:25] <tseng> is this kernel.org NX then?
[01:25] <bluefoxicy> Kamion:  odd.
[01:25] <bluefoxicy> hmm
[01:25] <Kamion> as far as I can tell, the memory management layer that's supposed to make the page executable simply isn't working properly in 32-bit mode, or something weird like that
[01:25] <bluefoxicy> tseng:  vanilla ignores PT_GNU_STACK?
[01:25] <tseng> no
[01:25] <Kamion> although I tried with a trivial 32-bit example and it seemed to work
[01:25] <Kamion> tseng: yes
[01:25] <Kamion> vanilla 2.6.10 does not ignore PT_GNU_STACK
[01:26] <tseng> dumb question, does the app have the markings?
[01:26] <Kamion> tseng: 00:24 < Kamion> and /sbin/grub correctly has an executable bit set in its PT_GNU_STACK program header, which is being correctly read by the kernel
[01:26] <bluefoxicy> Kamion:  ahh, I've noticed with PaX that relocations are still killed in 32 bit on 64 bit kernels, even though PaX is set to allow relocations (as a legacy option until all relocations are removed from 99% of all code at least)
[01:26] <tseng> right..
[01:26] <Kamion> bluefoxicy: that sounds similar
[01:26] <bluefoxicy> Kamion:  this may be a similar issue due to the design of the kernel, but I don't know.
[01:26] <bluefoxicy> pipacs doesn't seem to know wtf is wrong with it either, last i asked
[01:26] <mdz> Kamion: confirmed that noexec=off doesn't fix it when booting from the live CD, how weird
[01:26] <Kamion> I reported to linux-kernel and there was no response
[01:27] <tseng> maybe mingo was too busy trolling pagexec
[01:27] <bluefoxicy> XD
[01:27] <Kamion> mdz: it certainly baffled me
[01:27] <bluefoxicy> tseng:  vanilla has no execshield though
[01:27] <Kamion> *sigh* can we not get into inter-security-group flamewars here please?
[01:27] <tseng> bluefoxicy: bits and pieces
[01:28] <mdz> Kamion: aha
[01:28] <bluefoxicy> Kamion: I'm trying so hard not to
[01:28] <Kamion> it can't be that hard
[01:28] <mdz> Kamion: noexec32=off ?
[01:28] <Kamion> mdz: that option was removed, last I checked
[01:28] <mdz> oh
[01:28] <Kamion> mdz: (you could always try it though ...)
[01:28] <bluefoxicy> heh
[01:30] <wasabi> darn grub
[01:30] <wasabi> argh
[01:30] <wasabi> clean install still just boots to a blinking cursor
[01:34] <mdz> Kamion: doesn't help
[01:34] <mdz> confirmed that neither noexec nor noexec32 help on the CD boot, but noexec does on the hard disk boot
[01:34] <mdz> maybe something with the command line parsing?
[01:35] <Kamion> could be, but that would be ... strange
[01:35] <Kamion> mdz: you could try editing syslinux.cfg and putting noexec=off on it earlier on?
[01:35] <mdz> that's the only interesting difference I can think of
[01:35] <Kamion> although I think Kurt Roeckx said that didn't help, iirc
[01:37] <thully> just finished installing from latest install build... looks good, and at least in my experience is Array 4-ready
[01:39] <thully> well, network applet crashes when you open it and quit it - that's the one new thing I've seen so far
[01:39] <Kamion> netapplet recently got uploaded ...
[01:40] <mdz> Kamion: hmm
[01:40] <thully> I will try dist-upgrade and see if that fixes it
[01:41] <mdz> Kamion: parse_cmdline_early uses memcmp for comparison, while nonx_setup (now called from it) uses strcmp
[01:41] <mdz> i.e., the string is not null-terminated
[01:41] <mdz> or may not be
[01:41] <Kamion> thully: I was more thinking that it might have been introduced by that
[01:42] <Kamion> mdz: hmm
[01:42] <mdz> I would naively expect that it would still work if noexec were the last parameter on the command line
[01:42] <lamont> Kamion: wrt ia64 boot magic - I assume that we'll create a separate boot image for livecd eventually, yes?
[01:42] <mdz> but that's exactly where it should be ending up
[01:42] <thully> It happens when you open it and close it quickly afterwards
[01:42] <Kamion> lamont: yeah, that's the plan, or figure out how to push the bootloader config over to debian-cd
[01:42] <lamont> mdz: do you want to flush the images for the RC image, or a few days earlier, so that some of us can sync the bulk of the CD before the RC ships?
[01:43] <lamont> Kamion: cool
[01:43] <mdz> lamont: I want to flush them at such a time that it doesn't interfere with rsyncing down iterations leading up to final, but still minimizes fragmentation
[01:45] <bluefoxicy> um
[01:45] <lamont> mdz: right.  and that requires a compromise between the two extremes, I think...
[01:45] <bluefoxicy> still wondering about that keymap thing
[01:45] <mdz> please take that to #ubuntu
[01:45] <Kamion> mdz: I find it slightly puzzling that __supported_pte_mask is not set to _PAGE_NX by default
[01:46] <Kamion> unless I'm missing something
[01:46] <mdz> Kamion: got it
[01:46] <mdz> Kamion: on the CD boot, 'console=tty0' ends up after noexec
[01:46] <Kamion> oh, syslinux adds that?
[01:46] <mdz> so I think changing strcmp->(strncmp|memcmp) will at least get noexec working properly
[01:46] <mdz> apparently so
[01:47] <Kamion> funky
[01:47] <mdz> just checked with the daily-live amd64
[01:47] <mdz> I wonder if it's fixed in bk already
[01:47] <Kamion> I'll do a test build on concordia and bung it into an image
[01:49] <mdz> that should be sufficient to roll an array 4
[01:50] <Kamion> yep
[01:51] <mdz> I can do a round of tests this evening, and you can bless it in the morning, if you like
[01:53] <Kamion> mdz: I'll be up for a bit yet anyway
[01:53] <lamont> mdz: did we want to sync mono 1.0.5 from debian?  that'd cure universe of it's tainted state
[01:53] <mdz> lamont: sure
[01:53] <lamont> 1.0.4 should really not be allowed to ship, since it's ftbfs, and all that...
[01:54] <lamont> tseng: what all do we need to sync for 1.0.5?
[01:54] <tseng> lamont: everything was in the mono source last i looked
[01:54] <tseng> lamont: im doubting it changed from 1.0.4 to 1.0.5 heh.
[01:54] <lamont> tseng: not what I meant... we need to sync mcs_1.0.5-2, what else?
[01:55] <tseng> binary package names?
[01:55] <mdz> so this bug was the first thing that made me realize that this noexec functionality exists upstream now
[01:55] <mdz> does it actually provide us some security?
[01:55] <Kamion> I think it does; stack pages are non-executable by default with any vaguely recently built binary
[01:55] <Kamion> apart from a few wacko cases like grub
[01:55] <mdz> vaguely recent, as in -> likely all of main?
[01:55] <tseng> it certainly does provide a better situation than without
[01:55] <tseng> without any NX that is
[01:55] <Kamion> mdz: the toolchain patches have been in for ages
[01:56] <Kamion> you can look for the PT_GNU_STACK header using readelf -l
[01:56] <elmo> mdz: yes, for modern CPUs
[01:56] <Kamion> if the header isn't there, it's an old binary
[01:56] <tseng> lamont: mcs and all that iirc are all from one source package
[01:56] <Kamion> mdz: oh yeah, you have to have the nx bit available in hardware, as elmo says
[01:56] <tseng> lamont: i will grab it and play along
[01:56] <mdz> if it makes exploitation slightly harder, and we don't pay for it in terms of having to maintain some awful patch, that's excellent
[01:56] <elmo> mdz: the NX stuff in mainline only works with hardware support
[01:56] <Kamion> so it's really new P4s or AMD64 systems
[01:57] <elmo> mdZ: yep
[01:57] <tseng> hm i was unaware that p4s had any NX
[01:57] <mdz> elmo: are our P4s in the DC new enough?
[01:57] <tseng> nocona does not
[01:57] <Kamion> $ readelf -l /bin/ls | grep -A1 STACK
[01:57] <Kamion>   STACK          0x0000000000000000 0x0000000000000000 0x0000000000000000
[01:57] <Kamion>                  0x0000000000000000 0x0000000000000000  RW     8
[01:57] <Kamion> ^-- new binary with non-executable stack pages
[01:57] <Kamion> $ readelf -l /sbin/grub | grep STACK
[01:57] <Kamion>   STACK          0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
[01:57] <Kamion> ^-- new binary with executable stack pages
[01:58] <Kamion> tseng: hm, I thought new P4s did, but I might have been misinformed; I know Intel and Transmeta have adopted the change in some CPUs
[01:58] <mdz> mizar:[/usr/bin]  readelf -l tset | grep STACK
[01:58] <mdz>   STACK          0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
[01:58] <elmo> mdz: the machines will be getting next week maybe; not the existing ones, I don't think
[01:59] <mdz> that's the oldest thing in /usr/bin on my hoary desktop
[01:59] <elmo> s/will/we'll/
[01:59] <Kamion> mdz: you can check by looking in the 'flags' line in /proc/cpuinfo
[02:00] <lamont> tseng: I see mcs, mod-mono, mono, monodevelop, monodoc, monopd.. which of those should we sync is the question...
[02:00] <lamont> or is it really just mcs?
[02:01] <elmo> BOGGLE
[02:01] <tseng> monodevelop i believe will be the same version we have
[02:01] <elmo> http://anandtech.com/cpuchipsets/showdoc.aspx?i=2111
[02:01] <elmo> if that articles true, that may not be such a win
[02:01] <tseng> debian didnt have it at the time so i bumped it and did CDBS love
[02:01] <elmo> specifically the "you must enable PAE" bit
[02:01] <tseng> you can grab the debian one if youd like, non critical
[02:01] <tseng> mcs and mono are the biggies
[02:02] <Kamion> mdz: AMD's NX got marketed as something like "Enhanced Virus Protection" in the Windows world. :-)
[02:02] <elmo> yeah, they got slapped down in several european countries for advertising it like that too
[02:02] <Kamion> not surprised
[02:03] <tseng> lamont: want me to do a test run?
[02:03] <mdz> does EM64T implement it in a non-suck way?
[02:03] <elmo> if you're running in amd64 mode, yeah
[02:03] <tseng> lamont: then i can give you better answers, its been a long time
[02:04] <lamont> tseng: sure - I'm going to start with a sync req for mcs and mono, and we'll take it from there...
[02:05] <tseng> mcs and mono are the core
[02:05] <tseng> the other apps you mentioned are ancillary
[02:05] <tseng> and i havent been tracking all of them in debian, admitedly
[02:05] <lamont> s/sends/has sent/
[02:05] <wasabi> grub or lilo, that is hte question
[02:06] <tseng> i hooked up with meebey and dajobe today, pretty cool guys
[02:06] <mdz> grub is so useful that I am enticed every time, even though it sucks
[02:06] <tseng> so ill be more up on the debian-mono scene soon hopefully
[02:06] <mdz> Kamion: did I talk with you about publishing the install and live CDs together?
[02:07] <mdz> Kamion: in terms of directory layout?
[02:07] <Kamion> mdz: yeah, I thought I'd agreed?
[02:07] <Kamion> oh, maybe not
[02:07] <Kamion> surely /releases/hoary/array-4/hoary-{install,live}-$ARCH.iso?
[02:07] <mdz> yeah
[02:07] <Kamion> with one of those shiny HTML pages?
[02:07] <mdz> I didn't know if that required changes in your publishing infrastructure or not
[02:08] <mdz> definitely shiny
[02:08] <Kamion> oh, probably requires minor changes, but practically every release I do does for one reason or another ;-)
[02:08] <mdz> manual automation :-)
[02:08] <Kamion> it doesn't really matter, I can always move them into place by hand if need be
[02:09] <Kamion> the important thing is to have it not suck for the releases that I have to do in a real hurry (i.e. RC, final)
[02:10] <mdz> do you think it would be at all sensible to build them in a single pass? i.e., merge cron.daily and cron.daily-live, and sync the archive only once so that it's consistent
[02:10] <mdz> s/consistent/guaranteed &/
[02:11] <Kamion> mdz: I think that's just going to increase build time to the point where it frustrates us both when we're trying to build install and live CDs separately
[02:11] <Kamion> although I'm happy to do that as a one-off for array candidates
[02:12] <thully> hi - I just put my laptop to sleep and woke it up, and the clock moved back 5 hrs - why may this happen?
[02:12] <mdz> well, yeah, we would need to be able to limit it when needed
[02:12] <mdz> thully: I think there's a bug open about that
[02:12] <mdz> we need to reset the clock after resume
[02:13] <thully> OK - that's what I thought the problem was
[02:13] <mdz> maybe there isn't one; I can't find it
[02:13] <mdz> I have heard of that problem before at any rate, and it needs to be fixed
[02:16] <Kamion> mdz: hm, is an ISO from 2005-01-13 rsyncable?
[02:16] <Kamion> (live)
[02:16] <thully> OK - I'll make a bug report now
[02:17] <mdz> Kamion: I think the rsyncability began at ~2005-01-20
[02:21] <Kamion> mdz: oh well
[02:21] <lamont> yeah it was the 20th or so
[02:23] <thully> I just filed a bug - #6147
[02:26] <daniels> fabbione: if xorg was failing on sparc, I'd be interested in the logs
[02:27] <thully> I'll go look into this
[02:31] <mdz> Kamion: in a fit of madness today I wrote a little program to sniff around and tell me which version of a package is present in (local mirror, isos, d-i initrds, cloop images) * (i386,amd64,powerpc) on little
[02:32] <mdz> a bit like madison-lite on crack
[02:32] <mdz> maybe this would be useful to you as well?
[02:33] <Kamion> might well be; although I kind of concur with the fit of madness bit ;-)
[02:33] <Kamion> but, cool
[02:37] <thully> Hi - i know what the problem is that's causing the clock issues
[02:37] <thully> it's how hwclock is invoked in the /etc/acpi/resume.sh script
[02:38] <wasabi> this whole language pack idea is curious
[02:38] <wasabi> im not sure I understand it
[02:38] <lamont> mdz/Kamion: want me to have the build{LiveCD,DI} scripts immediately exit, or do you like having the boring output and the tied up terminal?
[02:39] <thully> hwclock doesn't autodetect whether the hardware clock is set to UTC or local time - it assumes based on what options it is invoked with.  If there is no --localtime or no --utc, it will default to the last option used.  If no option was used before, it will default to local time.
[02:39] <thully> in our case, there is no --localtime or --utc, so it assumed local time
[02:40] <lamont> wasabi: the lang pack motivator is to be able to deliver new translations for packages after the release is out the door.
[02:40] <Kamion> thully: so it should source /etc/default/rcS and get it from there, probably
[02:40] <wasabi> ahhh.
[02:40] <wasabi> So, all of the translations for ALL packages are moved into it?
[02:40] <lamont> wasabi: but you're right.  trying to understand it makes brains hurt.
[02:40] <lamont> all of main
[02:40] <wasabi> odd.
[02:40] <wasabi> that sounds like a lot of useless text.
[02:41] <thully> Kamion - yes
[02:41] <wasabi> for instance, if I had a server, headless, no GUI, but I wanted japanese translations of some console programs...
[02:41] <lamont> wasabi: but only for the languages you want, as opposed to having all the languages you don't want in each of the individual packages.
[02:41] <wasabi> I'd need all the translations for all of gnome too?
[02:41] <Kamion> I think it's a net loss as it stands. On the other hand I can see that it'd be a net gain once we have enough translations. Dunno ...
[02:42] <lamont> wasabi: what Kamion said
[02:42] <wasabi> It sounds confusing as hell to me.
[02:42] <wasabi> Like, files for one program are in another heh.
[02:42] <Kamion> well, in another package, but yes.
[02:43] <thully> Kamion: once this is fixed in acpi-support, bug #6147 can be closed
[02:43] <Kamion> wasabi: I think if you think of it in conjunction with the existence of Rosetta it makes a bit more sense
[02:43] <mdz> thully: please add that information to the bug repoert you filed
[02:43] <wasabi> i keep hearing that name
[02:44] <wasabi> but haven't bothred to look it up yet
[02:44] <lamont> wasabi: massive translation project
[02:44] <lamont> (that's the 3 word summary)
[02:45] <mdz> wasabi: you also currently have translations for all languages installed for the packages you have
[02:45] <mdz> wasabi: e.g., 500k * N for gcc
[02:45] <mdz> so it has some gains and some losses
[02:46] <Kamion> it's a question of which multiplier you remove
[02:46] <mdz> we're betting that the language multiplier is going to grow faster
[02:46] <jbailey> I have an initrd-tools bug that only occurs on 2.4.  The bugzilla page suggests that bugs like this should be closed as 'notwarty'.  Is that tag a generic Not For Us?
[02:46] <mdz> jbailey: yes, there's aa bug open about renaming it to NOTUBUNTU
[02:46] <mdz> but nobody's minding the bugzilla store at the moment
[02:47] <wasabi> every day i see ubuntu-update manager improve... what an awesome program
[02:49] <Kamion> mdz: oh, install CD build finished ages ago, BTW, if you want to kick off a live CD build
[02:49] <Kamion> thully: ^--
[02:49] <mdz> Kamion: kicked
[02:49] <thully> I installed from the last one (released a couple hrs ago) and it works pretty good
[02:50] <thully> also, live cd worked pretty good also
[02:50] <mdz> Kamion: does this have the fixed amd64 kernel?
[02:50] <thully> only main problem is that with the network applet crashing on close
[02:50] <mdz> and if not, can I download one and patch it in?
[02:50] <lamont> jbailey: NOTWARTY means 'look at it after we release, since it doesn't apply to the version in warty^Wubuntu'
[02:50] <Kamion> mdz: what fixed kernel? :)
[02:50] <mdz> Kamion: oh, I thought you said you were making one
[02:50] <mdz> Feb 03 16:48:58 <Kamion>        I'll do a test build on concordia and bung it into an image
[02:50] <Kamion> yeah, but only for test purposes as yet, I was going to patch it in and see what happened
[02:50] <Kamion> but I get:
[02:51] <Kamion> modprobe: FATAL: Could not load /lib/modules/2.6.10/modules.dep: No such file or directory
[02:51] <Kamion> indefinitely
[02:51] <Kamion> wonder what I broke
[02:51] <mdz> you didn't set EXTRAVERSION
[02:51] <lamont> mdz: fwiw, ia64 live is NFG until linux-source-2.6.10_2.6.10-14 - so no array 4 ia64-live
[02:51] <Kamion> oh, good point
[02:51] <mdz> you didn't build it using linux-source-2.6.10?
[02:51] <mdz> Kamion: a little symlink love should take care of it, for a test...
[02:51] <Kamion> I did, weird
[02:52] <Kamion> although I stopped it partway through to use make -j50, maybe that did it
[02:52] <jbailey> Do you just hate your io channel?
[02:52] <mdz> yeah, it probably passes it on the command line
[02:52] <mdz> jbailey: concordia loves it
[02:52] <lamont> jbailey: he wants it to feel important
[02:53] <Kamion> jbailey: concordia does a kernel in like a minute with that
[02:53] <jbailey> Concordia is a box I haven't heard of yet.
[02:53] <lamont> Kamion: way cool
[02:54] <Kamion> jbailey: one of the porting boxes
[02:54] <jbailey> Ah, cool.
[02:54] <thully> so, is polypaudio still planned for hoary?  I saw it was in universe (or maybe it's main) but not used by default
[02:55] <mdz> yes
[02:55] <elmo> err
[02:55] <elmo> it is?
[02:56] <mdz> hypothetically speaking, GNOME is still planning to move, and we are still planning to follow them
[02:56] <Kamion> mdz: EXTRAVERSION> ah, so it does
[03:03] <Kamion> mdz: kdelibs in main; does that mean that we can revert some of the gross hacks to remove it that break stuff? :)
[03:03] <Kamion> (kvim, frex)
[03:03] <mdz> Kamion: absolutely
[03:03] <Kamion> hoorah
[03:03] <mdz> once elmo says it's done
[03:03] <mdz> Kamion: live build is done, btw
[03:04] <Riddell> what is frex?
[03:04] <Kamion> lazy-man's shorthand for "for example"
[03:04] <thully> is there going to be any audio cd burn support in Hoary - last I remember there was no forthcoming solution.
[03:05] <Riddell> well kvim isn't in kdelibs (I would hope)
[03:05] <Riddell> thully: with kdelibs in main, I humbly recommend k3b  :)
[03:06] <lamont> Riddell: but kvim was killed so that vim didn't pull kdelibs into main.
[03:06] <Kamion> and it was killed really badly; we ended up with a kvim package containing only a diversion of vim
[03:06] <Kamion> and nothing to replace it
[03:06] <lamont> Kamion: lol
[03:06] <lamont> we should fix hta
[03:06] <lamont> that
[03:07] <thully> yes - if kdelibs goes in main, it would be great to find some way to make an exception to allow k3b, as we desperately need a decent CD-burning app - nautlius just doesn't cut it (no audio CD, no multisession CD)
[03:07] <thully> nautilus
[03:07] <Kamion> the plan for hoary was coaster, I believe
[03:07] <Kamion> we have no intention of putting kdelibs on the CD
[03:08] <jdub> Kamion: plan for hoary was "if any of them are actually ready"... :)
[03:08] <Kamion> well, yeah :)
[03:08] <Riddell> lamont: ah, ok
[03:09] <mxpxpod> tseng: did that work for you?
[03:09] <Kamion> mdz: do you object to pulling libqt-perl into main? it's pretty small once you have kdelibs, and would allow me to revert a debconf hack.
[03:09] <tseng> mxpxpod: didnt get to it tbh
[03:09] <mdz> Kamion: sounds fine
[03:09] <tseng> mxpxpod: planning to just play with it here before cleaning it up
[03:09] <mxpxpod> tseng: haha, ok
[03:09] <tseng> mxpxpod: ill do it now
[03:09] <tseng> it sounds like we need to uuencode the images in the diff
[03:10] <mxpxpod> tseng: that sucks
[03:10] <mxpxpod> tseng: can't you just submit the diff upstream?
[03:10] <mxpxpod> and get them to release a new version ;)
[03:11] <tseng> no, the author rejected the icons
[03:11] <mxpxpod> WHAT?
[03:11] <tseng> yeah.. doesnt fit with the goals of tomboy, too industrial
[03:11] <mxpxpod> that's retarded
[03:11] <tseng> whatever that means
[03:11] <tseng> tintin can die
[03:11] <mxpxpod> so he'd rather have a retarded icon?
[03:12] <tseng> apperantly
[03:12] <tseng> then some guy posted some absolutely awful icons of a notebook with stick notes on it
[03:12] <tseng> the icon wasnt worthy of window 3.1
[03:12] <tseng> thats where the thread ended..
[03:14] <mxpxpod> haha
[03:17] <mdz> Kamion: we ought to get in touch with henrik and get a copy of the latest OpenCD stuff to go on the hoary images
[03:17] <wasabi> okay this is getting annoying. am i just not going to be able to attach these drives? the ordering will simply not correct itself.
[03:18] <wasabi> there has to be a better long term solution for this too
[03:20] <wasabi> the kernel root= option should take a uuid heh.
[03:21] <wasabi> haha and my system just became unusable at "Checking all file systems". A failure, dropped me to console... no USB loaded!
[03:24] <Kamion> mdz: cool, that kernel fix seems to work
[03:25] <Kamion> just doing a full test now, then I'll fire it off to fabbione and go to bed
[03:25] <wasabi> there is no way i can think of to boot my system with these drives attached. =/
[03:27] <wasabi> except to boot, alter menu.lst and fstab, then reboot.... ugh
[03:27] <mdz> Kamion: sounds good
[03:30] <mdz> Kamion: how big a project do you think it would be to make the powerpc live CD automagically choose the proper kernel?
[03:31] <lamont> Kamion: are we doing weekly dvd images yet?
[03:31] <mdz> lamont: yes
[03:32] <lamont> cool
[03:32] <lamont> not that I have bandwidth, of course... but the full opencd should be on those..
[03:32] <mdz> http://cdimage.ubuntu.com/weekly-dvd/
[03:32] <mdz> lamont: how did that stuff work the last time around?
[03:32] <Kamion> mdz: in what way?
[03:32] <mdz> lamont: do you have a document which says which pieces go where, for the opencd content?
[03:32] <mdz> Kamion: rather than having to type 'power4', etc. at the initial prompt
[03:32] <Kamion> mdz: find me a yaboot guru who isn't already insane ...
[03:33] <wasabi> okay... so... this is a fairly serious hoary problem, in my book anyways. Should I just file a bug on it or does anybody want me to screw with it?
[03:33] <lamont> mdz: henrik provided a subset-ized opencd collection, that was untarred into the CD image before the final mkiso
[03:33] <Kamion> it's not possible specifically for the live CD. It might be possible for both the install and live CDs in tandem
[03:34] <lamont> mdz: it was litterally 'cd chroot; tar xzf .../WinFOSS-0.4.tar.gz' or some such
[03:34] <mdz> Kamion: if it got done, I'd certainly want to use it for both
[03:34] <mdz> lamont: ok, so we just need to ask him for a new tarball of the same kind
[03:35] <Kamion> mdz: maybe a week or so for a powerpc expert, considering the need for extremely extensive testing of that sort of change
[03:35] <Kamion> somebody would need to specify the yaboot.conf extension
[03:35] <mdz> Kamion: well, ideally it would still ask, but choose a smart default
[03:35] <lamont> mdz: with a size cap
[03:35] <mdz> until we got confidence in it
[03:36] <Kamion> nevertheless you need to extend the configuration file format (and upstream will guaranteeably not accept it)
[03:36] <Kamion> and that whole thing's being done without a libc, so it's prone to breakage
[03:36] <mdz> guaranteeably? :-/
[03:36] <Kamion> pretty much, yes
[03:37] <Kamion> the only things yaboot upstream is currently accepting are changes to stuff around the edges like ofpath
[03:37] <Kamion> that's not to say that we can't do it anyway, he'll just throw a tantrum :)
[03:38] <Kamion> on the other hand Sven Luther will probably love you for going against what Ethan wants ;)
[03:38] <mdz> it's a serious usability handicap
[03:38] <Kamion> anyway, personalities aside, need to figure out how to do it in a suitably generic way
[03:39] <Kamion> the configuration file change will be encoded in people's yaboot.conf forever more, since no-one ever changes bootloader configuration if they don't have to
[03:39] <Kamion> although actually not, I guess, it only has to go in CD yaboot.conf files
[03:40] <mdz> yeah
[03:40] <jba> hey guys
[03:41] <Kamion> mdz: I'm going to put noexec=off in the amd64 syslinux.cfg in such a way that it gets propagated to after the first reboot
[03:41] <mdz> Kamion: are you sure?  I'd prefer not to make that change permanent
[03:41] <Kamion> mdz: this will unfortunately mean that when we finally fix the bug we'll need to include something in the upgrade notes telling people to remove that from their grub configuration
[03:42] <Kamion> mdz: I see no other way, given that if somebody runs 'grub-install "(hd0)"' post-reboot then it'll hose their system
[03:42] <Kamion> although I suppose we could just say "don't do that then", since it's a pre-release
[03:42] <mdz> Kamion: people don't generally do that
[03:42] <mdz> and grub or the kernel will be fixed eventually
[03:42] <Kamion> true, I suppose I'm an unusual case
[03:42] <mdz> at least it blows up spectacularly when folks attempt it
[03:43] <mdz> as opposed to in the installer, where it appears to succeed
[03:43] <mdz> grub-install desperately needs set -e
[03:43] <Kamion> yeah, grub-install should be fixed
[03:44] <mdz> I especially love the way that at the end, it says "no error reported"
[03:44] <mdz> as if it has any idea whatsoever
[03:44] <wasabi> surely the linux kernel supports some way to pass root= which is indepent of drive order. =(
[03:45] <Kamion> mdz: actually it does sort of, it's grepping for "Error [0-9] *: " in grub's log file
[03:45] <mdz> wasabi: the kernel isn't likely to ever support a feature like that
[03:45] <Kamion> I wonder if earlier parts of grub-install are actually 'set -e' clean; there are a few bits that look suspicious to me
[03:45] <mdz> but it should be straightforward to do it by label or by uuid in userspace
[03:45] <wasabi> well this kind of makes my hotplug sata a pain in teh ass on linux
[03:45] <mdz> which is where the root filesystem is really mounted anyway
[03:45] <wasabi> or, at least on hoary.
[03:46] <wasabi> when I boot with the drive in, it takes sda and pushes my real sda down to sdb
[03:46] <mdz> Kamion: if you end up doing some more grub-installs for testing, it would be worthwhile to slap set -e on it
[03:46] <mdz> and see if it smokes
[03:46] <Kamion> ok
[03:47] <wasabi> mdz: somehow windows does this right. =)
[03:47] <wasabi> somehow warty did it right too, and that's a bit annoying too. =/
[03:48] <mdz> you got lucky, probably
[03:48] <mdz> maybe in both cases
[03:48] <mdz> but this is off-topic for this channel
[03:48] <wasabi> k
[03:48] <mdz> unless you want to discuss the extensions to initrd-tools to add the functionality to mount root by label or uuid
[03:48] <mdz> which would be a great feature
[03:49] <wasabi> im not smart enough yet. =)
[03:49] <jba> aah initrd my friend
[04:02] <jbailey> mdz: Do you want that for Hoary?
[04:04] <jbailey> mdz: I'd rather implement something like that against udev so that I could sanely get partition information but I don't think it should be that hard, really.
[04:05] <srbaker> jba, what, mounting by label or uuid?
[04:06] <mdz> jbailey: not for hoary, no
[04:06] <jbailey> mdz: Oh lovely.  I think I have almost all of the initrd-tools bugs you assigned me as pending now and in a local tree.
[04:06] <jba> jbailey,  i think that message by srbaker was meant for you
[04:07] <mdz> jbailey: great
[04:07] <jbailey> jba: Yeah, looks like. =)
[04:07] <srbaker> that's what i meant
[04:07] <mdz> jbailey: did you have a chance to look into the ide-{disk,cd,generic} stuff?
[04:07] <mdz> that I really do want for hoary
[04:07] <jbailey> mdz: I loaded the ide.rc onto my box today, and hotplug picks it up.  Tomorrow morning is for reviewing the init stuff.
[04:08] <jba> sorry for stuffing up the tab completion
[04:08] <srbaker> jba, you should be.
[04:08] <jba> in that case, I take it back
[04:09] <jbailey> mdz: I haven't done anything with the ide-generic magic to make sure it gets loaded last, though.  
[04:56] <thully> hi - found something interesting w/latest suspend code - suspend-to-RAM used to take 10% of my battery per hour, now it takes 5% (so it is actually tolerable for short-to-medium periods of time)
[04:59] <jba> thully, now that you mentioned it, i did notice that suspend to ram on low power seemed to kill the laptop quickly (when i turned it back on laptop complained of being below 10% and wouldn't turn on)
[05:01] <tritium> thully, S1 or S3 sleep?
[05:05] <thully> S3, I think - whatever pressing Fn+F4 does in Hoary
[05:05] <thully> I've got a ThinkPad T42 that has had trouble w/suspend - it has always taken 10% of power/hr in ACPI suspend-to-RAM,
[05:06] <thully> This is a known issue for some T42s on Linux, and nobody has resolved it (although Ubuntu has made it work better somehow - 5%/hr I can tolerate somewhat - 10%/hr is intolerable)
[05:06] <thully> I ended up using S4 exclusively in the past
[05:07] <thully> (S4=suspend-to-disk, btw)
[05:11] <tseng> daniels: what did you guys use for streaming at akademy? webcams, dv?
[05:13] <daniels> tseng: dv with flumotion
[05:14] <tseng> hm
[05:29] <daniels> Kamion: ping
[05:29] <daniels> mdz: ping
[05:29] <daniels> amu: ping
[05:29] <lamont> EFLOODPING
[05:29] <daniels> ah, lamont, you'll do :)
[05:30] <lamont> dambn
[05:30] <lamont> wassup?
[05:30] <daniels> i'm mastering a new live cd iso as detailed in LiveCDCustomizationHowTo
[05:30] <daniels> but where do I get .disk/info, and isolinux/isolinux.bin?
[05:31] <lamont> I rather expect you get them from a previous iso?
[05:31] <lamont> that is to say, not sure - haven't read that page..
[05:31] <daniels> lamont: ah, so it is -- thanks
[05:50] <daniels> lamont: night dude
[06:01] <Riddell> daniels: what's the status of dbus with qt?
[06:02] <daniels> Riddell: awaiting testing to see if they're any good or not
[06:02] <daniels> http://people.ubuntu.com/~daniels/dbus/
[06:30] <fabbione> morning guys
[06:31] <daniels> morning fabbione
[06:31] <smurfix> *yawn*
[06:33] <fabbione> mdz: ping
[07:11] <fabbione> daniels: busy?
[07:11] <daniels> fabbione: not hugely, just trying (so far in vain) to write a new live cd image
[07:11] <daniels> fabbione: what's up
[07:11] <daniels> ?
[07:12] <fabbione> daniels: do you have time to prepare a l-r-m to handle the ABI change and send me diff so that i can upload after testing?
[07:12] <daniels> not today, sorry
[07:12] <fabbione> ok
[07:12] <fabbione> no problem
[07:12] <daniels> probably not till the weekend
[07:12] <daniels> er
[07:12] <fabbione> we have a chicken egg problem
[07:12] <daniels> not till monday
[07:12] <daniels> heh
[07:13] <fabbione> i can't upload the kernel and without the kernel Kamion cannot release array4
[07:13] <daniels> ah :\
[07:13] <daniels> unfortunately my weekend is stacked full (more work on the other house, which is flooded, unavoidable family stuff) already
[07:13] <daniels> but i'll see if I can't get you an l-r-m by your Monday?
[07:14] <daniels> er, your Sunday
[07:14] <fabbione> nah don't worry
[07:15] <fabbione> i will see with Kamion and mdz
[07:15] <fabbione> if the latter is awake
[07:18] <daniels> ok, thanks
[07:19] <daniels> i don't have any changes apart from some new modules
[07:21] <fabbione> ok
[07:48] <fabbione> interesting...
[07:48] <fabbione> suse is looking at our kernel :-)
[08:37] <mdz> fabbione: morning
[08:37] <mdz> daniels: pong
[08:37] <daniels> mdz: nevermind, lamont pointed me in sort of the right direction, and I got to remaster a live CD image
[08:37] <mdz> daniels: was there an error in the howto?
[08:37] <daniels> several
[08:38] <daniels> firefox then thoughtfully crashed on my editing session, so I threw up the cbf flag and used the limited time I have for today on fixing casper instead
[08:38] <mdz> I fixed a couple of things earlier today
[08:38] <mdz> but I haven't actually tested the procedure myself
[08:38] <daniels> -V needed quotes around its argument, isolinux/* and .disk/* won't exist for most people (need to prepend extracted_cd/)
[08:38] <daniels> and a couple of other things
[08:38] <fabbione> mdz: the fix for the noexec seems wrong to me, but i will apply it anyway if you tested it.
[08:39] <fabbione> mdz: the problem is the ABI change.. Kamion would like to release Array4 today, but can we manage to do kernel -> l-r-m and d-i?
[08:39] <daniels> mdz: any objections if I upload casper 0.35?
[08:39] <mdz> fabbione: what ABI change? the patch does not change the ABI
[08:39] <fabbione> mdz: also please change l-r-m ownership in bugzilla for daniels :-)
[08:39] <mdz> fabbione: if you want to use strncmp instead of memcmp, that's fine; they're equivalent
[08:39] <fabbione> mdz: your patch does not. another one does 
[08:40] <fabbione> it's a security fix :-)
[08:40] <mdz> fabbione: then let's apply my patch, and not the other one
[08:40] <daniels> mdz: (with casper changes, we get a working x-on-livecd-under-qemu; not tested natively yet)
[08:40] <mdz> daniels: quotes?  $() should expand to a single word
[08:40] <mdz> daniels: what casper changes?
[08:40] <fabbione> mdz: if you want i can revert it, but ....
[08:40] <daniels> mdz: mkisofs bitches about not being able to find 5.04
[08:40] <mdz> fabbione: why revert? you have not uploaded it yet, have you?
[08:41] <daniels> mdz: but "$()" works fine
[08:41] <fabbione> mdz: no i didn't.. but it's in my tree..
[08:41] <mdz> weird
[08:41] <daniels> mdz: don't call dpkg-reconfigure xserver-xorg with XORG_FORCE_PROBE=yes
[08:41] <mdz> daniels: shouldn't that be a no-op now?
[08:42] <daniels> mdz: yes
[08:42] <mdz> fabbione: you could keep that tree, but create a second one based on -13, upload it, we build array 4, and then continue with your tree?
[08:42] <fabbione> mdz: ok.. it's just a lot of extra work.. but i will do asap
[08:42] <mdz> daniels: did you test the BusID thing?
[08:43] <mdz> fabbione: is it?  I can do it if it is a problem
[08:43] <fabbione> mdz: i will need to merge your changes anyway
[08:43] <mdz> it is a one-line change
[08:43] <fabbione> mdz: it's not your change the problem
[08:43] <fabbione> it's the other bug fixes that breaks the ABI :-)
[08:43] <fabbione> don't worry.. i will fix and upload asap
[08:44] <daniels> mdz: yes
[08:45] <daniels> mdz: bear in mind this is with ubuntu16, not 14
[08:46] <mdz> daniels: ubuntu15 is on the current live CD, and that works
[08:46] <mdz> I assume 15 and 14 are identical, debconf-wise
[08:46] <mdz> daniels: so it's not necessary to remove the XORG_FORCE_PROBE in sync with ubuntu16, right?
[08:47] <daniels> mdz: oh, and mkisofs throws volume id string too long too, so you have to use -V hoary-live-custom or whatever
[08:47] <daniels> mdz: theoretically, no
[08:48] <mdz> daniels: I want to get array4 out before changing this again
[08:49] <mdz> but after that, let's do it
[08:56] <daniels> frig!
[08:56] <daniels> mdz: er, so as I understand it, no-one without the archive signing key can fully customise live CDs
[08:56] <daniels> i just foolishly attempted to replace casper
[08:56] <mdz> hmm, if so, we should fix that
[08:57] <daniels> Packages.gz -> Release -> Releage.gpg
[08:57] <mdz> I thought Kamion and I agreed that trying to authenticate the CD we just booted from was a bit excessive
[08:57] <mdz> are you sure it's because of Release.gpg that it breaks?
[09:04] <daniels> mdz: no, hence the 'as I understand it'
[09:05] <mdz> daniels: what did you do exactly?
[09:05] <mdz> did you regenerate Packages and Release?
[09:05] <daniels> i didn't regenerate Release, no
[09:06] <mdz> ah
[09:06] <mdz> that'd do it, then
[09:06] <mdz> Release.gpg shouldn't even be touched on the live CD
[09:06] <daniels> ok
[09:06] <mdz> emailed you a script
[09:06] <daniels> thanks
[09:06] <mdz> which will fix up Packages and Release to match reality
[09:12] <aj_> mdz: ta for applying the patch
[09:13] <aj_> authenticating a cd you've already booted from is pointless; the gpg you're using could already be corrupted anyway (or the kernel you tried to use to exec gcc)
[09:13] <mdz> or a malicious boot loader!
[09:13] <mdz> I think we do authenticate the CD when doing an install from it, but more incidentally in that it's treated the same as a network archive
[09:14] <aj_> i imagine a malicious boot loader could only load a malicious kernel anyway
[09:14] <aj_> (and a normal boot loader can do that!)
[09:14] <mdz> a malicious boot loader could patch in the evil on the fly
[09:14] <aj_> yeah, that's authenticating to ensure it's not accidently corrupt, or out of date though
[09:14] <aj_> aren't boot loader's pretty restricted in size?
[09:14] <sivang> Morning all
[09:18] <mdz> aj_: grub stage2 is about 100k and does a lot
[09:18] <aj_> oh, wow
[09:19] <aj_> well, fair enough them!
[09:19] <aj_> then!
[09:30] <pitti> Hi guys
[09:31] <mdz> morning
[09:31] <fabbione> mdz: did you already tested the patch, right?
[09:31] <fabbione> hey pitti
[09:31] <mdz> fabbione: Kamion tested it
[09:31] <fabbione> ok
[09:31] <fabbione> -14 on the way to jackass
[09:31] <mdz> thanks
[09:32] <fabbione> np
[09:32] <fabbione> *cough*beeer*cough*
[09:33] <Treenaks> fabbione: dude, it's 9:32
[09:33] <fabbione> Treenaks: and?
[09:33] <fabbione> i am already drunk at 6am to manage the kernel dude...
[09:33] <Treenaks> fabbione: oh yeah wait
[09:33] <Treenaks> kernel stuff requires that
[09:34] <fabbione> it's a build-dep :-)
[09:34] <Treenaks> ;)
[09:35] <Treenaks> hm.. gpg --update-trustdb is a LOT faster now I did a --rebuild-keydb-caches
[09:36] <pitti> mdz: pmount 0.7 is up, so gvm can be uploaded. You really think that always mounting 'exec' is the way to go?
[09:36] <fabbione> Treenaks: want my gpgupdate script?
[09:37] <fabbione> Treenaks: it takes care of doing that stuff for you
[09:37] <mdz> pitti: I just don't see what is gained with noexec
[09:37] <Treenaks> fabbione: hm, cool
[09:37] <pitti> mdz: prevent accidential execution
[09:37] <pitti> mdz: nautilus makes it very easy on double-clicks
[09:37] <Treenaks> fabbione: can you mail it?
[09:38] <fabbione> Treenaks: www.fabbione.net/gpgupdate
[09:38] <fabbione> you need to customize it for your setup
[09:38] <mdz> pitti: hmm
[09:38] <Treenaks> fabbione: thanks
[09:38] <mdz> pitti: the same things are possible with samba shares, FTP sites, etc. though
[09:38] <pitti> yeah, right
[09:39] <fabbione> Treenaks: the rsync part is commented out, because you do it once
[09:39] <pitti> mdz: hmm, nautilus still asks whether to execute or open a file
[09:39] <fabbione> Treenaks: after taht you add the keyrings to your gpg.conf or whatever is called today
[09:39] <pitti> mdz: okay, I upload it like this now, we can always change it
[09:39] <fabbione> Treenaks: and gpg --refresh-keys will take care of it
[09:40] <Treenaks> fabbione: ok, cool
[09:40] <mdz> pitti: it asks when?
[09:40] <daniels> mdz: how do I debug casper-udeb failing to install?
[09:40] <daniels> mdz: all I get in syslog is that casper-udeb failed to configure
[09:41] <fabbione> mdz: linux-source-2.6.10_2.6.10-14_source.changes ACCEPTED
[09:41] <fabbione> have fun
[09:41] <pitti> mdz: it asks when you have an executable file with another mime type (graphic, ASCII text, etc.)
[09:41] <mdz> daniels: set -x in postinst, I suppose
[09:42] <pitti> mdz: "Do you want to open this file or execute in a text terminal" or sth. similar
[09:42] <mdz> pitti: oh, so there is already a safeguard against automatic execution?
[09:42] <pitti> mdz: the autorun has a confirmation dialog in any case, yes
[09:42] <pitti> mdz: I meant double-click execution, it should be mildly protected as well
[09:43] <mdz> fabbione: thanks
[09:43] <fabbione> no problem dude :-)
[09:43] <fabbione> i will wait monday to upload -15
[09:44] <fabbione> so we have time to prepare l-r-m and other stuff
[09:45] <mdz> I just want to get array 4 out
[09:45] <fabbione> yup.. i fully understand...
[09:45] <mdz> it is late already due to this grub bug and the xorg stuff
[09:45] <fabbione> we had some kind of chicken-egg problem here
[09:45] <fabbione> probably we need to be more careful next time
[09:46] <fabbione> because i was waiting to upload the kernel due to Array 4
[09:46] <fabbione> and Array 4 was waiting for me
[09:46] <mdz> array 4 was waiting for you?
[09:46] <fabbione> well due to the amd64/grub bug
[09:46] <mdz> we did not have a fix to give to you until a few hours ago :-)
[09:46] <fabbione> since we don't have a real fix...
[09:47] <mdz> s/fix/workraound/
[09:47] <fabbione> still... if i knew about the parsing problem before i could have fixed it easily
[09:47] <fabbione> i ahd to fight with it already for inotify
[09:48] <mdz> you already knew that noexec=off was buggy?
[09:48] <fabbione> no
[09:48] <mdz> oh
[09:48] <fabbione> but i knew how to fix it
[09:48] <mdz> once we realized that was the problem, it was trivial to fix
[09:48] <fabbione> ok :-)
[09:48] <mdz> I thought we could just use noexec=off as a workaround
[09:48] <mdz> I did not realiz euntil today that noexec=off wasn't working
[09:48] <fabbione> but it wasn't working everywhere
[09:49] <fabbione> yeah
[09:49] <fabbione> let me send the patch upstream...
[09:49] <mdz> we still have the underlying problem to fix :-/
[09:49] <mdz> no one responded on lkml I guess
[09:49] <fabbione> yup
[09:49] <fabbione> no.. nobody
[09:49] <mdz> that is crazy
[09:49] <mdz> there is no 64-bit boot loader for amd64, is there?
[09:50] <mdz> so this would affect everyone
[09:50] <fabbione> on the other hand the trackpoint patch has been submitted upstream and it is receiving comments
[09:50] <fabbione> also good ones to fix the detection
[09:50] <fabbione> (including from Suse people that have been tracking our kernel/bugzilla)
[09:51] <fabbione> so at the end i don't suck as much as i tought kernel-side
[09:51] <mdz> I last heard from Kamion at 0200 UTC
[09:51] <mdz> so I guess he will not be awake yet
[09:51] <fabbione> i doubt
[09:51] <fabbione> that was approx 7 hours ago...
[09:51] <fabbione> so at least another 2/3
[09:51] <mdz> once kernel -15 is up, he knows what needs to be done
[09:51] <dholbach> morning
[09:52] <fabbione> mdz: i will still wait monday. it will give me time to do more stuff
[09:52] <mdz> fabbione: between you and Kamion, you can test all 3 major architectures, right?
[09:52] <fabbione> mdz: since we must break the ABI, it is worth to backport more fixes
[09:52] <fabbione> mdz: with Array4? i think so yes...
[09:53] <fabbione> mdz: given that he can produce the iso's within a decent time...
[09:53] <mdz> ok, so if everything goes OK, you guys can get array4 out while I am asleep
[09:53] <fabbione> i promised my (future) wife to take her for dinner out this evening
[09:53] <fabbione> mdz: ok. i will talk with Kamion and we will see how it goes
[09:54] <fabbione> mdz: sleep tight :-)
[09:54] <mdz> night
[09:54] <daniels> i think partners of distribution team members will breathe a collective sigh of relief when hoary is out
[09:54] <daniels> mdz: g'night
[09:54] <sivang> mdz: night
[09:55] <dholbach> hai sivang
[09:55] <sivang> dholbach: morning!
[09:55] <sivang> dholbach: 'sup?
[10:01] <daniels> when you're a few hundred mb deep into swap on account of building a live cd image again, and your only swap device is a usb hard drive, it *hurts*
[10:02] <fabbione> ahhah
[10:24] <d3vic3> doko ping 
[10:24] <daniels> qemu is sloooow
[10:25] <d3vic3> if a package is 0.7.3, does it become 0.7.3ubuntu1 or 0.7.3-1ubuntu1 ? 
[10:25] <daniels> d3vic3: hard to tell, but usually 0.7.3ubuntu1; sometimes 0.7.3-0ubuntu1
[10:26] <d3vic3> hmm 0ubuntu1 seems close enough 
[10:29] <sivang> daniels: yeah...:-/ I wish it would be bit faster, would be real nice, as it's quite stable from what I've seen and played with.
[10:30] <doko> d3vic3: png
[10:31] <d3vic3> doko scroll up a bit 
[10:31] <daniels> mdz: ok, xorg on the live cd now works fine for me.
[10:31] <daniels> mdz: (with ubuntu16)
[10:32] <doko> d3vic3: I did choose 0.7.3ubuntu1 for packages with a tar.gz, and the schema with the dash for packages with an .orig tarball.
[10:32] <daniels> aha!
[10:33] <d3vic3> on 
[10:33] <d3vic3> ok 
[10:33] <daniels> mdz: ironically, the problem with writing out the new config you had was due to Branden's Debconf-fu not being anal enough :P
[10:33] <d3vic3> this one has tar.gz, so I'll do same as you 
[10:34] <daniels> later all
[10:34] <d3vic3> dch changes dir name however
[10:37] <sivang> hey _mvo_ 
[10:37] <dholbach> guten morgen _mvo_!
[10:37] <_mvo_> hi sivang, hi dholbach 
[10:55] <pitti> Hi _mvo_ !
[10:57] <_mvo_> hi pitti 
[11:16] <sivang> morning amu 
[11:18] <thom> fabbione: but you're a kde fanboy
[11:21] <fabbione> thom: no when it goes to kill my poor sparc 
[11:23] <thom> heh
[11:23] <sivang> so, does anybody know what is going to be hoary's official pdf reader (gpdf,xpdf...) ?
[11:24] <amu> fabbione: *eg* 
[11:24] <amu> hi sivang 
[11:24] <thom> sivang: xpdf
[11:24] <thom> sivang: we may change to evince in the next release, i guess
[11:25] <sivang> thom: thom : errr :)
[11:25] <thom> err?
[11:25] <sivang> thom: sorry,
[11:26] <sivang> thom: that was meant to be sounds of discontent :-))
[11:26] <thom> whyso?
[11:26] <sivang> thom: well, user interface wise, evince looks a bit better no?
[11:27] <sivang> morning seb128 
[11:27] <thom> sivang: yes, but it's nowhere near ready for hoary
[11:27] <seb128> hi
[11:27] <pitti> Hi seb128
[11:27] <seb128> thom: evince ?
[11:28] <sivang> seb128: do you read minds? ;-) (or have another nick which saves scrollback for you)
[11:28] <thom> seb128: yeah
[11:28] <seb128> sivang: <sivang> thom: well, user interface wise, evince looks a bit better no?
[11:28] <seb128> thom: doesn't work fine for you ?
[11:28] <sivang> seb128: oops, I am switching order of lines in my mind...
[11:28] <infinity> kdelibs in main?...  Bah.  I no longer like Ubuntu.
[11:29] <sivang> infinity: hehe
[11:29] <infinity> Lacking KDE was a feature, not a bug. :)
[11:29] <thom> seb128: works fine, it just is so young it scares me
[11:29] <Riddell> sivang: kpdf!  (pretty please, it's relly nice)
[11:29] <sivang> thom: what would be needed to make it hoary worthee? 
[11:29] <seb128> thom: xpdf is ugly :/
[11:29] <thom> seb128: yes
[11:29] <seb128> Riddell: stop trolling
[11:30] <jdub> seb128: is this the evince or gpdf in hoary discussion?
[11:30] <thom> seb128: are you really planning to ask for evince in main?
[11:30] <sivang> jdub: evince or xpdf :)
[11:30] <Riddell> seb128: hay, they started it :)
[11:30] <dholbach> evince is cool, but searching is a bit broken
[11:30] <seb128> jdub: seems so :p
[11:30] <jdub> seb128: i'm worried it hasn't had much testing
[11:31] <seb128> jdub: me too
[11:31] <sivang> dholbach: in what way?
[11:31] <jdub> so i'd be more comfortable with gpdf
[11:31] <seb128> jdub: but xpdf is really ugly :/
[11:31] <seb128> jdub: yeah, if it gets type3 font ...
[11:32] <dholbach> sivang: filed a bug yesterday... you hit ctrl-f - start typing - and it suddenly can't find anything anymore, it crashes
[11:33] <sivang> seb128: it's also using a non std menu layout, if that can be called a menubar at all :)
[11:40] <seb128> jdub: oh, themes/engines update, rock :)
[11:42] <smurfix> fabbione: wow. What are you going to do with those??
[11:42] <thom> fabbione: send em back! ask for full ones next time!
[11:42] <fabbione> thom: ahhaha
[11:42] <jdub> seb128: yeah, decided to just epoch it harder
[11:42] <fabbione> smurfix: well.. backing up my server and reinstall it from scratch.. 
[11:42] <fabbione> smurfix: + other stuff...
[11:43] <fabbione> i need a place where to store my pr0n collection
[11:43] <d3vic3> fabbione, yuk!
[11:43] <fabbione> now i need to buy a 600 DVD readers jubox
[11:43] <pitti> fabbione: I thought the kernel sources were your pr0n? :-)
[11:44] <smurfix> fabbione: Heh. I send the important stuff offsite, anything else is on a raid-5, and if that dies, well, I got the stuff from the net, I can do it again
[11:44] <fabbione> pitti: no.. i still don't masturbate with it.. even if it's getting slowly sexier
[11:44] <fabbione> smurfix: that's the plan.. but basically they will be a huge help for me to reinstall everything here
[11:44] <pitti> fabbione: maybe you should strip the kernel... 
[11:44] <fabbione> shit has been piling up for ages
[11:45] <fabbione> pitti: i don't compile with -g
[11:45] <fabbione> it's already naked :)
[11:45] <pitti> fabbione: ahem, 600 DVDs? and you are sure that you will find _anything_ on them?
[11:45] <fabbione> pitti: i am pretty good at keeping order around
[11:45] <fabbione> so yeah
[11:45] <fabbione> actually it's a very small box
[11:46] <fabbione> approx the size of a midtower case
[11:48] <fabbione> Mithrandir: ahahha
[11:48] <fabbione> approx 300GB to backup ;)
[11:48] <fabbione> but most of it will stay on DVD
[11:48] <fabbione> so it will be more like
[11:48] <fabbione> misc pron #1/XXX
[11:49] <pitti> weird guys...
[11:49] <pitti> oh, another security bug - yeah, give it to me! try me harder!
[11:49] <Treenaks> pitti: you just buy 2 identical servers? :)
[11:49] <pitti> Treenaks: hmm?
[11:50] <sivang> fabbione: trust me you will never touch most of the stuff that "just piled there" , I used to make lots and lots of backups, and they are still sitting in the closet, most of the important stuff is on imaps mail, cvs etc.. :-))
[11:50] <Treenaks> pitti: oh.. instead of making backups on DVDs, you have 2 identical machines
[11:50] <fabbione> pitti: what is about? kernel?
[11:50] <pitti> Treenaks: why should I? one is more than enough
[11:50] <pitti> fabbione: just kidding
[11:50] <fabbione> ah ok
[11:50] <pitti> fabbione: actually I have a bunch :-)
[11:50] <fabbione> i expected so
[11:50] <fabbione> and i am NOT surprised
[11:50] <pitti> Treenaks: I upload my backups to the worldwide mirror net :-)
[11:51] <Treenaks> pitti: oh yeah of course :)
[11:51] <sivang> pitti: can anybody upload there?
[11:51] <fabbione> the best backup around are gpg keyservers
[11:51] <pitti> Treenaks: any my personal backup fits in 30 MB
[11:51] <fabbione> i will let you figure out to use them for it
[11:51] <pitti> fabbione: debian mirrors are not bad as well
[11:51] <fabbione> you can remove stuff from a debian mirror
[11:51] <fabbione> you cannot from a gpg keyserver :-)
[11:52] <Treenaks> fabbione: ah, that's why you sent your private key there ;)
[11:52] <Treenaks> fabbione: so you won't lose it!
[11:52] <fabbione> Treenaks: EXACTLY!
[11:53] <fabbione> Who uses XFS and run 686 ?
[11:53] <fabbione> (and feels very lucky today...)
[11:53] <pitti> fabbione: hmm, is XFS and k7 close enough?
[11:53] <fabbione> pitti: i can make it close.. yes
[11:53] <pitti> fabbione: alternatively, xfs and ppc?
[11:53] <fabbione> pitti: if you want...
[11:53] <pitti> fabbione: my multimedia partition is xfs
[11:53] <pitti> fabbione: what do you want to destroy on it?
[11:54] <pitti> fabbione: incidentially, this one is _not_ backuped... :-/
[11:54] <fabbione> pitti: #6122
[11:54] <fabbione> pitti: updating to XFS in bk
[11:54] <fabbione> modulo a few bits that we can't backport
[11:55] <pitti> "XFS crashed on 2.6.10-2-k7" -> hey, that's my kernel
[11:55] <fabbione> pitti: just tell which flavour you prefer to trash... ppc or k7?
[11:55] <fabbione> ok
[11:55] <pitti> fabbione: well, k7
[11:56] <pitti> fabbione: however, I never experienced an XFS crash
[11:56] <sivang> fabbione: my home is xfs :)
[11:56] <pitti> fabbione: hmm, good opportunity to write my first DVD :-)
[11:56] <sivang> fabbione: is there some kernel sacrafices going to take place today? ;-))
[11:57] <sivang> fabbione: using a 686-smp , btw.
[11:57] <fabbione> sivang: do you use XFS?
[11:57] <fabbione> pitti: good opportunity ;)
[11:59] <Kamion> morning
[11:59] <sivang> fabbione: yes
[12:00] <fabbione> sivang: ok.. than i will build k7 and 686-smp
[12:00] <fabbione> Kamion: goodmorning :-)
[12:00] <sivang> fabbione: /dev/hdb7 on /home type xfs (rw)
[12:00] <sivang> fabbione: is anything going to break? ;-)
[12:00] <fabbione> Kamion: please read the scrollback from this morning.. it's about Array4.. the kernel is ready
[12:00] <fabbione> sivang: possibly...
[12:00] <Kamion> fabbione: yup, read it, thanks dude :)
[12:01] <fabbione> Kamion: no problem!
[12:01] <pitti> brb
[12:02] <sivang> fabbione: this was planned as a regular kernel update ? (or just your pkgs that need testing)
[12:02] <smurfix> array4? Somebody should update HoaryReleaseSchedule... it talks about array9 due next week. ;-)
[12:03] <fabbione> sivang: both...
[12:03] <Kamion> smurfix: oh yeah, been meaning to fix that
[12:03] <thom> fabbione: if you break XFS i will cry
[12:03] <fabbione> thom: can you test it too?
[12:04] <fabbione> thom: according to 6122 is already broken
[12:04] <thom> i'm on amd64
[12:04] <fabbione> ok .. can you test it? i don't mind building on amd64
[12:04] <thom> and it's not eaten my /home yet ;-)
[12:04] <thom> sure
[12:04] <fabbione> what flavour do you prefer?
[12:05] <thom> -k8
[12:05] <thom> (amd64-k8 that is)
[12:05] <fabbione> roger
[12:05] <fabbione> yeah yeah :-)
[12:05] <fabbione> that crap over there
[12:05] <thom> warm up concordia!
[12:06] <fabbione> thom: how much do you want me to fire this time?
[12:06] <thom> last time was maybe excessive ;-)
[12:06] <Simira> yay, a jdub :)
[12:06] <fabbione> eheheh
[12:06] <Kamion> smurfix: done
[12:07] <Kamion> jdub: I've updated the release schedule to reflect reality with respect to Array CDs, hope that's ok
[12:07] <sivang> fabbione: please, I also don't want my /home to disappear :-) How much gpg keys do you want for that? ;-)
[12:07] <Treenaks> "See here the reason I don't run JFS, XFS or Reiser" ;)
[12:08] <sivang> Treenaks: I've been using it since hoary with no apprent problem so far :)
[12:08] <fabbione> thom: last we tried 400... let see how it goes with 399 :-)
[12:08] <thom> heh
[12:08] <fabbione> kidding.. down to 200
[12:17] <thom> fabbione: 200 is too slow ;-)
[12:18] <fabbione> crap
[12:18] <fabbione> it doesn't even build on amd64
[12:19] <fabbione> (inotify)
[12:21] <fabbione> this should be easy
[12:23] <fabbione> is www.kernel.org down?
[12:24] <Mithrandir> looks like it.  Use ftp.$countrycode.kernel.org?
[12:25] <thom> fabbione: jabber me when you're ready? 
[12:26] <fabbione> thom: sure...
[12:28] <fabbione> thom: i have almost done.. these fixes are easy :-)
[12:31] <Kamion> fabbione: just waiting for elmo to NEW the ia64 stuff, then I'll kick off a CD build
[12:33] <elmo> the NEW stuff has been done a while
[12:33] <Kamion> oh, bonus, ta
[12:33] <elmo> tho, not in main
[12:33] <elmo> I guess you probably want that ;)
[12:33] <Kamion> ideally, yeah ;)
[12:34] <Kamion> haha, I really must fix d-i not to copy init=/bin/sh to the target bootloader config
[12:34] <elmo> Kamion: could you seed it?
[12:35] <Kamion> elmo: sure, sec
[12:35] <Kamion> um, minute. have to reboot to a system that actually has baz plus a seed checkout
[12:38] <Kamion> elmo: it shouldn't need seeded, stuff should depend on it - I don't seed ext2-modules on powerpc
[12:38] <elmo> casper-udeb depends on it for ppc
[12:39] <Kamion> and ia64; there's a glitch where kernel-image still provides ext2-modules on ia64, though, which might be confusing germinate
[12:40] <elmo> hmm, germinate doesn't mention casper-udeb for ia64.. 
[12:41] <Kamion> fabbione: please remove ext2-modules from the kernel-image Provides: line in debian/d-i/ia64/package-list
[12:42] <Kamion> fabbione: (not urgent for array 4)
[12:42] <fabbione> Kamion: done
[12:43] <Kamion> thanks
[12:43] <fabbione> no problem
[12:43] <fabbione> thom: check on people.u.c/~fabbione/
[12:44] <fabbione> argh.. i did too fast.. bah.. damn dpatch
[12:44] <Kamion> elmo: don't worry about it for now, it's probably useless given the incorrect kernel Provides:; when the Provides: are fixed, germinate should automatically ask for ext2-modules in main
[12:44] <thom> fabbione: thanks ;-)
[12:44] <fabbione> thom: thanks for trashing^Wtesting
[12:45] <elmo> Kamion: ok, I promoted it in the meanwhile - want me to force cron.daily, or is next scheduled one ok?
[12:45] <Kamion> elmo: next scheduled's fine
[12:48] <thom> fabbione: i need to clean up my ~ anyway ;-)
[12:49] <fabbione> ahha
[12:49] <fabbione> thom: please stress it as much as you can
[01:00] <thom> fabbione: well, my /home is still there
[01:00] <fabbione> thom: can you do some high I/O on it?
[01:02] <fabbione> check fs corruption.. stuff like that
[01:04] <thom> fabbione: hrm, this new kernel is an oops-oh-rama
[01:05] <thom> i'll save the oops, then i'm rebooting ASAP
[01:12] <fabbione> thom: try to reboot with noinotify
[01:12] <fabbione> or the oops are XFS related?
[01:14] <dholbach> /haggai
[01:16] <pitti> elmo: regarding #6124 (psql conffiles): which version did you try this with? This mess was already fixed in 7.4.6-6
[01:17] <pitti> elmo: (which is not yet in Warty, though)
[01:17] <thom> fabbione: RIP: 0010:[_end+534707758/2132627456]  <ffffffffa021ae2e>{:xfs:linvfs_ioctl+30}
[01:17] <fabbione> what is the EIP?
[01:18] <thom> wait one 
[01:18] <elmo> pitti: yeah, it was warty - I had a quick look at hoary and it looked the same, if it's already fixed, sorry
[01:18] <fabbione> thom: ok.. i guess we can't safely backport XFS...
[01:18] <fabbione> thom: at least not on x86_64
[01:18] <pitti> elmo: I don't think that I can put this change into hoary - it's not security and no major breakage, I think
[01:19] <pitti> elmo: s/hoary/warty/
[01:19] <fabbione> that's the one that suffer from the biggest ioctl changes
[01:19] <elmo> pitti: no, if it's definitely fixed in hoary just close the bug
[01:19] <pitti> okay
[01:20] <elmo> pitti: umm, how has it been fixed?
[01:20] <elmo> the function is still there and it still unconditionally chmods and chowns
[01:20] <elmo> in 7.4.7-1
[01:21] <thom> fabbione: www.clearairturbulence.org/syslog-xfs-broken
[01:21] <pitti> elmo: it is not called on every upgrade
[01:21] <elmo> pitti: when is it called?
[01:21] <pitti> elmo: just right after initdb (installation from scratch) and in db_upgrade
[01:21] <elmo> I don't think you can do it on db_upgrade either?
[01:21] <pitti> elmo: but db_upgrade will not be necessary any more
[01:21] <elmo> for hoary?
[01:22] <pitti> elmo: see my bug followup, I send it soon
[01:22] <elmo> ok
[01:23] <pitti> sent
[01:28] <fabbione> thom: thanks.. nothing i can fix without going 11rc3
[01:33] <thom> oh well, it didn't actually trash the FS at all so i can't complain
[01:33] <fabbione> thom: yeah i can see there are no thunderclouds in my house...
[01:33] <fabbione> :-)
[01:34] <Hwolf> When is the next array due?
[01:34] <Kamion> Hwolf: today hopefully
[01:34] <Kamion> Hwolf: I'm just building the candidate now
[01:34] <thom> fabbione: thunderclouds? there would be a fucking v2 on its way ;-)
[01:34] <Hwolf> kamion: Thanks. Was just planning to install array3. I'll save myself the agony then.
[01:34] <fabbione> thom: ehehhe
[01:35] <Kamion> Hwolf: what arch?
[01:35] <Hwolf> x86
[01:35] <Kamion> array 3 shouldn't be too agonising
[01:36] <Hwolf> I couldn't for the love of god get an .avi, .mpeg or anything to play, last time i checked.
[01:36] <Kamion> oh, no idea what that's about
[01:36] <Hwolf> Kamion: My messed up pc, probably
[01:52] <fabbione> Kamion, mdz: Andi Kleen thanks for the noexec option and he offered as direct contact point for future x86_64 patches
[01:54] <Hwolf> fabbione: how is the ubuntu (kernel) support for bluetooth HID?
[01:54] <Kamion> fabbione: cool
[01:54] <Kamion> fabbione: can we ask him if he knows anything about the grub noexec bug?
[02:05] <pitti> carlos: how far are you with the imports?
[02:05] <pitti> carlos: gtk+2.0 has two important domains, which my script cannot yet handle
[02:05] <carlos> pitti: yesterday I did a whole import
[02:06] <pitti> carlos: shall I improve my script or wait for you?
[02:06] <pitti> carlos: neat
[02:06] <fabbione> Kamion: i think so.. sure.. do you have a link to your message to lkml handy?
[02:06] <pitti> carlos: GIMME THE PO CRACK! :-)
[02:06] <carlos> pitti: If all goes well, on Monday or Tuesday will be in production
[02:06] <pitti> carlos: okay, I can wait until next week
[02:06] <pitti> carlos: actually I wanted to produce a new set of update packages
[02:07] <carlos> pitti: I'm going to have lunch now, could we talk later about the gtk+ problem? I'm interesting to know what's the problem exactly
[02:07] <pitti> sure
[02:07] <carlos> later!
[02:07] <Kamion> fabbione: http://www.ussg.iu.edu/hypermail/linux/kernel/0501.3/1083.html
[02:08] <fabbione> Kamion: ROCK 'N ROLL!!!!
[02:22] <Mitario> hi everyone
[02:23] <_mvo_> hi Mitario 
[02:38] <thom> Kamion: how do i get all but the first line of output in shell?
[02:40] <Kamion> thom: tail -n +2
[02:40] <fabbione> thom: i think you need to do it via wc -l -1 
[02:40] <Kamion> you so don't :-)
[02:40] <fabbione> interesting :-)
[02:40] <thom> Kamion: rocking, thanks
[02:41] <thom> why oh why doesn't man tail mention this
[02:42] <Kamion> it does
[02:42] <Kamion>        If the first character of N (the number of bytes or lines) is a
[02:42] <Kamion>        `+', print beginning with the Nth item from the start  of  each
[02:42] <Kamion>        file,  otherwise,  print  the  last N items in the file.
[02:43] <thom> argh
[02:43] <thom> right, i was stupidly looking for an argument to -n
[02:43] <thom> rather than a general comment
[02:43] <thom> in the same style as head, actually ;-)
[02:46] <Kamion> heh
[02:46] <Kamion> yeah, could probably do with rewording
[02:47] <Mithrandir> is X.org in arch somewhere?
[02:48] <fabbione> Mithrandir: it was.. but it's not updated anymore
[02:48] <fabbione> at least.. the debian/ dir was
[02:49] <Mithrandir> it's for sesse.  He's looking at making a X-to-RDP thingy.  (And yes, I know he's crazy.)
[02:49] <fabbione> RIGHT!
[02:53] <zul> hey
[02:54] <fabbione> hey zul
[02:54] <zul> hey fabbione how is it going
[02:54] <fabbione> not extremely bad...
[02:54] <zul> good...
[02:54] <Hwolf> fabbione, why so gloomy?
[02:55] <fabbione> Hwolf: because sometimes is just a royal pain to work on the kernel
[02:55] <zul> hes always gloomy hes a kernel hacker
[02:56] <Hwolf> fabbione: how far is the distro's kernel from the default?
[02:57] <fabbione> Hwolf: what is default?
[02:57] <Hwolf> vanilla, sorry
[02:57] <Kamion> Hwolf: the source package has a debian/patches/ directory, you can look in that
[02:57] <fabbione> also because there is no vanilla
[02:58] <Hwolf> kernel,org then.
[02:58] <fabbione> vanilla from a stable release? bk? rcZbk394738743+ac33-mm2?
[02:58] <zul> heheh
[02:58] <fabbione> There is no vanilla! There is only Zuul!
[02:59] <tseng> hmm looks like industrial cursors got dropped for this round of gtk2-engines updates
[02:59] <fabbione> BUGBUSTERS!
[02:59] <Treenaks> fabbione: yeah, look at the xmlns for xul
[02:59] <tseng> any ideas as to where it should go?
[02:59] <zul> i like ice cream
[02:59] <fabbione> never cross the flux of more upstream...
[02:59] <Hwolf> Call me stupid, but I've rarely noticed the difference on debian between a debian kernel or a kernel.org one.
[02:59] <Hwolf> Using it that is
[02:59] <tseng> Hwolf: most things in debian are bugfixes.
[03:00] <tseng> not magical fairy dust like some other kernel sources
[03:00] <Hwolf> tseng: at this moment, I'm living under the impression debian prefers to patch a new version together rathen than get it upstream. :-)
[03:00] <Hwolf> rather, even.
[03:01] <tseng> upstream releases arent in the best shape these days.
[03:01] <Hwolf> (popped the keys of my keyboard for cleaning, must've wrecked it)
[03:03] <zul> fabbione: kernel team meeting is still next week?
[03:04] <fabbione> zul: yes
[03:11] <jbailey> I have a patch for a bug on evolution-exchange in warty.  Do I need to do anything more than upload a new version with the distro set correctly?
[03:12] <Mithrandir> jbailey: uhm, warty?
[03:12] <Mithrandir> jbailey: sure you don't mean hoary?
[03:12] <tseng> hm, youll have to get that approved
[03:12] <tseng> there isnt a real policy of fixing bugs in warty.
[03:13] <jbailey> Mithrandir: Yes, certain.  Hoary I've figured out how to deal with already.
[03:13] <Mithrandir> jbailey: as tseng says -- get approval.  jdub/mdz; drop them a mail.
[03:13] <jbailey> evo-exchange is in main, and it's a stupid bug that keeps a good number of exchange configurations from working.  I patched it in Debian ages ago but I guess it didn't make the sync.
[03:14] <jbailey> Mithrandir: Cool, thanks,
[03:14] <elmo> jbailey: (btw, when/if you get approval, correct distro is 'warty-updates', 'warty' won't work)
[03:14] <jbailey> elmo: Thanks!
[03:14] <sivang> Hey jbailey 
[03:15] <jbailey> G'day sivang 
[03:15] <fabbione> jbailey: /wind goto 5
[03:15] <fabbione> ops
[03:15] <jbailey> fabbione: I suspect you don't actually want me to hop to my Hurd development window ;)
[03:16] <fabbione> jbailey: that's for sure :-)
[03:22] <tseng> oh hell yeah, mono 1.0.5
[03:22] <Treenaks> time for beagle! :)
[03:23] <elmo> Kamion: cute; you triggered a lintian error I've never seen before
[03:23] <elmo> E: kickseed source: no-standards-version-field
[03:23] <elmo> Kamion: can't you trigger them?  if not, I can for you if you want
[03:23] <Kamion> elmo: happens with a lot of udebs, since they don't follow policy :)
[03:23] <elmo> hmm
[03:23] <Kamion> elmo: I'm supposed to be able to, but when I tried, mcmurdo wanted a password
[03:24] <Kamion> elmo: in this case it was just an oversight though, I'll add the s-v field
[03:24] <Kamion> done in arch
[03:24] <elmo> the key in authorized_keys is fux0red
[03:25] <Kamion> elmo: machines are: mcmurdo hooker ross yellow (d-i) terranova weddell adare king (live fs, which didn't work either)
[03:27] <elmo> ok, triggered d-i on all of them; does live fs need to be after or can it run concurrent?
[03:27] <Kamion> I don't need the live fs now, just observing that the key is fux0red there too
[03:27] <Kamion> thanks
[03:27] <Kamion> actually ... yes, I suppose I do need the live fs, but it can run concurrently
[03:28] <Kamion> best not play too many games with version skew
[03:35] <fabbione> WOWWOWOWO
[03:35] <fabbione>  initrd-kickseed - Load Kickstart file from the initrd
[03:51] <dholbach> bbl
[03:52] <carlos> pitti: ping
[03:52] <pitti> carlos: pong
[03:52] <carlos> pitti: so, what's the problem with gtk+?
[03:52] <carlos> pitti: the multiple domains?
[03:53] <pitti> carlos: it has two domains which are both important
[03:53] <pitti> carlos: and my script cannot handle that
[03:53] <carlos> pitti: mine neither
[03:53] <pitti> carlos: well, but mine is only a temporary hack :-)
[03:53] <carlos> pitti: the only solution I found was to ask for a manual fix
[03:53] <pitti> carlos: however, I can improve it if necessary
[03:53] <fabbione> haggai: sparc is building OO2
[03:54] <pitti> carlos: why, the override can be extended to a mapping of domain => path
[03:54] <carlos> pitti: I record the domain for a defined path, and next import will know how to handle it
[03:54] <jdub> Kamion: YAY KICKSEED (haha initrd)
[03:54] <pitti> carlos: I do it similarly
[03:54] <pitti> carlos: but I only support one path/domain per pacakge override right now
[03:54] <tseng> morn jdub 
[03:54] <Kamion> jdub: err ... ok
[03:54] <carlos> pitti: don't worry about it (for me, if you want for your temporal solution, it's ok)
[03:55] <pitti> carlos: that depends on how fast I can get the updates from Rosetta
[03:55] <carlos> pitti: of course, if you could send me your current mapping table that will save me sometime :-D
[03:55] <pitti> carlos: I already did
[03:55] <carlos> pitti: no new additions?
[03:55] <pitti> carlos: no
[03:55] <carlos> ok
[03:57] <sivang> is there a way to uncompress a .deb to it's source form? (if you don't have the source package)
[03:57] <fabbione> sivang: uh?
[03:58] <sivang> fabbione: like "reverse engineer" a binary package, if I don't have the source pkg and want to modify it.
[03:58] <fabbione> sivang: it's easier to find the source :-)
[03:59] <Kamion> sivang: no.
[03:59] <Kamion> the source->binary transformation is lossy
[03:59] <sivang> Kamion, fabbione : ok, will do, thanks
[04:09] <sivang> jdub: has the skin competition closed for submission? when are you expecting to announce the winner?
[04:13] <jdub> sivang: it's closed, no details yet
[04:14] <sivang> jdub: cool, thanks, someone on the locoteam asked..
[04:19] <mxpxpod> tseng: any luck?
[04:19] <tseng> mxpxpod: no, it busted it pretty good
[04:19] <mxpxpod> haha
[04:19] <mxpxpod> well, that sucks
[04:19] <tseng> the trayicon dies on your GdkPixbuf bit
[04:20] <mxpxpod> what????
[04:20] <mxpxpod> that's stupid
[04:20] <tseng> well, it doesnt seem to install the gfx
[04:20] <tseng> which is part of the problem
[04:20] <mxpxpod> hrmm
[04:20] <tseng> adding the applet fubared my panel
[04:22] <fabbione> pitti: 6164!
[04:23] <pitti> darn
[04:25] <mxpxpod> I'd just like to say that you guys are all doing some really great work on the linux desktop.. thanks
[04:28] <fabbione> mxpxpod: thanks :-) really appreciated
[04:28] <zul> grrr...hate vnc
[04:28] <fabbione> mxpxpod: if you find a bug, please complain with seb128 and GTK :P
[04:28] <pitti> lamont: any idea about #6164?
[04:29] <fabbione> pitti: the reporter is not the only one btw
[04:29] <tseng> lamont: mono 1.0.5 is now rocking my box
[04:29] <mxpxpod> fabbione: no bugs here... yet
[04:30] <fabbione> hey seb128 :-)
[04:30] <seb128> heyhey fabbione :)
[04:30] <fabbione> i think i am off for a long break
[04:31] <fabbione> Kamion: what is the status with Array 4? do i need to be around later or can you manage?
[04:31] <fabbione> (for the tests)
[04:31] <mxpxpod> is s-j 0.6.0 going into hoary?
[04:32] <jdub> if it goes into gnome 2.10
[04:32] <mxpxpod> jdub: cool
[04:32] <jbailey> Anyone know what "    exec 3>&- 4>&- 5>&- 6>&-" means?  Herbert Xu seems to think that the ideal of shell is to make it look as much like Perl as possible. =)
[04:32] <fabbione> jbailey: where is that?
[04:32] <zul> jbailey: kernel rules?
[04:33] <pitti> jbailey: this redirects file descriptors 3 to 6 to stdout
[04:33] <mxpxpod> ok, I have some questions on powerpc... why does ubuntu-desktop install apmd and powernowd on powerpc laptops?
[04:33] <jbailey> fabbione: initrd-tools.  I'm trying to figure out why my DSDT stuff is showing up first.   I'm trying to figure out if this would affect buffering.
[04:33] <fabbione> jbailey: ah ok...
[04:34] <mxpxpod> shouldn't pbbuttonsd take care of the apmd stuff?
[04:34] <jdub> yes, file a bug on that one
[04:34] <jbailey> pitti: Thanks.  Is it functionally any different than 3>&1 ?
[04:34] <jdub> powernowd is for cpufreq stuff in general
[04:34] <jdub> though i don't know if any macs support that (or if linux supports it on them)
[04:34] <mxpxpod> jdub: so shouldn't cpufreqd be able to replace powernowd?
 how much are you using mono? are you writing in C# ? (I', curious to 
[04:35] <tseng>           know what mono can give me)
[04:35] <jdub> no, we chose powernowd instead of cpufreqd
[04:35] <mxpxpod> jdub: ah, ok
[04:35] <mxpxpod> jdub: does powernowd work just as well?
[04:35] <tseng> mxpxpod: i prefer cpufreqd, but pnd works pretty alright
[04:35] <jdub> i believe we chose it because it is broken and uses more power than cpufreqd
[04:35] <jdub> ;)
[04:36] <mxpxpod> heh
[04:36] <mxpxpod> jdub: so you prefer cpufreqd?
[04:36] <jdub> no
[04:36] <jdub> i have a certain amount of faith that we chose the right tool for the job
[04:36] <jdub> and if we didn't
[04:37] <jdub> i can blame thom
[04:37] <mxpxpod> haha
[04:37] <zul> lolo
[04:37] <zul> lol even
[04:37] <jdub> dpkg: error processing /var/cache/apt/archives/mono-assemblies-base_1.0.5-2_all.deb (--unpack):
[04:37] <jdub>  trying to overwrite `/usr/lib/mono', which is also in package libdbus-cil
[04:37] <tseng> jdub: 
[04:37] <jdub> daniels: ping
[04:37] <tseng> sudo dpkg -i --force-overwrite /var/cache/apt/archives/mono-assemblies-base_1.0.5-2_all.deb
[04:38] <jdub> tseng: use of --force-overwrite indicates LACK OF BUG FIXAGE
[04:38] <tseng> i hit the bug in my custom mono package as well
[04:38] <tseng> im sure it will be fixed when the real deal hits sid
[04:39] <tseng> as for dbus-cil ... :)
[04:39] <jdub> no, it's a libdbus-cil bug we've seen before
[04:39] <tseng> jdub: hey, i met up with meebey and dajobe yesterday
[04:39] <tseng> cool dudes
[04:40] <tseng> meebey gave me a rebuttal to miguel
[04:40] <sivang> tseng: who are those guys?
[04:40] <tseng> basically he likes GAC and all that, but the policy is to allow people to use pnet and that stuff
[04:40] <sivang> (miguel sounds suspiciously related to gnome :)
[04:41] <tseng> sivang: miguel = vp of novell, meebey = debian-mono
[04:41] <sivang> tseng: nice
[04:41] <mxpxpod> jdub: who should I assign the pbbuttonsd bug to?
[04:41] <thom> me, probably
[04:41] <mxpxpod> thom: ok
[04:41] <jdub> mxpxpod: pbbuttonsd bug?
[04:42] <thom> and no, pbbuttonsd shouldn't be taking care of apm
[04:42] <mxpxpod> seriously?
[04:42] <thom> at least, not on x86
[04:42] <thom> no
[04:42] <thom> no way
[04:42] <mxpxpod> but on powerpc, yes
[04:42] <thom> meh
[04:43] <thom> dunno, i don't know of any powerpc kit that uses apm
[04:43] <thom> file a bug, i'll look
[04:43] <mxpxpod> ok, thanks
[04:44] <jdub> mxpxpod: the bug is that apmd is shipped on ppc
[04:44] <mxpxpod> jdub: ok
[04:44] <jdub> mxpxpod: ought to be filed against ubuntu-meta or ubuntu-desktop
[04:44] <mxpxpod> ok
[04:46] <lamont> pitti: looking
[04:46] <tseng> lamont: hey, can we sync libgdiplus 1.0.5
[04:46] <lamont> tseng: that'd be part of mono?
[04:46] <tseng> lamont: goes with mono. i cant really test the apache stuff
[04:47] <lamont> pitti: GAH!
[04:47] <lamont> pitti: dup of 5025
[04:47] <mxpxpod> thom: what's your bugzilla name?  I'll CC you
[04:47] <tseng> lamont: also monodoc 1.0.5 has a seperate source
[04:47] <thom> thom@ubuntu.com
[04:48] <lamont> pitti: would you like an upload of ubuntu17.2?
[04:48] <tseng> lamont: we already have latest gtk# and monodevelop, mod_mono and xsp i have never touched / know nothing about. i can ask meebey
[04:49] <Kamion> fabbione: I'm fine
[04:49] <Kamion> jdub: ... or against apmd?
[04:49] <mxpxpod> thom: 6166
[04:49] <lamont> tseng: monodoc is still 1.0.4-1 in debian.
[04:49] <tseng> odd
[04:49] <Kamion> thom: possibly non-Mac != Mac in this case
[04:50] <fabbione> Kamion: ok.. i am off than
[04:50] <lamont> tseng: as is libgdiplus
[04:50] <fabbione> i might pass later
[04:50] <tseng> lamont: yeah, looking at pkg-mono, updated page now
[04:50] <tseng> hm
[04:50] <tseng> mod_mono and xsp are at 1.0
[04:51] <lamont> Kamion: did you get your d-i build, or do you still need one?
[04:51] <thom> Kamion: yeah
[04:51] <thom> what does pegasos do?
[04:53] <Kamion> lamont: gotcha
[04:53] <Kamion> thom: god knows, dunno if it even cares about power management
[04:54] <lamont> Kamion: ??  want me to do a d-i build?
[04:54] <Kamion> lamont: I've got the build now thanks. sorry, got mutilated into meaninglessness somewhere between brain and fingers
[04:54] <lamont> Kamion: np.  I know that problem far too well.. :-)
[04:57] <elmo> lamont: you could fix the key tho :)
[04:57] <elmo> it looks like cut'n'waste damage
[04:57] <lamont> elmo: ah, k
[04:57] <lamont> Kamion: wanna email me a copy of what it should be for you?
[04:58] <Kamion> lamont: done
[04:59] <mxpxpod> is there a way to use bogofilter with evo?
[05:11] <tseng> mxpxpod: not in the way you are thinking
[05:11] <mxpxpod> tseng: ok
[05:11] <tseng> it might not be a difficult patch
[05:12] <tseng> s/sa-learn/bogoutil
[05:12] <mxpxpod> what about a wrapper?
[05:12] <tseng> or a config option.. spam command/ham command
[05:13] <mxpxpod> hmm
[05:13] <pitti> lamont: what was the cause? this bug did not look like it was introduced in 17.1
[05:13] <pitti> lamont: if you have a fix, go ahead
[05:15] <jdub> tseng: it's not a terribly difficult patch (i did it at oxford), but evo makes some assumptions that don't really work well with it
[05:16] <tseng> hm.
[05:16] <jdub> you can mark as spam, but not as ham
[05:16] <jdub> (not easily)
[05:16] <jdub> and bogofilter doesn't like that
[05:17] <mxpxpod> jdub: doesn't sa-learn have a --ham option?
[05:17] <tseng> bogofilter didnt like me much w/o complicating things
[05:17] <tseng> mxpxpod: yes.
[05:17] <jdub> mxpxpod: *evo* makes some assumptions that don't work well with bogofilter
[05:17] <mxpxpod> ooooh, gotcha
[05:18] <tseng> i only every got up to about 85% success with bogofilter after a month or so of use
[05:18] <tseng> im back to s-a on the server side
[05:25] <lamont> pitti: no - it was introduced in warty
[05:26] <lamont> and fixed in hoary
[05:26] <lamont> will upload
[05:26] <lamont> Kamion: key fixed - sorry for not twigging to it quicker
[05:26] <Kamion> lamont: np, thanks
[05:26] <Kamion> was it just line-wrapped or something?
[05:32] <jdub>      - beginnings of continuous viewing.
[05:32] <jdub> seb128: !!! :-)
[05:37] <sivang> Kamion: do you know if d-i is already in rosetta? (sorry to bug you on this)
[05:37] <sivang> (but it's been long since it was promised for it to reside there so people could start translate)
[05:38] <Kamion> sivang: -> daf
[05:38] <sivang> daf: is d-i in rosetta already? we are anxiously waiting to start make a *good* translation this time :)
[05:39] <Kamion> sivang: (though you'll probably find that once I apply your general rules for Debian->Ubuntu the translation level will go up markedly)
[05:39] <Kamion> sivang: er that's a kind of worrying statement; are you implying that you intend to go through and retranslate stuff that's already translated? 'cos that's generally bad
[05:40] <sivang> Kamion: no, but there are various parts that could use some lovin' , I am never in favor of duplicating work
[05:40] <Kamion> are they strings that have been branded in Ubuntu?
[05:40] <seb128> jdub: rock, isn't it :)
[05:41] <sivang> Kamion: not AFAIK, more of bad wording and strange phrasing of stuff..
[05:41] <Kamion> sivang: perhaps you could coordinate with the people translating d-i in Debian to get things fixed
[05:41] <Kamion> I am going to be a very very poor go-between to get your translations merged upstream
[05:42] <lamont> pitti: uploaded, bug closed
[05:43] <sivang> Kamion: well, I would , but we do have rosetta no? and want people to use it? ;-) I'd prefer at the moment to use rosetta for this, which seems to me less time consuming at the moment. 
[05:43] <Kamion> sivang: yeah, I'm not suggesting you shouldn't be using Rosetta, merely saying that this is something you can usefully do in the meantime rather than have everyone sitting on their hands
[05:44] <Kamion> the distro team didn't wait for Soyuz, we got on and did things the old-fashioned way until it's ready :)
[05:45] <sivang> Kamion: well sure, trouble is I already got someone with me that is eager to start working on d-i translations, and doesn't know a single thing about PO files...the bigger problem is that he is likely going to have more time to do them then me at the moment...
[05:46] <Kamion> ok, fair enough
[05:46] <daf> Kamion: are d-i source packages a normal part of the archive, or are they special?
[05:46] <Kamion> daf: they're a normal part of the archive
[05:46] <sivang> daf: Evening :)
[05:46] <Kamion> for the most part they're maintained collectively upstream though
[05:47] <daf> in that case, d-i should get pulled in when we do the mass import into Rosetta
[05:47] <Kamion> so installer-po/ tries to reflect the upstream maintenance
[05:47] <daf> given that, I'm not sure if we should special case it now
[05:47] <sivang> daf: when is the mega import planned?
[05:47] <Kamion> ok, that sort of thing's your call :)
[05:50] <lamont> mdz: looking at 4642, and trying to fathom how mount is supposed to know that it's a windows partition that is being mounted...
[05:51] <zul> lamont: doesnt mount look at /proc/mounts?
[05:51] <lamont> zul: that's the stuff that's already mounted, no?
[05:52] <daf> sivang: it's planned for next week
[05:52] <zul> lamont: true
[05:52] <daf> Kamion: coordination of changes in Rosetta with upstream is not a d-i-specific problem
[05:52] <sivang> daf: could you point a specific day? or at least, estimtion, end of the week, beggining of ?
[05:52] <Kamion> daf: that's true; I think d-i's aggregate master .po files are unusual though
[05:53] <Kamion> aren't they?
[05:53] <daf> yes
[05:53] <daf> sivang: beginning of the week rather than the end -- Carlos has a better grip on the timing than I do
[05:53] <sivang> daf: ok, thanks, I'll speak to him also :)
[05:54] <lamont> zul: I may just have to go back and read the mailing list traffic to get more context..
[05:54] <Kamion> I'm just worried about it because I have to deal with .po file merging A LOT when we're busy merging new stuff from Debian, and the edge cases that can't be auto-merged take up a lot of my time
[05:55] <zul> lamont: yeah but couldnt you put in nls=utf8 in the /etc/fstab and be done with it. i dont have a windows partition here to test it out though
[05:55] <zul> lunch...bbl
[05:56] <lamont> zul: sure - that's the manual solution. The bug asks mount to default to that
[05:57] <carlos> sivang: it depends on the speed we are able to move the needed code from my local computer to the production server (that implies tests cases to be sure all works)
[05:58] <sivang> carlos: ah ok, cooool then. I'll shut untill end of next week :)
[06:00] <daf> Kamion: you're right -- you shouldn't need to worry about this stuff
[06:00] <daf> Kamion: for now, the ideal situations is that people who fix translations in Rosetta then contact upstream and try and get their changes merged there
[06:01] <Kamion> fair enough
[06:22] <jdub> sivang: is there a romanised way of expressing hebrew? (like pinyin for chinese or romanji for japanese)?
[06:23] <sivang> jdub: do you mean to write hebrew prononciation in roman letters?
[06:23] <jdub> yeah
[06:24] <sivang> jdub: so maybe I could teach how to say some stuff ? ;-))
[06:24] <jdub> heh
[06:24] <sivang> jdub: yes ofcourse :)
[06:24] <jdub> mostly interested if there's a standard way of writing things in roman characters
[06:25] <sivang> jdub: not too much, just make sure you double the "e" when wanting to express the "eeeee" sound - for instance
[06:25] <sivang> ok, I need to think up one :) but also,
[06:26] <sivang> hrm, I need to teach you the sounds in it so you'll understand what I mean...hmm
[06:27] <sivang> I need you to hear my voice, otherwise everything I would say make no sense :-/
[06:27] <Kamion> sivang: just did a batch of Hebrew branding fixes; I think you only have about 30 fuzzy strings now, although I haven't counted untranslated strings
[06:28] <sivang> Kamion: are these going to be in rosetta eventually? (so I could review them etc)
[06:28] <Kamion> sivang: I should imagine they'll go in in the same way as everything else in the distribution
[06:28] <Kamion> there was certainly nothing unusual about my uploads
[06:28] <sivang> Kamion: cool, tnx :)
[06:32] <sivang> jdub: I could teach you how to say some stuff, but for some specific sounds, you must listen to it, for example, when right something  "HAATOOL" (which means a cat (the animal) in hebrew) you would go and use the "H" sound for the first letter, which expresses only part of the sound in the correct pronounciation.
[06:32] <sivang> s/right/you write something/
[06:32] <mdz> morning
[06:33] <sivang> morning mdz
[06:33] <Kamion> mdz: note live CD build running at the moment
[06:33] <Kamion> (hopefully array 4)
[06:33] <mdz> great
[06:33] <mdz> do you have an install set you're happy with?
[06:34] <Kamion> mdz: dunno yet, still rsyncing/burning/testing
[06:34] <daniels> jdub: pong
[06:35] <mdz> ok, I'll pull them down as well
[06:35] <jdub> sivang: i'm not interested so much in pronounciation, but whether there is a standard form of romanisation
[06:35] <jdub> daniels: n/m
[06:35] <daniels> jdub: phat
[06:35] <jdub> daniels: you remember the libdbus-cil issue with /usr/lib/mono
[06:35] <jdub> ?
[06:35] <daniels> jdub: yeah
[06:35] <jdub> daniels: that just bit me with the mono upgrade
[06:36] <sivang> jdub: not too much, there is a "common convention" of how to write in roman letters the special sounds, like the "H" sound I Just mumbled about.
[06:36] <daniels> jdub: libdbus-cil should have that fixed as of 0.23-1
[06:36] <jdub> $ dpkg -S /usr/lib/mono
[06:36] <jdub> mono-assemblies-base, libdbus-cil: /usr/lib/mono
[06:36] <daniels> jdub: unfortunately there's no way to fix the upgrade without having newer mono conflict with older versions of libdbus-cil
[06:37] <sivang> jdub: what do you need it for?
[06:37] <sivang> jdub: (the romanizatio stuff)
[06:38] <jdub> daniels: i had 0.23-2 on here before the upgrade
[06:38] <jdub> sivang: interest's sake
[06:38] <sivang> jdub: ah cool
[06:40] <Kamion> mdz: oh, fyi, I'm uploading bazaar 1.1.1 to hoary as soon as I finish fiddling with tarballs and stuff
[06:40] <mdz> Kamion: sounds good
[06:40] <pitti> Hi mdz
[06:40] <mdz> pitti: hi
[06:40] <mdz> someone on the bazaar team needs to become an Ubuntu maintainer
[06:40] <pitti> bye guys, I'm dragged away by my gf
[06:40] <pitti> have a nice weekend
[06:40] <jdub> mdz: bob2 wants to be a maintainer
[06:41] <mdz> Kamion: sync-mirrors has been taking ages recently
[06:41] <daniels> jdub: wackwackwack
[06:41] <elmo> mdz: graphviz 2 is in debian/main; can I sync it into ours?
[06:41] <mdz> elmo: definitely
[06:41] <daniels> jdub: does the new mono provide it as a directory or a symlink?
[06:43] <jdub> symlink
[06:43] <tseng> lrwxrwxrwx  1 root root 20 2005-02-04 10:27 /usr/lib/mono -> ../share/dotnet/mono
[06:45] <mdz> elmo: sync-mirrors on little has been running 40 minutes; has it hosed itself like yesterday?
[06:46] <wasabi> So... What sort of policy is there about packages depending on themselves?
[06:46] <wasabi> I have a situation where that is the only way to bootstrap it. =/
[06:46] <wasabi> Without massive hacking at least.
[06:47] <elmo> mdz: hanging on mirnyy?
[06:47] <mxpxpod> did you guys change the default cursor theme in gnome?
[06:47] <mdz> elmo: yep
[06:50] <daniels> jdub: OH M YGOD
[06:50] <daniels> jdub: symlink to directory and back to symlink again
[06:50] <daniels> dear mono,
[06:50] <daniels> make up your mind.  shit.
[06:51] <daniels> cheers,
[06:51] <daniels> daniel
[06:51] <sivang> daniels: lol
[06:51] <daniels> really bedtime now
[06:56] <mdz> wasabi: for self-hosting compilers and the like, we live with it because there is no other way
[06:56] <elmo> as long as it is a reason like a self-hosting compiler
[06:57] <jdub> daniels: seems to be "dear debian mono maintainers who do ungodly things"
[06:57] <mdz> Kamion: so the current daily-live has the amd64 noexec workaround?
[06:57] <Kamion> mdz: the one currently building will have it
[06:57] <mdz> Kamion: yeah, it's actually finished
[06:58] <Kamion> oh, hence you talking about sync-mirrors, ok
[06:58] <mdz> Kamion: the mirror trigger has been having some problems due to mirnyy being bogged down
[06:58] <Kamion> I'll ^c it and try again
[06:58] <mdz> Kamion: elmo fixed it up
[06:58] <Kamion> oh, already mirrored?
[06:59] <elmo> no
[06:59] <elmo> done amd64 + i386 tho
[06:59] <winkle> to what extent is the install sharing drivers with d-i? my cd isn't detected in latest snapshot but works fine in latest d-i rc.
[07:00] <Kamion> winkle: the install *is* d-i; detection works somewhat differently though
[07:00] <Kamion> likely to be some kind of weird hotplug issue, please send /var/log/* to a bug
[07:00] <winkle> Kamion: ok, that's what I thought, thanks.
[07:02] <fabbione> re
[07:03] <fabbione> how is going guys?
[07:03] <zul> fabbione: good except for setting up a winblows 2000 server
[07:04] <fabbione> ehhe
[07:11] <mdz> Kamion: I'm burning live CDs and downloading install
[07:12] <Kamion> I so wish I had something that resembled bandwidth
[07:13] <thom> it's overrated, your housemates will just use it all up
[07:22] <elmo> any reason why we ship every moz-thunderbird extension we support except -enigmail?
[07:22] <Kamion> thom: I'm the biggest bandwidth hog in this house by some distance
[07:28] <bradb> Can a binary package possibly come from more than one source package? (Please say no, or that it /can/ but that would not be considered a sane thing.)
[07:29] <elmo> bradb: yes
[07:29] <elmo> sorry
[07:29] <elmo> it's not common, and we could possibly avoid it for ubuntu, but there are several examples in Debian
[07:29] <Kamion> also over time obviously the answer is yes, since sometimes binaries move between sources
[07:31] <bradb> yeah, that makes sense. ooph, this throws a bit of a wrench in the works for figuring out the maintainer of a binary package though.
[07:32] <Kamion> well you can certainly discard the "over time" bit, since you just take the most current in whatever distrorelease you're looking at
[07:32] <Kamion> and there's only ever one binary of any given name in a Packages file at any one time
[07:33] <Kamion> so you just find the source corresponding to that binary
[07:33] <elmo> Kamion: yeah but if foo is from bar on i386 and baz on powerpc and bar and baz have different maintainers, who's the maintainer?
[07:33] <elmo> oh, and foo is same version on both arches :)
[07:34] <Kamion> oh, er, yeah
[07:34] <Kamion> I'd be inclined to say "all of them", from the point of view of bug tracking
[07:34] <Kamion> unless you know the architecture
[07:34] <Kamion> being limited to a single maintainer is bad anyway :)
[07:35] <bradb> a maintainer can be a group. in this case both groups would be subscribed.
[07:35] <Kamion> (and I know Debian's generally single-maintainer for everything, but debbugs does actually handle multiple maintainers on a package
[07:35] <Kamion> )
[07:35] <Kamion> multiple maintainer addresses is semantically different from a group, but sure
[07:36] <Kamion> as in the two maintainers may not be working together in any particularly meaningful way
[07:36] <elmo> kamion: or 900 maintainers may not be working together in any particularly meaningful way
[07:36] <elmo> oh, no, wait, that's Debian ;)
[07:36] <Kamion> but I realise you probably only have one slot in the database or something
[07:36] <Kamion> elmo: ;-)
[07:37] <bradb> Kamion: right now there's no "slot" for binary package maintainer, because the semantics are a bit fuzzy.
[07:37] <Kamion> actually surely this grand database of doom must be able to cope with a list? :)
[07:37] <bradb> i guess all maintainers of all the sourcepackages from which that might be built in the most current release of a distro is the best answer.
[07:37] <Kamion> bradb: mapping it via the source package seems sane anyway
[07:38] <Kamion> it's precisely as hard as having a direct maintainer mapping
[07:39] <bradb> so, in the worst case scenario, there are N sourcepackages for a given binary package in a distro release, where N == the number of arch's on which that distro release is supported?
[07:39] <bradb> s/package/package name/
[07:39] <lamont> source->binary is a 1->N mapping
[07:40] <lamont> so there are N binary packages for a given source package in a distro release
[07:40] <lamont> same source builds on all architectures.
[07:40] <bradb> lamont: what elmo said earlier seems to disagree with that:
[07:40] <bradb> [13:33]  <elmo> Kamion: yeah but if foo is from bar on i386 and baz on powerpc and bar and baz have different maintainers, who's the maintainer?
[07:40] <lamont> except on insane distros where that's not true
[07:41] <lamont> bradb: ew.
[07:41] <bradb> i.e. N<->N!
[07:41] <lamont> yeah
[07:41] <Kamion> bradb: yeah - if I were implementing it, I'd take the binary package name, look up all the entries corresponding to the actual .debs on all architectures, and get the maintainer for each of those via the corresponding source package.
[07:41] <lamont> binaries aren't maintained, source is...
[07:41] <lamont> so yeah, the (binary,arch) tuple gets you back to 1 and only 1 source package
[07:41] <bradb> lamont: yeah. i have to figure out maintainers from binaries in malone though.
[07:42] <Kamion> certainly in the Debian control file format the Maintainer: field only exists in the source stanza
[07:42] <lamont> but if they don't give you an architecture, then you have to grab all the possible source packages, I expect
[07:42] <lamont> of course, that's (binary,version,arch), since it can change from version to version... :-)
[07:43] <bradb> yeah, we're working towards a UI where the user can specify as much as they know about a bug (re: versions of various things), but I guess the less they know, the more fuzzy our job will be (i.e. maintainer subscriptions and such.)
[07:43] <dholbach> re
[07:43] <Kamion> (binary,version,architecture) uniquely identifies (source,version) uniquely identifies maintainer
[07:43] <Kamion> if that helps
[07:44] <bradb> yes, that makes perfect sense. thanks for the insight guys.
[07:44] <Kamion> if you're missing version, you have to look up the most current in the distrorelease; if you're missing architecture, you either have to guess (grotty) or try all and take the union
[07:45] <Kamion> if you've got a version but it doesn't exist, well, world of hurt etc. ;)
[07:45] <Kamion> (bearing in mind that when you're syncing bugs from Debian, bugs may be filed on versions you don't know about yet because they're still in queues you can't see)
[07:47] <Kamion> this is the point when people tend to take up a different hobby rather than think about it
[07:47] <bradb> eesh, yar
[07:48] <Kamion> so the versions *will* be valid in the future, they just aren't yet ... I think that's why versions tend to be stored as unparsed strings
[07:49] <bradb> i hope our debbugs syncing script is creating those releases before creating the infestations. sabdfl wrote it, so he'd know for sure what it's doing.
[07:49] <Kamion> well it's just not possible, not all versions you see in debbugs will be valid; in fact some will never become valid because the reporter was just wrong
[07:50] <Kamion> IIRC the plan was to throw that version information away and pretend you never saw it, but I don't know what was to be done about the will-be-valid-in-the-future case
[07:50] <bluefoxicy> anyone know which package I should install to build a .deb for a kernel source tree?  (and the appropriate documentation)
[07:51] <Kamion> bluefoxicy: apt-get source linux-source-2.6.10
[07:51] <Kamion> and satisfy its build-deps ...
[07:52] <bradb> Kamion: i have no idea if our debbugs imports take that into consideration, but i guess we'll find out. /me makes some changes to his proposal about bug triaging and package reassignment to launchpad@.
[08:00] <sri> hi all
[08:01] <sri> I'm in a bit of a quandary after today's update from hoary
[08:01] <sri> my xorg server has a box with lines in it for a pointer
[08:01] <sri> (I'm using a matrox G400 as a card)
[08:02] <sri> and my GNOME session looks like the default theme is not loaded.
[08:02] <mdz> Kamion: live CD test was successful x3
[08:02] <sri> btw I was told to come here because it doesn't seem like a common problem
[08:02] <Kamion> mdz: install powerpc successful, live powerpc test pending
[08:02] <sri> I can run back to #ubuntu if this is not appropriate :)
[08:03] <mdz> Kamion: I'm going to do powerpc and amd64 installs next
[08:03] <Kamion> thanks, I'll be doing amd64/i386 installs in a moment
[08:06] <sri> rubenv: i figured out that the icon problem I was having is because industrial disapeared on me.
[08:07] <sri> rubenv: and I'm wondering if my pointer is theme related as well.
[08:07] <Kamion> bleh, stupid burner
[08:12] <rubenv> sri: my mouse pointer has just resetted itself after upgrading :/
[08:17] <sri> rubenv: ok..yeah, so I think thast why I'm getting that strange mouse pointer
[08:17] <sri> rubenv: because my icon theme got resetted as well.
[08:17] <sri> rubenv: in fact even though the industrial theme engine is installed it's not showing up in the themes manager.
[08:20] <Treenaks> does anyone else's firefox look ugly?
[08:20] <tseng> there was an update to gnome-themes, the engines were split out
[08:21] <Treenaks> ah ok
[08:21] <tseng> the industrial cursors dont seem to be installed anymore
[08:21] <tseng> this is all #ubuntu stuff i believe.
[08:21] <Treenaks> tseng: not only that..
[08:21] <tseng> ya?
[08:21] <sri> tseng: yep..thats why my mouse looks like ass :)
[08:21] <tseng> yes
[08:22] <Treenaks> tseng: it lost looks ugly :)
[08:22] <sri> any quick fixes?
[08:22] <tseng> um, install it from ximian-artwork srpm if it bugs you that much
[08:22] <tseng> in novell i believe it is packed inside of the gnome-artwork srpm
[08:22] <sri> tseng: I have a mouse pointer that looks like a box with lines in it
[08:22] <tseng> older releases were ximian-artwork
[08:22] <Treenaks> tseng: uh.. I /do/ have the engines installed
[08:23] <Treenaks> or so it seems
[08:23] <sri> tseng: so it sort of interferes. :-)
[08:23] <tseng> i mean the cursor theme.
[08:23] <rubenv> tseng: i have all industrial stuff
[08:23] <tseng> not the engine
[08:23] <rubenv> yet still no blue icons
[08:23] <tseng> what do you mean, blue icons?
[08:24] <tseng> are you talking about the icon theme now?
[08:24] <rubenv> yeah, that got resetted too
[08:24] <tseng> i have one guy telling me about his engines, one his cursor, and one his icon theme
[08:24] <rubenv> as well as my mous
[08:24] <tseng> slow down and read the facts
[08:24] <rubenv> *mouse
[08:24] <tseng> all you should have now is the industrial *engine*
[08:24] <Treenaks> tseng: and the theme
[08:24] <tseng> the icon theme and cursor are gone
[08:24] <rubenv> eh :/
[08:24] <tseng> Treenaks: yes.
[08:25] <rubenv> why bork out those?
[08:25] <tseng> you can install them, as i said, from novell srpm
[08:25] <tseng> or hold onto your pants until jdub or whoever puts them back in
[08:25] <Treenaks> jdub: I seem to be looking for my pants 8)
[08:25] <rubenv> oh, they're only borked temporarly
[08:25] <sri> jdub is always without his pants. :)
[08:25] <Treenaks> rubenv: it's hoary.. we should've expected this ;)
[08:26] <tseng> seeing as that cursor was ubuntu default, id say its meant to be put back
[08:26] <Treenaks> sri: I know.. I was in Mataro
[08:26] <sri> tseng: indeed. :)
[08:27] <tseng> also, its deadly obvious, so not much need to report it on irc like this
[08:27] <Treenaks> tseng: anyway, mozilla in plain GTK theme looks ugly ;)
[08:27] <tseng> if anyone wants to search/make a proper bug tracker however, feel free
[08:27] <Treenaks> tseng: I always ask if it's known here... bugzilla's search feature is often useless
[08:27] <sri> tseng: I agree.  I was just making sure that it wasn't something I changed
[08:27] <tseng> no, its certainly valid
[08:28] <sri> tseng: btw.. are you still creating bugzilla accounts?
[08:28] <tseng> is there a problem with them? i know nothing about bugzilla.
[08:28] <sri> tseng: oh..for some reason I thought it was you we wer supposed to send mail to for bugzilla account..nm if I'm wrong.
[08:29] <tseng> no.. you can sign up on the web form
[08:29] <Treenaks> sri: no.. bugzilla is all web-based afaik
[08:29] <sri> yeah I have, months ago and I tried to follow up but I never got one created.
[08:29] <sri> but that was back in november/december.
[08:29] <sri> maybe it's changed now.
[08:30] <tseng> i had a bugs account since october
[08:30] <tseng> if not before
[08:30] <sri> nod.
[08:33] <Kamion> it was never actually manual
[08:34] <Kamion> just sometimes if bugzilla and your mail system didn't like each other, there had to be manual intervention
[08:35] <sri> oh nice, created abugzilla acct.
[08:37] <Simira> jdub: ping?
[08:39] <Treenaks> Simira: yes, themes are broken ;)
[08:39] <douglas> hi !
[08:39] <douglas> is there a place to download hoary images ?
[08:39] <Simira> Treenaks: huh? what is broken?
[08:39] <Treenaks> Simira: oh it looks broken here... nm :)
[08:39] <Kamion> mdz: install/i386 is good; burning install/amd64; I'll be out at dinner for a while this evening, but will come back to do the release
[08:39] <mdz> Kamion: amd64 and powerpc both in archive-copier at the moment
[08:40] <mdz> douglas: http://cdimage.ubuntu.com/
[08:40] <douglas> tnx :)
[08:41] <elmo> Kamion: when do you plan to put array's on releases, if ever?
[08:41] <Kamion> elmo: sabdfl said when RC happens
[08:42] <elmo> boggle
[08:42] <Kamion> I was fed up with the to-and-froing and that seemed a reasonable answer, so I left it at that
[08:47] <elmo> [sorry about hoary-changes...] 
[08:47] <mdz> Kamion: powerpc and amd64 both chugging along happily through stage 2, going very well
[08:48] <mdz> your prompting changes have really accelerated my test cycle
[08:48] <mdz> I switched the KVM over to powerpc to answer the prompts, and when I finished and switched back to amd64, it was already unpacking packages :-)
[08:49] <Kamion> mdz: heh, fair enough :)
[08:50] <Kamion> elmo: what about it?
[08:50] <elmo> Kamion: 79x auto sync spam
[08:50] <mdz> blame me
[08:50] <Treenaks> elmo: that explains the beeping
[08:50] <Kamion> d'oh
[08:50] <sri> woo..got it going
[08:51] <sri> mouse pointers look good
[08:51] <sri> only my icons need fixin
[08:51] <sri> jimmac to hte rescue :)
[08:52] <Kamion> amd64 working well and installing ubuntu-desktop, I'll be back later
[08:52] <Kamion> (to publish)
[08:56] <mdz> Kamion: amd64 complete
[08:57] <fabbione> Kamion, mdz: fix grub!
[08:57] <fabbione> :P
[08:57] <fabbione> you both got emails BTW
[08:57] <elmo> can anyone rember any previous imports from non-Debian sources, other than MythTV and Marillat?
[08:58] <tseng> elmo: imports from me pre-hoary
[08:58] <elmo> tseng: right.. but, we get mono stuff via Debian and/or MOTU uploads now, right?
[08:58] <tseng> yes.
[08:58] <elmo> ok, thanks.. anything else, anyone?
[08:59] <mdz> not that I recall
[09:06] <elmo> heh, nice sign off
[09:09] <mdz> elmo: do you know if i'm supposed to be able to login to the wiki this week?
[09:09] <sm> mdz: the main wiki ?
[09:10] <sm> if so: yes you are
[09:10] <mdz> then it isn't working for me
[09:10] <mdz> "you are not logged in"..."Welcome, you are logged in!" on the same page
[09:12] <sm> here's what I just did: went to http://www.ubuntulinux.org/wiki , clicked "log in" at top right, entered name/pw, then it showed me FrontPage again, logged in
[09:12] <sm> what did you do ?
[09:14] <elmo> mdz: WFM - are you using ul.o still?
[09:14] <mdz> elmo: I tried www.ubuntu.com, www.ubuntulinux.org, and site-edit.ubuntulinux.org
[09:14] <mdz> none work
[09:16] <sm> I logged in at  http://www.ubuntulinux.org, and ended up at https://www.ubuntulinux.org
[09:16] <sm> as long as I stay at https, I'm logged in.. any other url and I'm not
[09:16] <elmo> umm, not being funny, but try some browser you don't normally use? in case your normal one has it's cookies all confused
[09:16] <sm> this sounds like https://bugzilla.ubuntu.com/show_bug.cgi?id=5725
[09:17] <sm> at least it would help
[09:17] <mdz> elmo: as a matter of fact, this browser has another tab which is logged in and working
[09:17] <elmo> mdz: score
[09:18] <mdz> elmo: score + WTF
[09:19] <elmo> maybe logging in twice confuses it?
[09:19] <mdz> possible, if idiotic
[09:20] <sm> elmo, are you apache/squid admin ?
[09:21] <elmo> sm: one of, yeah
[09:21] <sm> I am the wiki guy and know plone/zope some
[09:21] <elmo> we don't use squid tho
[09:21] <sm> oh, my mistake
[09:21] <elmo> we use apache's own caching
[09:21] <elmo> sm: yeah, I figured from the list of channels you're on :) nice to meet you
[09:21] <sm> likewise
[09:22] <sm> any thoughts on 5725 ? this multiple urls can really confuse logins
[09:22] <elmo> yeah, I'll take a pass at it tonight
[09:22] <elmo> we're a bit headless chicken when it comes to plone atm, with Lu gone
[09:22] <sm> oh, gone ?
[09:23] <sm> didn't know.. well ping me if I can help at all
[09:23] <elmo> sm: thanks, will do
[09:24] <elmo> sm: yeah, she got a job working on a movie
[09:24] <sm> ah.. plone not glamourous enough eh
[09:24] <sm> :)
[09:25] <lamont> sm: amazingly, plone was not quite the dream job for her that the movie one is...
[09:25] <sivang> lamont: hehe
[09:26] <sivang> elmo: She told me it was something for the discovery channel right?
[09:26] <sivang> (IIRC)
[09:34] <rcaskey_> are things looking good for Array4 today?
[09:45] <sivang> mdz: regarding #6092, would you favor a patch to remove the option completely from the gui?
[09:45] <sivang> mdz: (that is the input box for the UID)
[09:45] <mdz> rcaskey_: yes
[09:47] <rcaskey_> mdz: great, although it looks like I won't have it by the time I leave work ;)
[09:48] <rcaskey_> I guess it's no big loss, can't get on the torrent anyway from here
[09:48] <mdz> sivang: the problem is not the code changes, but agreeing on what should be done
[09:48] <mdz> carlos seems to disagree
[09:49] <sivang> mdz: I know, but you seemed to really discontent the fact that such an option is so "east" with the desktop, well, maybe add a confirmation dialog when someone chages that?
[09:50] <sivang> s/east/easy
[09:50] <sivang> and that can be understandable, IMHO
[09:51] <mdz> I don't think the feature should exist at all
[09:51] <sivang> (he said he doesn't mind us patching it, as upstream we're after FF)
[09:53] <sivang> ok, I can take this to the mailing list if you like, let's see if we can get some concensus wrt what to do? The thing is, g-s-t is meant for the desktop sysadmin, which supposedly knows what he's doing..I think that can be attributed to his disagreement
[09:54] <carlos> mdz: ?
[09:54] <carlos> oh gst.
[09:54] <carlos> ok
[09:54] <sivang> carlos: hehe, yeah, not you :)
[10:02] <rcaskey_> mdz: any thoughts about an admin group that has sudo rights?
[10:02] <rcaskey_> mdz: and then users could create new admin users by just using g-s-t
[10:04] <mdz> rcaskey_: yes, this has come up several times and I think it is a good idea
[10:04] <rcaskey_> Is that to major to happen by Hoary?
[10:04] <rcaskey_> %s/o h/oo\ h/
[10:06] <mdz> it is a bit late in the game for that kind of change
[10:06] <mdz> while many people have talked about it, no one has written code
[10:06] <srbaker> what's g-s-t ?
[10:06] <rcaskey_> it would just be adding a group and one line to the default sudoers file
[10:07] <sivang> srbaker: gnome-system-tools
[10:07] <srbaker> ahh
[10:07] <mdz> rcaskey_: yeah, it sounds pretty simple. could you send a tested patch?
[10:07] <mdz> rcaskey_: I'm very busy with other things
[10:08] <zul> tseng: evilness is afoot
[10:08] <zul> later
[10:09] <sivang> rcaskey_: I can could an "Admin" profile to g-s-t, which would make creating new "admins" only choosing their profile in the add user dialog :)
[10:10] <sivang> rcaskey_: that is, add an admin profile
[10:11] <rcaskey_> mdz, I might could actually manage to do that
[10:12] <rcaskey_> what package governs /etc/groups?
[10:14] <mdz> rcaskey_: base-passwd, but you don't want to touch that
[10:14] <mdz> rcaskey_: the two packages which would need changing are sudo and passwd
[10:14] <mdz> sudo to change the default /etc/sudoers, and passwd to do add the user to the group instead of modifying /etc/sudoers
[10:15] <rcaskey_> mdz: any problem with using the group name admin?
[10:15] <mdz> rcaskey_: it's a tough call
[10:16] <mdz> we already have adm both adm and admin would be confusing
[10:16] <rcaskey_> mdz: curses you and your beagle!
[10:16] <rcaskey_> finding my email address
[10:16] <sivang> rcaskey_ , mdz : maybe the group "super" ?
[10:16] <bluefoxicy> god I suck
[10:16] <bluefoxicy> I made it build the kernel
[10:17] <bluefoxicy> tried to install the package
[10:17] <sivang> or do we have something liek this already?
[10:17] <bluefoxicy> no kernel installed
[10:17] <rcaskey_> is wheel the traditional name?
[10:17] <rcaskey_> it's admin over here in OS X land
[10:17] <bluefoxicy> yes wheel
[10:17] <tseng> rcaskey_: traditional for bsd, gentoo, osx. mdz argued that the meaning was slightly different
[10:18] <tseng> wheel is users who can su, he wanted a new group for sudo
[10:18] <mdz> wheel actually has the right semantics
[10:18] <mdz> but we don't have a wheel group
[10:18] <mdz> and if we're going to create one, wheel is a silly name :-)
[10:18] <sivang> doens't imply much of what it entails to do..
[10:22] <dholbach> i'm off to bed - sleep tight everyone
[10:22] <mdz> fabbione: still here?
[10:24] <rcaskey_> wheel is dumb
[10:24] <rcaskey_> what does the adm group do?
[10:25] <smurfix> rcaskey_: wheel has 20+ years of history behind it ...
[10:25] <smurfix> ... fortunately, all the zealots about that one tend to be *BSD people.
[10:25] <rcaskey_> if someone sees admin on a dropdown though, they might actually guess what its for
[10:25] <sivang> smurfix: is wheel used in debian for the same purpose?
[10:26] <smurfix> rcaskey_: I agree.
[10:26] <smurfix> sivang: No. Doesn't have one.
[10:34] <jbailey> IT doesn't look like LSB specifies that it be called wheel, which is nice.
[10:36] <bluefoxicy> wheel is still defacto
[10:37] <rcaskey_> so what does adm do?
[10:37] <HrdwrBoB> bluefoxicy: so is browse-in-one window
[10:37] <bluefoxicy> it is preferable that the defacto standards be stuck to in this case to avoid confusion
[10:37] <bluefoxicy> HrdwrBoB: Change defactos only when they cause a problem, not just to change them
[10:38] <rcaskey_> is visudo deprecated?
[10:38] <bluefoxicy> HrdwrBoB:  are we going to use wheel to control access to the mouse wheel?
[10:38] <bluefoxicy> :)
[10:38] <HrdwrBoB> heh
[10:39] <bluefoxicy> more pertainently, even if you change the name, you must avoid making another 'wheel' group
[10:39] <HrdwrBoB> at the same time, why be afraid of changing something
[10:39] <bluefoxicy> because other tools may rely on 'wheel' to be the symbolic name
[10:39] <bluefoxicy> unless there's a greater gain than loss, care should be taken in avoid change :)
[10:40] <bluefoxicy> (a principle commonly called "improvement" isn't it?  :P)
[10:40] <bluefoxicy> anyway
[10:40] <bluefoxicy> i'm done talking
[10:44] <rcaskey_> basic procedure is apt-src the package, copy the resulting directory, make changes, patch to get the diffs, and submit the patch?
[10:48] <rcaskey_>   --with-all-insults
[10:48] <rcaskey_> hrmm
[10:49] <HrdwrBoB> rcaskey_: yeah
[11:02] <rcaskey_> thanks all
[11:02] <rcaskey_> I'm gonna be on later with some more newbieish questions after I finish making the needed changes
[11:13] <eruin> did you decide to remove the pretty mouse cursors?
[11:26] <bluefoxicy> https://www.ubuntulinux.org/wiki/NewHoaryHedgehog  do not edit  o.o what should be edited then
[11:27] <bluefoxicy> " Security update notification GUI (MichaelVogt?)"  <-- that thing popping up in the status bar once in a while with updates, I like it, but it's completely passive
[11:27] <bluefoxicy> the damn thing just makes an icon, and then when I go down to click on i.e. gaim, I see it.  It doesn't pop up a baloon or un-autohide the panel
[11:27] <bluefoxicy> which may be a good idea
[11:28] <bluefoxicy> (considering on a stable system it should only be popping up for security updates)
[11:28] <bluefoxicy> on Windows though there's a billion of these that do that (firewalls, antivirus, windows update, disk cleanup) and they all get annoying pretty fast, so uh.  o.o
[11:29] <mdz> it displays a notification icons when updates are available, when you hover, it tells you how many, and when you click, it applies them.
[11:29] <bluefoxicy> _____________________________________ -> [ (o) <(New updates are ready to be installed) 12:31] 
[11:29] <bluefoxicy> mdz:  yeah.  My notification area is not onscreen though.
[11:29] <mdz> well, the default one is
[11:30] <bluefoxicy> true.
[11:30] <bluefoxicy> also the icon is very still from what I can see
[11:30] <bluefoxicy> Fedora has a similar thing
[11:31] <sivang> bluefoxicy: what's the pkg name for this notifier?
[11:31] <bluefoxicy> which displays a check mark when there's no updates, and a slowly pulsing/fading ! in a red sphere when there's updates
[11:31] <bluefoxicy> sivang:  I have no idea.  When I installed hoary it was there
[11:31] <bluefoxicy> or rather, a day after I installed hoary, an icon popped up in my taskbar
[11:31] <bluefoxicy> I have no idea what the running process even is
[11:32] <sivang> interesting, I didn't get it. and I dist-upgrade all the time
[11:32] <bluefoxicy> update-notifier is the process
[11:32] <mdz> sivang: sudo aptitude install ubuntu-desktop
[11:32] <bluefoxicy> Package: update-notifier
[11:33] <bluefoxicy> or what mdz said
[11:33] <bluefoxicy> htf it got running I'll never know; I have an old, left-over gnome-session from gentoo that doesn't have it in there
[11:33] <sivang> mdz: I had it :) I wonder if an upgrade removed it..
[11:33] <sivang> hmm depencency list is 10M
[11:34] <bluefoxicy> mdz:  I'm annoyed that the icon actually dissappears when there's no updates, trying to find it so I can see if there's any options to change that behavior but . . . umm.  I can't find the icon, it's dissappeared  o.o
[11:35] <mdz> that is by design
[11:36] <bluefoxicy> I noticed.  I like my running processes to be non-interactive daemons or accountable though :)
[11:36] <mdz> it is not something which should be displayed on the desktop continuously; it is only interesting when there are updates available
[11:36] <sivang> No Gimp-Print PPD files to update.
[11:36] <sivang>  * Restarting Common Unix Printing System: cupsd                         [ ok ] 
[11:36] <sivang> Setting up ubuntu-desktop (0.25) ...
[11:36] <sivang> touch: cannot touch `/var/lib/upgrade-notifier/dpkg-run-stamp': No such file or directory
[11:36] <sivang> E: Problem executing scripts DPkg::Post-Invoke 'touch /var/lib/upgrade-notifier/dpkg-run-stamp'
[11:36] <sivang> E: Sub-process returned an error code
[11:36] <mdz> sivang: sudo dpkg -P upgrade-notifier
[11:36] <bluefoxicy> heh, true but it has options doens't it?
[11:37] <bluefoxicy> ok what's eating 80% of my net
[11:37] <bluefoxicy> since when the heck do you get 190k/s in bittorrent   o.o
[11:38] <sivang> bluefoxicy: when downloading from a.u.c I do :)
[11:38] <bluefoxicy> sivang:  I thought the upgrade notifier may have been downloading things in the background, forgot about bt :)  but bt only ever does like 15k down anyway  o_O
[11:39] <bluefoxicy> anyway
[11:39] <bluefoxicy> I'm trying to find the thing to see if there's options to have it auto-download or (not that I actually recommend anyone set this) auto-install updates
[11:39] <sivang> well you can do this "manually" by adding cron entries
[11:40] <sivang> (I did it once, didn't end all too good, for a sid machine)
[11:40] <sivang> dholbach: hey, didn't you say you were going to sleep? :)
[11:40] <bluefoxicy> yes but while we're flashing icons around we might as well have one appear that in hover says "updates being downloaded (20%)"  "Uploads being installed (45%)"  "*blink* *blink* GPG key updates, attention REQUIRED"
[11:40] <dholbach> sivang: couldnt sleep
[11:41] <sivang> hmm, I now have readahead. cool
[11:41] <dholbach> sivang: i guess i'll learn a bit - that will make me sleep well :-)
[11:41] <bluefoxicy> heh.  "GPG updates are available.  Please check ubuntulinux.org, browse the site, make sure it hasn't been owned, and then check to make sure the key fingerprints match before installing"
[11:42] <sivang> now that's a first timer that I don't really feel updatedb slashing down my disk acces , nice
[11:50] <Kamion> bluefoxicy: speaking of de facto, the wheel group on many systems is de facto gid 0. (a) we already have root as gid 0, adding another name for it would be confusing, (b) I don't think we should be adding users to gid 0 by default, since that gives them significant extra privileges without the need even to use sudo (therefore without passwords etc.)
[11:51] <Kamion> sivang: there's already a program called 'super' which is similar to but distinct from sudo, so I feel we should be careful about using that name
[11:51] <bluefoxicy> Kamion:  wheel == root wtf?
[11:51] <bluefoxicy> I thought wheel was 76
[11:51] <Kamion> bluefoxicy: wheel is gid 0 on lots of systems. There is currently no gid wheel in Debian/Ubuntu; if it were to exist, it would really have to be defined in base-passwd.
[11:52] <Kamion> (which I maintain)
[11:52] <Kamion> bluefoxicy: 76 must just be one particular system, I've never heard of it having that value
[11:52] <Kamion> there is almost no standard for gid name/number mapping
[11:53] <Kamion> there are a couple which are common and even those you can't rely on 
[11:54] <Kamion> bluefoxicy: FreeBSD has wheel:0 for example; see http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/group?rev=1.31&content-type=text/x-cvsweb-markup
[11:54] <Kamion> I'm sure the other BSDs and practically any Unix directly descended from BSD are similar, since according to FreeBSD CVS that was in 386BSD
[11:56] <bluefoxicy> hmm
[11:57] <bluefoxicy> Kamion:  odd.  I've seen wheel in i thought gentoo and one other I can't remember. . . I think itm ight have been mandrake, I dunno anymore though
[11:57] <Kamion> also note pam_wheel which refers to traditional semantics of the wheel group
[11:57] <bluefoxicy> I remember noticing it when i tried to su
[11:58] <bluefoxicy> it was like "authentication denied" and I was like "BUH?"
[11:58] <mdz> Kamion: welcome back
[11:58] <bluefoxicy> a bit of googling brought up the wheel group
[11:58] <bluefoxicy> my mistake
[11:58] <mdz> Kamion: I'm 5 for 5 in my tests of the current dailies
[11:58] <Kamion> mdz: yeah, I'm publishing as I type
[11:58] <Kamion> fabbione: grub> aha!
[11:59] <Kamion> fabbione: ... although I see no PROT_anything in grub. will have to investigate.
[12:00] <mdz> Kamion: do we need thom to get the torrents going?
[12:01] <Kamion> mdz: yes