[12:03] <ogra> mem ?
[12:03] <ogra> should work
[12:03] <Burgundavia> ogra, what soc thing are you mentoring?
[12:03] <Mez> I need a linux distro that'll run on this
[12:03] <Mez> http://www.dsl-ltd.co.uk/products/6070spec.htm
[12:03] <ogra> Burgundavia, the above :)
[12:04] <Burgundavia> ogra, ubuntu-lite?
[12:05] <ogra> Burgundavia, and graphical config tools... which is a bit odd for a bounty since all thing listed on the spec are already done fine upstream.... so the SoC student had not many options... but he made the best out of it :)
[12:05] <ogra> Burgundavia, yep
[12:05] <Burgundavia> ogra, yes. I was wondering the same thing. But the ndisgui thing is worth it
[12:07] <ogra> you already saw it ? 
[12:07] <Burgundavia> yes
[12:07] <Burgundavia> poofyhairgui on the forums found it and posted it about it
[12:08] <ogra> heh
[12:08] <ogra> it'll be in universe soon ...
[12:08] <Burgundavia> you can even download debs for it
[12:08] <ogra> i know
[12:08] <ogra> i reviewed them
[12:09] <Kamion> daniels: please make xserver-xorg stop prompting me for questions in triplicate every time I upgrade it
[12:10] <Kamion> lamont: libgl1-xorg-dev should be happier now
[12:12] <Nafallo> users want to add breezy to install valknut :-P
[12:13] <Nafallo> I'm trying to explain to them why it is a bad idea ;-)
[12:15] <Mez> ogra: got any link for the ubuntu light project
[12:17] <ogra> currently not... im on a thin clinet here 
[12:17] <ogra> but something like www.ubuntulite.org ...
[12:17] <Burgundavia> gah
[12:18] <paolo> Burgundavia, which SoC project is it?
[12:18] <Burgundavia> paolo, which one?
[12:18] <paolo> Burgundavia, the one you were talking about some lines ago.
[12:18] <Burgundavia> paolo, ubuntu lite is LIghtweightDesktop or something
[12:18] <Burgundavia> GraphicalConfigTools
[12:19] <ogra> Mez, http://ubuntulite.org/wiki/index.php/Main_Page
[12:20] <Burgundavia> ogra, any idea why most of the ubuntulite project has been done outside the official channels?
[12:20] <paolo> Nice :-)  I'm a SoC-er too (but not for ubuntu)
[12:20] <ogra> Burgundavia, because they were already existent and nearly done with their version 1 wher the SoC started
[12:21] <Burgundavia> ah
[12:21] <Burgundavia> paolo, what are you doing?
[12:21] <paolo> Burgundavia, Haskell bindings for Cairo, and integration in the Haskell Gtk+ bindings <http://haskell.org/gtk2hs/>
[12:21] <Burgundavia> hmm
[12:23] <ajmitch> ogra: it'd be nice to see these people working in the existing development community
[12:23] <ogra> ajmitch, yes... but you cant force people
[12:24] <ajmitch> I know
[12:24] <ajmitch> ogra: and I guess you tried recruiting them as MOTUs :)
[12:25] <ogra> heh.... after they finished their projects... let them focus on their work now ;)
[12:25] <Burgundavia> I think that people see Ubuntu has this giant monlithic entitiy
[12:25] <Burgundavia> and they think it is hard to get involved
[12:25] <HrdwrBoB> Burgundavia: but they see it as that because it works
[12:26] <Burgundavia> I spend a lot of words/time on the forums telling people to join the official efforts (motu, doc team, etc.)
[12:26] <HrdwrBoB> a whole lot of software that generally works well and together appears every six months
[12:26] <ajmitch> they see the developers as far above the ordinary users?
[12:27] <Burgundavia> yes
[12:27] <Burgundavia> and Ubuntu is one of the easiest distros to get involved in
[12:27] <ajmitch> I'd say
[12:27] <ogra> thats because we have a split community.... forum people vs. mailing list people
[12:28] <Burgundavia> most developers rarely read the forums
[12:28] <HrdwrBoB> I rarely read either
[12:28] <ogra> and i dont know any devs that do it
[12:28] <Burgundavia> if you took all my posts on the forums, probably over half are "file a bug, devs won't read it here"
[12:28] <tseng> if it wasnt for you, the bug would sit there forever
[12:29] <azeem> the forums need to be more bidirectionally gated, to unite the communities
[12:29] <paolo> Do you know which xorg packages defines "string literal" colors (if any) ?
[12:29] <tseng> and people would get bitter because no one cared about their "bug report"
[12:29] <ogra> azeem, they are
[12:29] <Burgundavia> there is talk about extending launchpad login to the forums
[12:29] <Burgundavia> but they use non-free software
[12:30] <Lathiat> heh
[12:30] <tseng> the current forums seems to want me to sign up every time i click my mouse
[12:32] <pitti> seb128: still here?
[12:33] <seb128> yep
[12:33] <pitti> seb128: I pinpointed the bug on amd64, but it's nontrivial to solve
[12:33] <pitti> seb128: is there any gdk function to determine the work area?
[12:33] <seb128> oh, what is it?
[12:34] <pitti> seb128: i. e. the screen size minus panels etc.
[12:34] <pitti> seb128: it calls XGetWindowProperty to determine the desktop work area size
[12:35] <pitti> seb128: on i386 this returns 32 bit ints, on amd64 it returns 64 bit numbers
[12:35] <pitti> (in an array)
[12:35] <pitti> so the coordinates are totally off on amd64 and you can't see the window
[12:35] <seb128> there is no gdk function for that afaik
[12:35] <pitti> but instead of brutally fixing that, I'd rather use a gdk function to determine the desktop size
[12:35] <pitti> seb128: darn
[12:36] <pitti> seb128: it almost seems that XGetWindowProperty has a bug...
[12:37] <seb128> nautilus seems to do
[12:37] <seb128>         XGetWindowProperty (display, RootWindow (display, screen_num),
[12:37] <seb128>                             XInternAtom (display, "ESETROOT_PMAP_ID", False),
[12:37] <seb128>                             0L, 1L, False, XA_PIXMAP,
[12:37] <seb128>                             &type, &format, &nitems, &bytes_after,
[12:37] <seb128>                             &data_esetroot);
[12:37] <pitti> and I would feel bad if I just worked around that
[12:37] <paolo> I think the problem is that xorg misses some packages other than the ones listed in the mail pitti pointed me before.
[12:37] <seb128>         retval = XGetWindowProperty (GDK_DISPLAY (), GDK_ROOT_WINDOW (),
[12:37] <seb128>                                      window_id_atom, 0, 1, False, XA_WINDOW,
[12:37] <seb128>                                      &actual_type, &actual_format, &nitems,
[12:37] <seb128>                                      &bytes_after, &data);
[12:37] <pitti>     int result = XGetWindowProperty(GDK_DISPLAY(), win, workarea, 0,
[12:37] <pitti>                                      max_len, False, AnyPropertyType,
[12:37] <pitti>                                      &type, &format, &num,
[12:37] <pitti>                                      &leftovers, &ret_workarea);
[12:38] <pitti> seb128: format is 32 on amd64, although it returns 64 bit ints
[12:38] <pitti> so 
[12:38] <paolo> Could you tell me in which package is "showrgb" ?
[12:38] <pitti>     guint32 *workareas = (guint32 *)ret_workarea;
[12:38] <pitti>     rect.x      = workareas[disp_screen * 4] ;
[12:38] <pitti>     rect.y      = workareas[disp_screen * 4 + 1] ;
[12:38] <pitti> breaks
[12:38] <ogra> why dont you use GDK_ROOT_WINDOW () instead ? 
[12:39] <pitti> ogra: and determine its size?
[12:39] <ogra> yup
[12:39] <ogra> there are various others to use: http://developer.gnome.org/doc/API/2.0/gdk/gdk-X-Window-System-Interaction.html
[12:41] <pitti> ogra: cool, do you know how to query the size?
[12:41] <ogra> nope, never did that....
[12:42] <pitti> this GetProperty thingy fails, so using it to determine the size of it leads to the same proble
[12:43] <paolo> Sob.  In hoary showrgb is in xutils, but there isn't in breezy.
[12:46] <paolo> Seveas, do you know if there is an online search for this kind of things?  Like "file -> package"
[12:47] <ogra> pitti, gdk_window_get_geometry ()
[12:47] <Kamion> paolo: http://packages.ubuntu.com/; but (a) it may be out of date and (b) showrgb is probably just missing at the moment, due to the in-progress xutils reorg
[12:47] <ogra> pitti, http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#gdk-window-get-geometry
[12:48] <paolo> Kamion, I was searching for that because of this error running emacs: 'Undefined color: "black"'.  And #freedesktop guys told me that string literals are defined in some file belonging to showrgb or something.
[12:48] <pitti> ogra: doesn't fit, take a penalty card :-)
[12:49] <ogra> heh
[12:49] <pitti> ogra: that's only for gdk windows, not for X window IDs
[12:50] <ogra> and a GDK_ROOT_WINDOW () isnt a gdk window ? 
[12:51] <pitti> no, an X window id
[12:52] <pitti> XGetWindowAttributes() - let's try that
[12:52] <ogra> yeah
[12:52] <ogra> hanst X a GetGeometry too ? 
[12:52] <ogra> hasnt even
[12:54] <luis_> mjg59: whaaaaa
[12:54] <luis_> mjg59: I want my graphical boot now
[12:54] <mjg59> luis_: I'm hacking on it
[12:55] <mjg59> Stuff is being mean to me
[12:55] <Burgundavia> mjg59, are lappys expected to be shipped this week?
[12:55] <mjg59> Burgundavia: Yes
[12:55] <Burgundavia> ok
[12:55] <Lathiat> ooh nice
[12:56] <luis_> you're all getting new lappys?
[12:56] <Kamion> lamont: a give-back of nautilus/i386 once the buildd chroots have been repaired would be very much appreciated
[12:57] <Kamion> (it sorta breaks the world through out-of-date nautilus-data_all.deb
[12:57] <Kamion> )
[12:57] <lamont> Kamion: ok...
[12:59] <ogra> pitti, http://seth.positivism.org/man.cgi/3/XGetWAttr
[01:00] <pitti> ogra: that's what I'm trying right now :-)
[01:00] <ogra> :)
[01:02] <Makako> Zquit
[01:02] <Makako> Oops ;)
[01:03] <Burgundavia> mjg59, I have placated the ravaging hordes at the forums with the news that Usplash is being worked on
[01:03] <lamont> Kamion: pardon me while I rampage through all of main :0)(
[01:04] <mjg59> Burgundavia: Hurrah!
[01:04] <Kamion> lamont: fair enough :)
[01:05] <Nafallo> lol
[01:05] <ogra> mjg59, you could become ubuntu DPL (if we hadnt already a dictator) after finishing usplash... it will make you paparazzi-popular ;)
[01:06] <mjg59> Haha
[01:06] <Nafallo> hihihi
[01:06] <Burgundavia> I also got to include the whinging of luis_ in there too ;)
[01:06] <luis_> haha
[01:06] <ogra> lol
[01:06] <luis_> I'm not whinging, I'm trying to improve the livecd. ;)
[01:06] <tseng> what happens if i apt-get usplash atm?
[01:06] <luis_> <- master of subtle differences
[01:07] <ajmitch> Burgundavia: laptops soon? great, means I might see it in 2 months :)
[01:07] <ogra> tseng, you get a package installed ?
[01:07] <luis_> ogra: what does that package do? :)
[01:07] <tseng> ogra: good one.
[01:07] <Nafallo> ogra: naah, that's apt-get install :-)
[01:07] <ogra> tseng, err, actually you get an error :)
[01:07] <Burgundavia> I installed usplash
[01:07] <Nafallo> tseng: I belive it will tell you that usplash isn't a valid command :-)
[01:07] <tseng> meh
[01:08] <ogra> heh
[01:08] <tseng> you guys are tools
[01:08] <luis_> Burgundavia: and what did it do? :)
[01:08] <Nafallo> hehehe
[01:08] <mjg59> Burgundavia: Yeah, it might work soon
[01:08] <Burgundavia> after my hardware testing by kicking power cord out, nothing happened
[01:08] <ajmitch> that's a shame
[01:08] <ajmitch> power cord testing isn't the most reliable though
[01:09] <Burgundavia> no
[01:09] <Burgundavia> but the ext3 journal recovered fine
[01:09] <ajmitch> especially if you were installing something at the time
[01:09] <Burgundavia> it had finished installing, luckily
[01:10] <mjg59> Burgundavia: It won't do anything without initramfs
[01:10] <mjg59> (and at the moment that won't quite work properly - give me a few minutes and there'll be a new upload)
[01:10] <Burgundavia> ok
[01:10] <lamont> Total 5917 package(s) in state Installed.
[01:10] <lamont> Total 442 package(s) in state Needs-Build.
[01:11] <lamont> Kamion: ^^^ have a nice day
[01:11] <jbailey> lamont: You need a w-b state "B0rked"
[01:11] <ogra> heh
[01:12] <lamont> mind you, most of those 442 packages will fail again
[01:13] <pitti> ogra: darn, that works, but gives the complete root window, not the workspace
[01:13] <ogra> there must something similar for the workspace
[01:14] <ogra> sorry phone...
[01:16] <seb128> src/common/gst-package.c:64: undefined reference to `_'
[01:16] <seb128> collect2: ld returned 1 exit status
[01:16] <seb128> grumpf
[01:17] <pitti> hey, wait...
[01:17] <Lathiat> heh
[01:18] <pitti> YAY, YAY, YAY
[01:18] <seb128> pitti \o/
[01:18] <tseng> whats new pitti?
[01:18] <sladen> ajmitch: I'm expecting to pick one up tomorrow
[01:18] <pitti> seb128: how stupid...
[01:19] <pitti> "If the returned format is 32, the returned data is represented
[01:19] <pitti>        as a long array"
[01:19] <pitti> seb128: i. e. even if format is 32, I have to use a long (64 bit)
[01:19] <pitti> so if that is the spec, fine :-)
[01:20] <seb128> pitti: why does it return 32 if the format is 64 ?!
[01:21] <pitti> seb128: other way round 
[01:21] <pitti> ask the X authors
[01:21] <seb128> bah
[01:21] <seb128> kick daniels? :)
[01:22] <ajmitch> sladen: living in NZ has it's disadvantages
[01:39] <HrdwrBoB> tell me, is there any reason why the gnome weather applet can't get the location from the timezone as a default
[01:39] <seb128> it does
[01:40] <HrdwrBoB> since recently?
[01:40] <nickrud> Is there a way to see if a package is in the build queue?
[01:40] <HrdwrBoB> it's defaulted to pennsylvania always for me
[01:40] <HrdwrBoB> which is a long way from melbourne
[01:40] <seb128> what locale do you use?
[01:40] <seb128> maybe it uses the locale
[01:40] <HrdwrBoB> en_AU
[01:41] <HrdwrBoB> the timezone is a bit more specific though
[01:41] <luis_> yes, because weather here in boston is just like the weather in miami!
[01:41] <luis_> if it should try to guess at all, it should be from the address in about me
[01:42] <HrdwrBoB> still in the right continent though
[01:42] <luis_> guessing from timezone is basically useless unless you live in hawaii
[01:42] <seb128> it picks Paris here
[01:42] <HrdwrBoB> Your current time zone is set to Australia/Melbourne
[01:42] <Lathiat> well on ubuntu you usually set a location at the start
[01:42] <Lathiat> do other distros do similar?
[01:42] <HrdwrBoB> that's precisely where I am
[01:42] <luis_> you're in a small minority then
[01:43] <Lathiat> i set mine to where i am too, heh
[01:43] <Lathiat> Australia/Perth
[01:43] <HrdwrBoB> luis_: well, for the small minority it would be correct
[01:43] <HrdwrBoB> and the the majority it would be in the right area at least
[01:44] <pitti> good night everybody
[01:44] <mjg59> luis_: You need usplash-0.1-2 (which will hit the archive shortly) and the latest initramfs-tools, then mkinitramfs -o /boot/initrd-foo
[01:45] <luis_> coolio
[01:45] <seb128> HrdwrBoB: they use the translation to set the default 
[01:45] <luis_> thanks, dude
[01:45] <mjg59> luis_: But be warned that it's very ugly right now
[01:45] <mjg59> And doesn't really do anything useful
[01:46] <pitti> good night
[01:46] <luis_> if it can hide the text behind an arbitrary image which contains the string 'please wait', then it is a step up for me
[01:49] <mjg59> luis_: Well, sort of
[01:49] <mjg59> You'd need a couple of hacks for that
[01:50] <Kamion> nickrud: you look in http://people.ubuntu.com/~lamont/buildLogs/Lists/, but you might want to get somebody who knows how to interpret those
[01:50] <nickrud> Kamion, thanks, I'll see what I can see
[01:50] <luis_> mjg59: anyway, I'll play with it
[01:51] <mjg59> luis_: Basic idea is: splash appears. Scripts call command that writes stuff to splash. Splash vanishes after timeout.
[01:52] <mjg59> There's still a tiny bit of work needed to get it to work on both sides of the root filesystem being mounted, but you could just up the timeout
[01:55] <robertj> (what I really mean is that it probably shouldn't be on the panel by default)
[02:23] <nickrud> Kamion, most of it is self explanatory  (at the level I needed:), thanks
[03:15] <luis_> mdz, anyone else: where would it be best to discuss the liveCD? ubuntu-devel?
[03:52] <daniels> Kamion: worksforme
[03:55] <mjg59> daniels: I've seen it to
[03:55] <mjg59> o
[04:06] <marcin> hi all 
[04:06] <marcin> I got a propably simple question... but I cannot find an answer myself
[04:07] <marcin> how you guys build packages in this way that they got *-ubuntu[somebuildversion]  suffix?
[04:07] <bddebian> marcin: It comes from the changelog
[04:07] <daniels> mjg59: it used to happen in the pre-hoary days, and I don't see what could've changed to make it come back.  of course, neither can I remember what I changed to fix it, exactly ...
[04:09] <ajmitch> daniels: I still get that, it came back recently
[04:09] <marcin> bddebian: so for example: wget (1.9.1-10ubuntu2.1) in changelog does this trick?
[04:09] <marcin> bddebian: and in fact - I know that 1.9.1 is version 
[04:09] <daniels> headdesk
[04:09] <marcin> bddebian: but what 10 and 2.1 is?
[04:10] <marcin> bddebian: (in 10ubuntu2.1 suffix)
[04:10] <bddebian> Hmm, I haven't seen a suffix like 2.1
[04:10] <marcin> bddebian: well is is in ubuntu hoary - wget package - for example
[04:11] <Kamion> marcin: generally because there had already been a -10ubuntu3 in breezy but a security fix to -10ubuntu2 needed to happen in hoary
[04:11] <Kamion> (guessing)
[04:11] <shaya> Kamion and they didn't want to go -10unbuntu2hoary1 :)
[04:11] <Kamion> shaya: that would be really rather redundant and unhelpful, if you think about it
[04:12] <shaya> it was a joke :)
[04:12] <shaya> anyways
[04:12] <shaya> is there a libgl-xorg-dev package anywhere?
[04:12] <Kamion> codenames like "hoary" don't sort well
[04:12] <Kamion> shaya: libgl1-xorg-dev
[04:12] <marcin> Kamion: so this thing after 'ubuntu' is something like build version in rpms?
[04:12] <shaya> Kamion: aptitude is giving me serious issues
[04:13] <Kamion> marcin: no
[04:13] <Kamion> shaya: it's fixed, may still be propagating to your mirror
[04:13] <marcin> Kamion: hmm any naming convention guide?
[04:13] <shaya> hmm
[04:13] <Kamion> marcin: everything after the - is the package revision (as opposed to the upstream version number)
[04:13] <shaya> I use archive.ubuntu.com
[04:14] <Kamion> marcin: "ubuntu" is an indicator that we have made substantive changes in Ubuntu so we shouldn't automatically sync new versions from Debian, and instead must merge them
[04:14] <Kamion> marcin: the bit before "ubuntu" is generally the revision of the corresponding package in Debian
[04:15] <Kamion> normally speaking, the bit after "ubuntu" is just an integer. Don't mess about with extra 2.1 bits unless you know what you're doing and absolutely have to
[04:16] <Kamion> so typically, Debian has 2.3.1-1, first Ubuntu revision against that is 2.3.1-1ubuntu1, second is 2.3.1-1ubuntu2, etc.; if Debian release 2.3.1-2, then the merged version would be 2.3.1-2ubuntu1, etc.
[04:21] <marcin> Kamion: hmmm
[04:21] <marcin> Kamion: ok then when we need to change from 1ubuntu to 2ubuntu?
[04:23] <marcin> Kamion: ahh I think I get it - first digit is _Debian_ build indicator and last number after 'ubuntu' thing is _Ubuntu_ build indicator
[04:23] <marcin> Kamion: right?
[04:25] <Lathiat> mjg59: are you interested in hearing about usplash not working?
[04:25] <mdz> luis_: ubuntu-devel, yes
[04:26] <sladen> Lathiat: yes, in what case?
[04:26] <Lathiat> sladen: on my laptop, boots, screen goes blank, no hard disk activity, alt+sysrq+b works, capslock doesnt
[04:27] <Lathiat> hrm i just realised i have a vga=771 
[04:27] <Lathiat> maybe tahts interfering
[04:28] <sladen> Lathiat: it can't cope with vesa modes
[04:28] <Lathiat> also
[04:28] <Lathiat> it should respect nosplash
[04:28] <sladen> Lathiat: it should probably check for, and ignore modes
[04:28] <Kamion> marcin: right
[04:28] <Lathiat> or not havign 'splash'
[04:28] <sladen> Lathiat: from reading the code about an hour ago, it /should/ do that
[04:28] <Lathiat> (because i had to boot a livecd to uninstall and reinstall the kernel to be able to boot again)
[04:29] <Kamion> marcin: don't touch the bit before "ubuntu" unless you're merging new code from upstream or from Debian (which you generally shouldn't be doing at this stage of the release process without getting prior approval, anyway)
[04:29] <Lathiat> i tried recovery mode and changing splash to nosplash
[04:29] <Kamion> Treenaks: hmm, I read some documentation a bit more carefully, I think that hotplug thing is actually a busybox sed bug
[04:29] <Lathiat> ill try without vga= and see what happens
[04:31] <marcin> Kamion: and what about new packages that doesn't exist in Debian repository?
[04:31] <ajmitch> marcin: they get -0ubuntu1, etc
[04:31] <Kamion> marcin: either versioned as if they were Debian packages, or as ajmitch says
[04:31] <sladen> Lathiat: 'splash' is not set for recovert mode.  nothing knows about 'nosplash'  it is  'splash' or ''
[04:32] <Lathiat> sladen: well if i set nosplash
[04:32] <Lathiat> sladen: thered be no splash
[04:32] <Lathiat> sladen: nor did it work in recovery mode
[04:32] <Kamion> I tend to use Debian-style versioning for new development, and -0ubuntu1 versioning for cases where we're temporarily running ahead of Debian
[04:32] <Lathiat> bbs
[04:32] <marcin> Kamion: ok
[04:32] <Lathiat> i saved the old initrd this time :)
[04:33] <Am|NickTaken> wtf, why does gmail-notify depend on straw (rss reader)
[04:33] <ajmitch> Kamion: we mandate -0ubuntu1 for universe new packages
[04:34] <sladen> Lathiat: nothing should happen at all in recovery mode.  Is that what you see in your case?
[04:35] <Kamion> ajmitch: for universe that's reasonably sensible I guess, since much of that should be expecting similar packaging to show up in Debian as -1
[04:35] <Kamion> ajmitch: however, I refer you to e.g. the recent usplash uploads
[04:36] <Lathiat> sladen: nope, it still screwed up, however i just found out that i want the second version that was uploaded as without vga=771 i saw a kernel panic after some random foo 
[04:36] <Lathiat> (cus init died)
[04:37] <ajmitch> right, I mainly deal with packages that MOTUs review for universe
[04:37] <ajmitch> where it's easiest just to have a consistent scheme, and try &get it into debian
[04:37] <sladen> Lathiat: okay, so a kernel panic.  can you replicate it and record what the kernel paniced over?
[04:37] <marcin> Kamion: btw you want always follow debian repositories?
[04:37] <Lathiat> sladen: it had errors about the usplash_something-init, i saw a changelog entry about -s in the variables, so i'll get that new version and try it first
[04:38] <marcin> Kamion: or is this possible to create some really _different_ packages for ubuntu?
[04:38] <marcin> Kamion: (different - I mean different than in debian)
[04:39] <Kamion> marcin: we can and we have
[04:39] <Kamion> marcin: but try to limit it
[04:39] <Amaranth> should i uninstall usplash? :)
[04:39] <Kamion> marcin: the fewer *unnecessary* diffs we have versus Debian, the less work we have to do
[04:40] <sladen> Amaranth: is it giving you problems?
[04:40] <Kamion> sometimes the diffs are necessary, but don't do it just for the sake of it
[04:40] <Amaranth> sladen: I'm not comfortable booting up to a live cd to 'uninstall' my kernel to fix any potential problems :P
[04:41] <Lathiat> Amaranth: 'sok, backup your old initrd first ;p
[04:41] <Lathiat> (then use the power of grub ;p)
[04:41] <Amaranth> too late
[04:41] <Lathiat> Amaranth: nah just reinstall your kernel image
[04:41] <Lathiat> copy it
[04:41] <Lathiat> and then run mkinitramfs again
[04:41] <marcin> Kamion: ok anyway I want to package some software not much important for ubuntu
[04:41] <marcin> Kamion: and I think that I create these packages mainly for myself
[04:41] <Amaranth> Lathiat: ok, but if i just uninstall usplash and reinstall my kernel it should be fine, right? :)
[04:42] <Lathiat> Amaranth: i guess?
[04:42] <marcin> Kamion: especially while I want to break some debian rules (so propably no chance to adopt my package to debian)
[04:43] <Kamion> marcin: the Debian policy is not there just for fun; it's a collection of good practice that's evolved over time. If you insist on breaking it you should be very sure of your reasons
[04:44] <marcin> Kamion: I think I'm sure - especially while some packages adopted by ubuntu from debian are not installable
[04:44] <Kamion> I would expect the universe folks to require Debian policy from new packages by default except where they've explicitly decided to do otherwise for good reasons, I think
[04:45] <Kamion> dude, uninstallability's just about dependencies, it's not generally policy
[04:45] <ajmitch> we do require policy compliance
[04:45] <marcin> Kamion: but it is only one reason
[04:45] <daniels> what reason is that?
[04:45] <sladen> Amaranth: can you boot using the recovery-mode ?
[04:45] <Amaranth> sladen: i haven't tried to reboot at all
[04:46] <marcin> Kamion: and another is that some things are installed with packages but not available for user due to screwed up config files
[04:46] <daniels> argh
[04:46] <daniels> mjg59: sessreg comes from the xdm source
[04:47] <Kamion> marcin: and you think Debian rules include "must be broken"?
[04:47] <marcin> Kamion: anyway I'm too tired now to explain all of this it's too late (4:47 here)
[04:47] <Kamion> marcin: some packages in Debian are buggy; that doesn't mean that fixing them involves breaking Debian rules
[04:47] <marcin> Kamion: well maybe not all debian rules
[04:47] <marcin> Kamion: to be more specific 
[04:48] <marcin> Kamion: the thing I want to do is a bunch of packages for Emacs
[04:48] <marcin> Kamion: and debian policy for emacs is pretty good
[04:48] <marcin> Kamion: (overcomplicated - but good)
[04:49] <marcin> Kamion: but there is a lot of broken packages - broken in different ways
[04:50] <bob2> how does any of this justify breaking policy?
[04:50] <marcin> Kamion: dependencies (for example: jde), broken config files (for example: dired-x - available in package but user needs to configure this by hand in .emacs file)
[04:51] <Kamion> so far it sounds like you're just saying "I need to fix stuff that's broken", which is fine
[04:51] <ajmitch> have you filed bugs in debian for these?
[04:52] <Kamion> the thing I'm boggling at is purely "can't fix without breaking [unspecified]  Debian rules"
[04:52] <ajmitch> at least for the issues that come from debian
[04:52] <Kamion> that does happen, but it's rare, and I'd like to hear exactly what rules you think you have to break so that people can review that decision
[04:52] <marcin> ajmitch: not yet because I know that they will give me a million of reasons why their policy is the best one and they will tell me to shut up ;)
[04:53] <bob2> so, your complaint is "Debian Emacs Policy section $blah is buggy"?
[04:53] <marcin> ajmitch: btw there are things that propably are ok in debian but not in ubuntu - like jde package - non installable in ubuntu due to problems with java
[04:54] <Kamion> Ubuntu's founded to a large extent on Debian policy; if you think the policy is broken, you need to explain *why*
[04:54] <Kamion> so that it can be fixed wherever's appropriate
[04:55] <daniels> (and fixing it will usually involve getting it fixed in Debian, also)
[04:57] <Amaranth> hrm
[04:57] <Amaranth> xnest installs into /usr/X11R6/bin/
[04:57] <sladen> Amaranth: I'm lost.  Are you wanting to uninstall because you're worried by other people's reports
[04:57] <Amaranth> sladen: yeah
[04:57] <Amaranth> sladen: doesn't matter though, i can't even make gdm work anymore :)
[04:57] <Amaranth> time to see if usplash cuts
[05:00] <Kamion> marcin: jde is uninstallable because bsh failed to build from source, which in turn is because kaffe is uninstallable; see http://people.ubuntu.com/~lamont/buildLogs/b/bsh/1.3.0-3/
[05:01] <marcin> Kamion: I know that and I said that this is dependency problem
[05:01] <Kamion> marcin: in turn, kaffe looks like it simply needs to be rebuilt for the C++ transition
[05:01] <Kamion> I'll take care of that now
[05:01] <marcin> Kamion: anyway the thing is that I don't want to broke all debian rules for emacs
[05:02] <marcin> Kamion: I just want things to "just work"
[05:02] <marcin> Kamion: and the problem is that there is really a lot of things in debian packages for emacs 
[05:02] <marcin> Kamion: that doesn't work at all - regarding if installed or not
[05:03] <ajmitch> Kamion: kaffe is on a list to be synced, I don't think the current version was building 
[05:03] <Kamion> ajmitch: the current version *has* built
[05:03] <marcin> Kamion: because propably maintainters think that emacs users are advanced one and they don't provide almost any config settings for emacs
[05:04] <Kamion> marcin: so it sounds like you're attributing all sorts of awful motives to people that in all probability aren't there
[05:04] <bob2> marcin: so, submit a patch for a sane default config
[05:04] <marcin> Kamion: and in this way every emacs user needs to spend a lot of time hacking .emacs file
[05:04] <ajmitch> Kamion: sorry, I was going by what other MOTUs had said
[05:04] <Kamion> you'll never find out if you don't talk to the maintainer who did it that way. :)
[05:05] <Kamion> we try to cooperate with Debian where possible, not just work around them :-)
[05:05] <marcin> Kamion: to make things _just work_ while it is common procedure in emacs world ( ;) ) I don't thing it is good for ubuntu image
[05:06] <Kamion> I have no objection to things just working - all I'm saying is that you seem to be being unduly pessimistic
[05:09] <marcin> Kamion: well it is pretty hard to work with debian maintainers while propably their packages are maintained in simmilar way to their debian-emacsen mailing list
[05:10] <marcin> Kamion: which is full of 'penis enlargement' spam stuff instead of real discussion
[05:11] <Kamion> problems with the lists have very little to do with quality of maintenance
[05:12] <Amaranth> well, i'm still here, i guess that's good :)
[05:12] <Amaranth> what i supposed to see any difference?
[05:12] <Amaranth> err, was
[05:12] <Kamion> anyway you should feel free to sort things out in Ubuntu; I'm just trying to encourage you not to give up on cooperating
[05:13] <marcin> Kamion: now I work on some build scripts that will create really huge amount of packages based on single *.el files
[05:14] <marcin> Kamion: (something simmilar to garnome scripts but my scripts will create *.debs with emacs things automatically)
[05:14] <marcin> Kamion: and these *.el libraries aren't packaged for debian yet
[05:15] <marcin> Kamion: so I'll try to follow debian policy this time
[05:15] <marcin> Kamion: but when I'll finish these packages I'm going to try some more difficult packages
[05:16] <marcin> Kamion: and then we'll see
[05:16] <marcin> Kamion: and now I need to go to bed, I'm too tired to talk logically
[05:16] <marcin> Kamion: and my english sucks more and more in every minute ;)
[05:19] <daniels> please don't automatically create .debs
[05:24] <TerminX> is xorg -45 safe?
[05:24] <TerminX> (yeah, I know 44 works but I feel like I have to ask ;) )
[05:24] <bddebian> OddAbe19: Are you in Lancaster?
[05:25] <daniels> TerminX: yeah, -45 is marginally safer than -44, and -46 will be safer again
[05:25] <Amaranth> latest version is actaully installable, that's a plus
[05:26] <TerminX> okay, thanks.. wanted to make sure there wasn't any weird breakage upgrading from 44 to 45 as there was with, say, 36 to 44
[05:27] <daniels> nah.  but if you don't have any problems with 44, 45 won't give you anything useful.
[05:27] <daniels> 46 will fix xnest and a couple of other small things.
[05:28] <Lathiat>  yay xnest
[05:28] <Kamion> lamont-away: please dep-wait bsh on kaffe (>= 2:1.1.5-4); MOTU will need to sync to that to fix it, I think
[05:29] <Kamion> ajmitch: you were right, it does need to be synced; 2:1.1.5-3 has some silly hardcoded dependencies (debian/shlibs.local) that were removed in later versions
[05:31] <daniels> although, um, the server looks a little special on amd64
[05:31] <daniels> so I guess it's kind of lucky that it's waiting on binary NEW
[05:32] <daniels> or that it's totally FTBFS
[05:32] <daniels> ARGH
[05:32] <Kamion> new's empty ...
[05:32] <daniels> seriously, I must have run rm *amd64* at some stage
[05:32] <daniels> headdesk
[05:34] <Kamion> whoops
[05:37] <Amaranth> ok, has usplash worked sucessfully for anyone here?
[05:37] <Lathiat> heh
[05:37] <Lathiat> you want the new version
[05:37] <Lathiat> that isnt in the archives yet
[05:38] <Lathiat> is there some way to get mail when things move into the archives?
[05:38] <Kamion> not for binaries, no
[05:38] <Lathiat> damn
[05:40] <Kamion> no i386 buildd has taken it yet; I assume they're still chasing up main backlog following the libgl1-xorg-dev fix
[05:42] <Kamion> lamont-away: a lot of stuff seems to have failed due to lack of 'apt-get update' in the buildd chroot or similar ...
[05:43] <daniels> if -46 builds on i386 and amd64, I'm going to upload it
[05:43] <daniels> so it shouldn't be too far away
[05:43] <daniels> (libosmesa being fixed also)
[05:43] <OddAbe19> bddebian, yeah, why?
[05:43] <Amaranth> hrm, cellrenderertext and mozilla don't agree on how to render this mix of ltr and rtl languages
[05:44] <infinity> Kamion : The apt sources are refreshed before each build..
[05:44] <infinity> Kamion : Example failure?
[05:49] <Kamion> infinity: nautilus_2.11.91-0ubuntu1_20050810-0236-i386-failed.gz, oem-config_0.5_20050810-0236-i386-failed.gz, others
[05:51] <daniels> i wonder if I can blame xorg's utter failure on amd64 on this
[05:53] <infinity> The nautilus failures look more like dirty chroots to me.  Or something else hideously whacky.  I'll poke after I attack my lunch.
[05:56] <infinity> Kamion : Of course, those kinds of failures also result in automatic give-backs, so if it is a transient archive issue, it'll sort itself.
[05:56] <infinity> I'll still have a look at all the chroots in a few minutes though. :)
[05:57] <daniels> Kamion: i assume the libgl1-xorg-dev thing was just causing problems for germinate?
[05:58] <Kamion> daniels: no, it seemed to be causing a bunch of weirdly fucked-up buildd chroots after failed builds
[05:59] <Kamion> or at least a lot of stuff was failing to build with cryptic messages from apt, may not have been screwed chroots
[05:59] <infinity> The weirdly-fucked-up chroots were being caused by the dpkg segv, afaict.
[05:59] <infinity> Which is unrelated.
[05:59] <infinity> Unless your change managed to work around dpkg hating itself.
[05:59] <Kamion> ah. I thought that was related to the uninstallability, though
[05:59] <Kamion> because the segv was consistently on libglu1-mesa-dev, which is intimately related to libgl-dev providers
[06:00] <Kamion> and it started happening at pretty much the same time
[06:00] <infinity> mesag-dev, actually, but yes, those packages are a nasty incestuous group.
[06:00] <Kamion> oh, it was libglu1-mesa-dev for me
[06:00] <infinity> Oh, interesting.
[06:00] <infinity> Well, I'll retry my testcase with the changes you've made and see if the dpkg segv is gone for me.
[06:00] <Kamion> did you manage to save a tar of /var/lib/dpkg/info and the .deb it was trying to install?
[06:01] <Kamion> would be nice not to lose the dpkg segv testcase
[06:01] <infinity> Installing one deb never did it for me.  I had to install a massive set of packages in one rnu.
[06:01] <Kamion> I was having trouble reproducing it consistently without re-debootstrapping
[06:01] <infinity> s/rnu/run/
[06:01] <infinity> elmo may or may not have taken a snapshot of the archive last night when we were disussing the issue.  I'm hoping he did, if it's not magically fixed.
[06:01] <Kamion> well, we can always extract xorg -44 later at leisure
[06:02] <daniels> right.  scott's fault. :)
[06:02] <Kamion> and appropriate matching mesa
[06:02] <Kamion> I tweaked libglu1-mesa-dev's libgl-dev alternatives, which will probably have helped matters too
[06:02] <daniels> Kamion: i keep a source morgue of every xorg upload since hoary (except a couple of the weird-shit random uploads in the week I was at LinuxTag, since they disappeared before I got back and caught up), so we can rebuild at will.
[06:02] <Kamion> but it's all uncomfortably debugging-by-voodoo
[06:03] <Kamion> I've been going around trying to get stuff updated to the newer package names so that we can demote-to-universe/remove the old ones
[06:03] <Kamion> which should also help consistency of hoary->breezy upgrades
[06:04] <ajmitch> if there's any name changes that are affecting universe, notification would be good
[06:04] <ajmitch> as I'm not sure if we're needing to rebuild packages with new build-deps yet or not
[06:05] <daniels> Kamion: the hillarious part of all your mesa changes is that libgl1-xorg* will cearse to exist before breezy's out
[06:06] <daniels> replaced by ... libgl1-mesa*
[06:06] <infinity> Kamion : The only way to get upgrade consistency will be if sometihng directly depends on libglu1-mes (etc), since everything that depends on libgl/libglu depends on virtual packages.
[06:06] <Kamion> daniels: yeah, I know, but in the meantime I really want to deconfuse germinate
[06:06] <Kamion> it was doing shit like pulling in mesag3 because it was the primary alternative from libglu1-mesa or something like that
[06:07] <Kamion> and that makes it hard to demote the old packages from main, which in turn means people are more likely to upload new stuff (build-)depending on the old names
[06:08] <daniels> hm
[06:09] <daniels> it should be letting the dependency be satisfied by the alternative anyway
[06:09] <infinity> Yay, my dpkg segv is still there.
[06:09] <Kamion> yeah, it wasn't though, I think because it looked at libglu1-mesa before looking at anything that depended directly on libgl1-xorg
[06:10] <daniels> huh
[06:10] <daniels> can't we all just use portage or something?
[06:10] <Kamion> germinate's ordering-dependent in some cases; we have a couple of seed workarounds for it, but the right answer is to make primary alternatives consistent in main at least
[06:10] <infinity> Kamion : Your mucking with package relations did nothing to help dpkg stop littering chroots.
[06:10] <infinity> (glad it helped germinate though)
[06:10] <Kamion> ah well
[06:11] <Kamion> grr
[06:11] <Kamion> daniels: please make libgl1-xorg.shlibs mention libgl1-xorg not xlibmesa-gl kthxbye
[06:11] <daniels> Kamion: *cough*
[06:12] <infinity> Kamion : Has libgl1-mesa already been promoted to main?
[06:12] <Kamion> anyway, *my* primary alternative is to go to bed rather than poking at dependencies ...
[06:13] <infinity> Kamion : If so, it's more future proof for us to just change those shlibs to be "libgl1-mesa | libgl1"
[06:13] <infinity> (Since that's what we want in the end)
[06:13] <Kamion> infinity: no
[06:13] <infinity> Err, there is no libgl1-mesa.  It's mesag3... And it needs love.
[06:13] <infinity> But, yeah.  I should go hump mesa's leg for a bit or something.
[06:14] <Kamion> yeah, if that's going to take some complicated mesa/xorg interaction then I think I prefer the multi-step approach
[06:14] <Kamion> while taking the point about having to go back and do it all over again later, at least we only end up with one layer of old packages lying around in breezy if we don't get it done in time, rather than two
[06:15] <infinity> ;)
[06:15] <Kamion> and I really don't feel good about germinate sucking in stuff that's NBS from xorg :)
[06:15] <daniels> surely it should follow provides where the package is a pure virtual with only one provider
[06:15] <infinity> No arguments on that one.
[06:16] <Kamion> daniels: yes - such as?
[06:16] <daniels> Kamion: ... xlibmes-agl?
[06:16] <Kamion> xlibmesa-gl |   6.8.2-43 |        breezy | amd64, hppa, i386, ia64, powerpc, sparc
[06:16] <Kamion> not pure virtual
[06:16] <daniels> oh, argh
[06:17] <daniels> can we please cull xlibmesa* from the archive?
[06:17] <Kamion> that's what I'm trying to arrange
[06:17] <infinity> If you drop xlibmesa completely, then the "xlibmesa-gl | libgl1" dep becomes a pure virtual.
[06:17] <elmo> don't
[06:17] <Kamion> hmm
[06:17] <elmo> it's not showing up in rene
[06:17] <elmo> which means something's still claiming to build it
[06:17] <elmo> pls fix that first
[06:17] <infinity> elmo : Not yet built on amd64, I assume that's the only issue.
[06:17] <infinity> (the new source, that is)
[06:17] <elmo> no, that doesn't matter
[06:18] <elmo> rene looks at the source, which is always the latest
[06:18] <elmo> bah, don't make me wake up
[06:18] <Kamion>         o 6.8.2-43 [ia64, i386, sparc, amd64, powerpc] : libfs-dev, libfs6, libfs6-dbg, xfs, xlibmesa-dri, xlibmesa-dri-dbg, xlibmesa-gl, xlibmesa-gl-dbg, xlibmesa-gl-dev, xlibosmesa-dev, xlibosmesa4, xlibosmesa4-dbg
[06:18] <Kamion> (rene's partial NBS list) - hppa maybe?
[06:18] <daniels> daniels@ephemera:~/canonical/brainfreeze/xorg/monolith% grep xlibmesa-gl old/xorg_6.8.2-44_source.changes
[06:18] <daniels>      + xlibmesa-gl* -> libgl1-xorg, libgl1-xorg-dev, libgl1-xorg-dbg
[06:18] <daniels> (that's the changelog entry)
[06:19] <infinity> elmo : Did you snapshot the archive last night so we can reproduce that dpkg segv?  (now would be fine too, I can still reproduce it as of right now)
[06:19] <Kamion> it's not in xorg -44.dsc
[06:19] <elmo> xfree86
[06:19] <infinity> !
[06:19] <elmo> claims to build it
[06:19] <elmo> infinity: no, sorry, I didn't think of a cunning way to do it and forgot/got distracted by terranova
[06:19] <Kamion> heh
[06:19] <daniels> elmo: i don't see how this is problematic
[06:19] <infinity> And why do we still have xf86 source packages at all?
[06:20] <elmo> daniels: because if you remove stuff a source package claims to build the buildds think it needs to be built?
[06:20] <elmo> xfree86 may have sneaked back in when I spethialed the sync blacklist a while back
[06:20] <daniels> elmo: right.  so that's why we remove the source package that claims to build it.
[06:22] <elmo> daniels: sure - I was more objecting to the principle of forcibly removing stuff in rene's partial NBS list
[06:22] <daniels> elmo: yeah, fair enough
[06:22] <infinity> Objection duely noted.  xfree86 source removal would be nice. :0
[06:22] <daniels> if we could nuke xfree86, that would simplify a lot of things
[06:22] <Kamion> oh, argh, speaking of partial NBS
[06:22] <infinity> (probably would have been nice about a month ago...)
[06:22] <elmo>    libxft1 | 4.3.0.dfsg.1-6ubuntu25 | amd64, i386, ia64, powerpc
[06:22] <Kamion> tseng: please stop mcs building mono-assemblies-arch, I didn't spot that
[06:22] <daniels> there's a lot of shit that's atrophied since hoary that would still be claimed by xfree86
[06:22] <elmo> I take it we don't need that?
[06:22] <daniels> yeah
[06:22] <elmo> ok, removed, re-blacklisted
[06:23] <daniels> elmo: we don't need anything that xorg doesn't build today
[06:23] <ajmitch> Kamion: mcs source should be removed, it's all in the mono source package now
[06:23] <elmo> ------------------- Reason -------------------
[06:23] <elmo> [rene]  out damn spot, out
[06:23] <elmo> ;)
[06:23] <daniels> elmo: including libxp6, libxp-dev, libxaw8, libxaw8-dev, xmh, xdm (cough), xfs, etc
[06:23] <infinity> Man, Lady MacBeth was so mean to that dog.
[06:23] <daniels> elmo: heh
[06:24] <elmo> daniels: once xfree86 disappears, rene will do her thing and someone who's awake and with katie privs can kill the rest
[06:24] <daniels> elmo: awesome, cheers
[06:25] <Kamion> elmo: do I have to know anything special to remove mcs? just melanie in the obvious way?
[06:25] <Kamion> oh, sync blacklist, hmmmmmm
[06:25] <elmo> it just a file dude
[06:25] <elmo> it's like the least katie part
[06:26] <ajmitch> mcs source isn't in sid either, from what I can see
[06:26] <Kamion> good point
[06:26] <elmo> kamion: but yeah, melanie just works, you might want to prefix the removal with '[rene] ' to avoid silly fascism checks
[06:26] <Kamion> how do we keep track of stuff removed from Debian?
[06:26] <elmo> I have something that parses removals.txt
[06:27] <elmo> I wrote it as punishment for logging the removals in such an incredibly unparseable format
[06:27] <elmo> I haven't run it since UVF tho
[06:27] <elmo> as tracking removals when we're not syncing new stuff gets insane fast
[06:32] <daniels> i think lamont should write more katie tools
[06:32] <daniels> that would be awesome
[06:32] <Kamion> elmo: btw, did I ever ask you, how do you NEW stuff straight into universe the way you seem to do?
[06:32] <elmo> Kamion: yeah, and I think I dodged the question, it's a disgusting hack
[06:32] <elmo> kamion: basically, the problem is the override-source's-idea-of-componet stuff is an old-school warthogs-era hack,and only exists in jennifer
[06:32] <elmo> lisa doesn't know how to do it
[06:33] <elmo> so my straight to unvierse stuff, adds the overrides semi-by-hand, then moves the upload from new back into unchecked
[06:33] <elmo> [yes, I rock.  I'm here all week.  thank you.] 
[06:33] <Kamion> ah, right, I had wondered if it was something like that since I noticed lisa really didn't like the whole idea
[06:34] <Kamion> after trying the obvious-looking thing in lisa and then having to unfuck the overrides
[06:34] <elmo> c.f. 'new_universe' alias the katie user has
[06:34] <elmo> for the 'semi-byhand' bit
[06:34] <elmo> oh it's a script in ~/bin/ actually
[06:35] <Kamion> niiiice
[06:35] <elmo> :>
[06:35] <elmo> yeah, not proud
[06:36] <Kamion> I guess that has trouble with contrib/ and non-free/ stuff from Debian too
[06:36] <elmo> one day... I'll fix lisa
[06:36] <elmo> kamion: or anything that mentions universe or multiverse, yes
[06:37] <daniels> i swear elmo and lamont are one and the same person
[06:37] <daniels> because I was actually joking about lamont writing bits of katie
[06:37] <daniels> now I'm not so sure
[06:37] <elmo> dude, katie's obsolete for us
[06:38] <elmo> elegant solutions are WAB
[06:38] <Lathiat> wab?
[06:40] <raphaelpereira> hi
[06:40] <raphaelpereira> hello?
[06:40] <raphaelpereira> i found a bug
[06:41] <raphaelpereira> and have a patch
[06:41] <raphaelpereira> is this the right place?
[06:41] <Lathiat> raphaelpereira: What is it for?
[06:41] <infinity> bugzilla is probably the right place to document the bug/patch.
[06:41] <raphaelpereira> which is the addres???
[06:42] <raphaelpereira> it's simple
[06:42] <raphaelpereira> and corrects all problems (i hope) related to hibernation on errors of  "scheduling while atomic"
[06:42] <raphaelpereira> upon resume
[06:43] <Lathiat> http://bugzilla.ubuntu.com
[06:43] <raphaelpereira> ok
[06:43] <raphaelpereira> do you wanna know or i just go there and report?
[06:43] <Xyc0> I wanna know
[06:43] <jsgotangco> its best to bugzilla though
[06:44] <raphaelpereira> ok
[06:44] <raphaelpereira> Xyc0, simple
[06:44] <raphaelpereira> schedule while atomic problems probably is kernel bug
[06:44] <raphaelpereira> i'm no kernel hacker
[06:44] <Kamion> file the bug, then point him at it
[06:44] <raphaelpereira> so, i workaround it
[06:44] <raphaelpereira> ok
[06:44] <raphaelpereira> sorry
[06:44] <Kamion> no need to rehash it here
[06:45] <Xyc0> That works
[06:45] <Kamion> feel free to discuss pending issues with the patch here, though
[06:56] <daniels> ummmmmmmmmmmm
[06:56] <daniels> this is more special
[06:57] <daniels> the only explanation I can come up with is that I did find ./ -name \*amd64\* | xargs rm -f
[06:57] <daniels> 'cause debian/patches/600_amd64_support.diff was missing, so everything went into /usr/X11R6/lib64
[06:57] <Lathiat> umm
[06:57] <Lathiat> how the hell did you manage that
[06:57] <Amaranth> who needs amd64?
[06:57] <Lathiat> haha Amaranth 
[06:58] <Lathiat> you can get amd64 laptops for like $1100, maybe i should save up for a play
[06:58] <Amaranth> with 2 hours of battery life, yay
[06:58] <Lathiat> heh yeh
[07:00] <Xyc0> Lap tops can get more then 2 hours?!?
[07:00] <raphaelpereira> http://bugzilla.ubuntu.com/show_bug.cgi?id=11824
[07:00] <raphaelpereira> sorry for the long time
[07:00] <raphaelpereira> i didn't have an account
[07:01] <Xyc0> no worries
[07:01] <raphaelpereira> i have just noticed
[07:01] <raphaelpereira> my time is wrong
[07:02] <raphaelpereira> Xyc0, mine is last
[07:02] <Xyc0> rgr
[07:04] <Xyc0> raphaelpereira: Ill have to test this, bbl
[07:04] <raphaelpereira> bbl?
[07:05] <raphaelpereira> uau
[07:05] <raphaelpereira> does someone knows what is the meaning of bbl?
[07:05] <raphaelpereira> ok
[07:05] <raphaelpereira> be back later
[07:05] <Lathiat> be back later
[07:05] <raphaelpereira> i figured...
[07:05] <daniels> can we PLEASE try to keep this channel to discussion of Ubuntu development?
[07:06] <raphaelpereira> sorry mr daniels
[07:37] <jdub> Kamion: ping
[07:41] <infinity> Kamion : Have all the old xfree/xorg binaries been removed from the archive by now?
[07:41] <infinity> Kamion : Or are we still waiting on a cron.something to run?
[07:42] <infinity> Kamion : I'm cleaning up all the buildd chroots right now, and would like to do a mass give-back to see if anything's slightly happier with the new world order once the old junk is gone.
[07:47] <fabbione> infinity: what happened to the chroots?
[07:47] <daniels> dpkg keeps segfaulting
[07:47] <infinity> dpkg segfaults
[07:47] <fabbione> ah
[07:47] <fabbione> what version of dpkg?
[07:48] <infinity> Anything in the last month?
[07:48] <infinity> It's been going on for ages.
[07:48] <infinity> Try "apt-get install libqt3-mt-dev mesag-dev" in a clean buildd chroot.
[07:48] <infinity> (make sure it's clean first)
[07:49] <fabbione> create-chroot test
[07:49] <fabbione> argh.. EWINDOW
[07:51] <fabbione> Package mesag-dev is not available, but is referred to by another package.
[07:51] <fabbione> However the following packages replace it:
[07:51] <fabbione>   x11proto-gl-dev
[07:51] <fabbione> E: Package mesag-dev has no installation candidate
[07:51] <infinity> You need universe on.
[07:51] <fabbione> infinity: so what else can i test?
[07:51] <fabbione> ok
[07:52] <fabbione> infinity: nada.. latest mesa didn't build on sparc yet
[07:53] <fabbione> any other test?
[07:53] <infinity> That's the only "easily" repoducble testcase I have, though I know there are other killer package combinations too.
[07:53] <infinity> (I just would have to look through build logs to find them)
[07:53] <fabbione> ok....
[08:07] <Burgundavia> jdub, red hat is already working with MIT with that $100 laptop. Looks like your vision of gnome on that laptop might become a reality
[08:07] <Burgundavia> jdub, http://laptop.media.mit.edu/
[08:10] <sivang> morning all
[08:17] <Mithrandir> 'morning
[08:23] <Treenaks> hi
[08:26] <Mithrandir> daniels: you've _stolen_ my precious norwegian characters!
[08:26] <daniels> Mithrandir: no I haven't.
[08:26] <daniels> they work just fine.
[08:26] <Mithrandir> no, they don't
[08:27] <daniels> if you're having problems, follow my howto on -devel
[08:27] <daniels> but bear in mind that -46, which I just uploaded, was the first sensible version to build on amd64
[08:29] <daniels> if it still persists, I need a more sensible bug report
[08:30] <daniels> is your keyboard layout set right?  does it try to set it and bomb out?  does setxkbmap -print look right?  does setxkbmap -print | xkbcomp - :0 help?  does setxkbmap -model pc105 -layout no help?
[08:30] <daniels> but it's lunchtime
[08:37] <Mithrandir> yes, no, yes, yes, restarting X seems to have fixed it.
[08:37] <doko_> good morning
[08:38] <Treenaks> Mithrandir: s nw you cn d weird Norwegian stuff again? :)
[08:38] <Mithrandir> !
[08:38] <Treenaks> we need a single code point for \o/
[08:40] <Mithrandir> indeed, we do.
[08:41] <paolo> Do we, provided we have the interrobang
[08:42] <Treenaks> paolo: Unicode has a code point for the interrobang, so we have the interrobang.
[08:56] <Mithrandir> whom should I talk with to get my bugzilla ID changed?
[08:58] <robitaille> Mithrandir:  if you mean your email address, you can do it yourself
[08:58] <infinity> Mithrandir : Yeah, just set it yourself, there's a 4 day delay or some such, then it switches over.
[08:58] <infinity> Mithrandir : I did the same thing a couple months back.
[08:59] <Mithrandir> inded I can.
[08:59] <Mithrandir> indeed, even
[09:18] <tepsipak1i> kamion: I can't preseed locales, is it known not to work? even if I set the default locale to be None, it is set as "en", and the locales that I want aren't generated
[09:18] <tepsipak1i> this is with both hoary and latest breezy-netboot
[09:19] <tepsipakki> damn typo
[09:21] <\sh> Kamion: Kick my butt for what I done yesterday..it wasn't my purpose to upload this package without asking...
[09:22] <Mithrandir> hi pitti
[09:22] <pitti> Good mor*yawn*ing
[09:24] <paolo> 'morning :-)
[09:26] <\sh> morning pitti
[09:28] <mvo> morning 
[09:28] <ajmitch> hi pitti 
[09:29] <sivang> moring pitti 
[09:30] <sivang> s/moring/morning/
[09:30] <pitti> Hi ajmitch, hi sivang 
[09:43] <ajmitch> hi chmj 
[09:45] <Burgundavia> who is in charge of UbuntuExpress?
[09:46] <chmj> hi ajmitch 
[09:50] <highvoltage> hi chmj 
[09:50] <Mithrandir> ok, ooo2 working on amd64 with gtk looks.
[09:54] <mdz> pitti: my firefox has become crashy as well
[09:54] <mdz> Mithrandir: yay!
[09:54] <pitti> mdz: same for mozilla
[09:55] <pitti> mdz: and only on amd64, right?
[09:55] <Burgundavia> mdz, what are the specific plans for the hoary-->breezy updater?
[09:55] <Burgundavia> mdz, would it be possible for it to show the same screenshot tour as UbuntuExpress?
[09:55] <Mithrandir> mdz: there is an mozilla-ooo and ooo-evolution, I guess you are fine with me not providing those on amd64?
[09:56] <mdz> pitti: no, on i386
[09:56] <mdz> Burgundavia: screenshot tour?
[09:56] <Burgundavia> mdz, apparently UbuntuExpress will be able to show images while installing
[09:57] <jdub> Burgundavia: nicely spotted
[09:57] <pitti> mdz: hm, my i386 installation is not yet updated to the latest packages (libraries, not ffox itself)
[09:57] <Burgundavia> jdub, now we just need Ubuntu on them...
[09:58] <pitti> mdz: I'll upgrade, check if it becomes unstable and will try to single out the lib that caused that
[10:00] <Mithrandir> mdz: and -kde is not even started yet. :-/
[10:00] <Mithrandir> mdz: I'll finish up the gnome version before starting on ia32-libs-kde, I think
[10:01] <mdz> Burgundavia: I would be much happier if UE could not display screenshots, but could in fact install Ubuntu
[10:01] <Burgundavia> jdub, the doc team (myself and jsgotangco mostly) have been working on a new quickguide, ala the original spec. Rough draft at https://wiki.ubuntu.com/QuickTourDraft
[10:01] <mdz> Mithrandir: do mozilla and evolution require more ia32 libs?
[10:01] <jdub> YAY ORIGINAL SPEC!
[10:01] <sivang> jamesh: I get this when running ./autogen:
[10:02] <Mithrandir> mdz: I _think_ they require mozilla and evo as 32 bit programs.
[10:02] <paolo> Anybody uses emacs to develop on ubuntu-breezy? heh :-)
[10:03] <jsgotangco> i do docbook stuff on emacs
[10:03] <jsgotangco> psgml mode
[10:03] <jdub> Mithrandir: you think multiarch is doable/sensible for breezy+1
[10:04] <paolo> jsgotangco, do you know this error: Undefined color: "black" ?  I get this with every emacs I tried (emacs21, emacs-snapshot) - I think it's probably because of Xorg issues.
[10:04] <sivang> jamesh: http://paste.uni.cc/7567
[10:04] <jdub> Burgundavia: couple of comments
[10:04] <Burgundavia> jdub, shoot
[10:04] <jdub> Burgundavia: could do with a bit more copy where useful
[10:04] <Mithrandir> jdub: yes.
[10:05] <jdub> also, really got to zoom in on user-benefit features
[10:05] <jdub> about-me, for instance, isn't a user-interesting feature
[10:05] <jamesh> sivang: those are warnings you should ignore
[10:05] <Burgundavia> jdub, what do you see those as?
[10:05] <sivang> jamesh: ok, what is the source for them?
[10:05] <jdub> so *some* breezy goals are user-interesting
[10:05] <jamesh> sivang: they can only be fixed by updating the packages owning each of those .m4 files
[10:05] <jdub> such as built in LTSP
[10:05] <jdub> easier to use file manager
[10:05] <Mithrandir> jdub: it's going to require some concentrated effort, though
[10:06] <Burgundavia> jdub, file manager is somewhat mentioned, but could be tied together more
[10:06] <jamesh> sivang: automake checks to make sure that autoconf macro definitions are of the form AC_DEFUN([NAME] , ...) rather than AC_DEFUN(NAME, ...)
[10:06] <jdub> Mithrandir: elite
[10:06] <sivang> jamesh: ah, I see
[10:06] <jsgotangco> built in LTSP sounds good but quite advanced
[10:06] <jdub> Burgundavia: yeah, bundle those micro-feature grains into user-benefit blobs :-)
[10:06] <jamesh> sivang: since M4 is a macro expansion language, the AC_DEFUN(NAME, ...) form is dangerous if the macro gets defined multiple times
[10:06] <jdub> jsgotangco: it can be explained pretty simply
[10:07] <jdub> can just point to more information
[10:07] <paolo> Which lisp is going to be builtin?
[10:07] <Burgundavia> those who know what LTSP means will be excited
[10:07] <jamesh> sivang: "AC_DEFUN(foo, bar)AC_DEFUN(foo, baz)" would define two macros: foo -> bar and bar -> baz
[10:07] <Burgundavia> those who don't will ignore it
[10:07] <jsgotangco> rights its a quick tour anyways
[10:07] <jamesh> sivang: proper quoting would give just a single macro
[10:07] <Burgundavia> jdub, anything else? like the style? anything you would remove?
[10:07] <jdub> Burgundavia, jsgotangco: i'll pop over to -doc :)
[10:18] <karlheg> Idea; please implement (RFI): A package that sets the system up for source level debugging of packaged software.  Perhaps if each package had an automatically generated companion package that contains the debugging symbols that have been stripped from the normal binary; GDB supports this.  I think it would be better than having separate debugging versions of libraries.  A gdb wrapper script should be able to set up the environment so 
[10:18] <karlheg> that gdb picks up those symbols when it's run, right?  (I will look for a place in the UDU Wiki to place this idea)
[10:19] <siretart> morning
[10:19] <sivang> jamesh: ok, noted. pkg is here: http://muse.19inch.net/~sivan/lpint/lpint-bonnobo-0.0.tar.gz
[10:19] <siretart> fabbione: around?
[10:22] <JanC> karlheg : the udu wiki is merged with the normal wiki now AFAIK?
[10:24] <Mithrandir> mdz: would you be ok with putting ia32-libs-gtk 4 into hoary?  It fixes printing for people using ooo-amd64
[10:25] <mdz> Mithrandir: hoary-updates, you mean?
[10:25] <mdz> Mithrandir: it depends on what the changes are
[10:25] <Mithrandir> mdz: it wraps spadmin in the pango preload hack similar to what is done to ooo
[10:25] <Mithrandir> it's been in breezy since may, but you wanted it to have a little time there to see that it didn't break anything before putting it into -updates
[10:26] <sivang> jamesh: I've kept the way the patch is done, as evident from http://muse.19inch.net/~sivan/lpint/01_lpint_bonobo_src.patch
[10:26] <siretart> ah, so it's not my fault that my ooo/amd64 cannot print? If I may help testing, tell me where I can download the packages to test ;)
[10:26] <Mithrandir> siretart: from breezy
[10:27] <siretart> oh. ok
[10:27] <Mithrandir> http://archive.ubuntu.com/ubuntu/pool/main/i/ia32-libs-gtk/ia32-libs-gtk_4_amd64.deb
[10:34] <jamesh> sivang: cool.  I'll take a look at it.
[10:34] <jamesh> sivang: if you want to manage your changes, a bazaar branch might be easier
[10:35] <sivang> jamesh: I will crete one today :)
[10:35] <jdub> jbailey: still around?
[10:35] <jbailey> jdub: Yup
[10:35] <sivang> jamesh: it pretty cool using it in that ditributed format, and it's not as hard as it seemed first place (to operate baz, that is)
[10:35] <jbailey> 'sup?
[10:37] <seb128> mdz, Kamion: we are targetting a stable desktop this week to run a colony CD?
[10:37] <mdz> seb128: yes
[10:37] <seb128> k, here is the issue
[10:38] <pitti> Hi carlos 
[10:38] <seb128> cairo has changed its soname ... they were moving the API from some time with .so.1 on purpose, and the API is declared stable now so they bumped it to .so.2
[10:38] <carlos> morning
[10:39] <infinity> seb128 : Oh joy.
[10:39] <seb128> but GTK using it, around ~70 main packages (200 packages) rdepends on libcairo1
[10:39] <infinity> seb128 : API-compatible?... Cause a mass rebuild with no source changes isn't really tough.
[10:39] <seb128> yep, API compatible with the current version
[10:39] <pitti> seb128: can't we do that after the next colony?
[10:39] <mdz> infinity: is NM going to happen or no?
[10:39] <seb128> pitti: <seb128> mdz, Kamion: we are targetting a stable desktop this week to run a colony CD?
[10:40] <seb128> pitti: that's why I ask ...
[10:40] <mdz> it's been too long since the last milestone; we need one as soon as possible
[10:40] <pitti> yes, this was planned for the feature freeze
[10:40] <seb128> k
[10:40] <infinity> mdz : Are you okay with reverting the resolvconf attempt and going with bind9?... If so, then yes, I think I'm in a position to say "it'll be ready well before breezy"
[10:40] <seb128> I'll delay the cairo change for after the next colony
[10:40] <mdz> infinity: the relevant deadline is feature freeze, rather than breezy release
[10:40] <infinity> mdz : Dropping bind9 loses functionality (like bind views for VPNs), as well as making things not quite work optimally.
[10:40] <seb128> GTK 2.8 should be out this week too, I'll do both updates after colony
[10:41] <mdz> infinity: the issues with bind9 were resource consumption and security policy
[10:41] <infinity> mdz : Well, it won't be perfect for feature freeze, but I can get it "pretty good" in a day.
[10:41] <infinity> Resource consumption shouldn't be an issue, what's the security worry?
[10:41] <mdz> infinity: we can choke a bit on resource consumption; security needs to be addressed
[10:41] <mdz> infinity: no open ports in desktop
[10:41] <infinity> If we're only binding to localhost, it should be okay.
[10:41] <mdz> well, we weren't binding to localhost
[10:41] <infinity> Well, that's easily fixed, then.
[10:42] <Lathiat> mdz: it was but
[10:42] <mdz> I'm not convinced of that
[10:42] <Lathiat> another copy was running standard
[10:42] <mdz> but I hope so
[10:42] <Lathiat> from the init scfript
[10:42] <Lathiat> not sure how you can address that without breaking everyones bind9 installs by not starting it by default
[10:42] <infinity> mdz : Well, it's a tradeoff, cause allowing NM to depend on bind9 and rnu its own instance that only bindt o localhost means we need to ship a bind9 package that's DOA.
[10:43] <infinity> mdz : Then again, we shipped postfix DOA with the last release, so I suppose it's something we're used to.
[10:43] <mdz> infinity: I don't see why
[10:43] <mdz> I thought NM already supplied its own config to bind
[10:43] <infinity> mdz : Well, if I depend on bind9, it'll get installed, it'll by default run a cacheing nameserver on *:53 (and NM will also run its own instance on localhost:53)
[10:44] <mdz> infinity: that's currently the case, yes.  but that's not what we want
[10:44] <mdz> that's one of the things that needs to be fixed in order to integrate network manager
[10:44] <infinity> mdz : Right, hence why I said we'd need to deliver bind9 DOA.
[10:44] <infinity> mdz : Or ship two bind9 binary packages, one just for NM. (ick)
[10:44] <mdz> infinity: that is not the right solution
[10:44] <Mithrandir> split bind9 into bind9 and bind9-config where bind9-config is the set of current config files?
[10:44] <infinity> mdz : I'm flailing for a solution that isn't one of those two.
[10:45] <mdz> infinity: Mithrandir just mentioned one. another would be to suppress the default bind9 startup if NM is active
[10:45] <infinity> Mithrandir : That still delivers bind9 DOA, unless the admin knows to install bind9-config. (unless you're suggesting NM provides it as a metapackage, but those packages coulnt'c onflict, cause it's perfectly reasonable to run two bind9 instances)
[10:45] <Mithrandir> or bind9-daemon is just the daemon and bind9 is the config files + a dependency on bind9-daemon
[10:46] <infinity> mdz : There's no reason not to run bind9 /and/ NM (though it's an odd setup, sure)
[10:46] <Lathiat> mdz: so like an /etc/default/bind9 DONT_START_IF_NETWORKMANAGER_IS_INSTALLED or something?
[10:46] <mdz> the important use cases are: desktop user gets NM + caching nameserver, server user gets "apt-get install bind9"
[10:46] <infinity> Mithrandir : That's more workable, yes.
[10:46] <mdz> infinity: it'd be a silly deafult
[10:46] <mdz> default
[10:46] <jstr> hello people.  I would like to help Ubuntu by coding.  Is there anyone here that I can talk to get started?
[10:46] <mdz> jstr: yes
[10:47] <infinity> mdz : How about the suggestion to split the damon binary into a seperate package, as above?.. That's very little effort on the packaging front, and would seem to solve the problem.
[10:47] <mdz> infinity: it is one option
[10:47] <Mithrandir> it means moving conffiles, but that's doable, just ugly.
[10:47] <infinity> Mithrandir : No it doesn't, the conffiles would stay in bind9.
[10:48] <mdz> Mithrandir: why?  the conffiles can stay in bind9
[10:48] <infinity> Mithrandir : And just move the binary itself to bind9-bin.
[10:48] <infinity> Mithrandir : That's the path of least reistance so far.
[10:48] <Mithrandir> hm, true.
[10:48] <mdz> infinity: what about interaction between NM and ifupdown?  is that all sorted?
[10:49] <infinity> In that ifupdown has absolutely no clue about NM-managed interfaces?  No.
[10:49] <mdz> I think that the reverse is rather the problem
[10:49] <Lathiat> infinity: itd be nice if you could stop network-manager, and then start it and have it work again
[10:49] <Lathiat> or just have it not eat my interfaces if i play with them
[10:50] <jdub> infinity: so thom and i were talking about making ifupdown understand n-m
[10:50] <jstr> sweet.  Well I am a comp sci student in australia.  I would like to do some open source work before I graduate so I have a nice looking resume.  I like using C, and have done a unit on C in UNIX, but i have also done units in C++, java, and heeps of boring things like UML and project management.... I plan to give at least a year of commitment to a project.
[10:50] <infinity> jdub : Do you have logs of this?
[10:50] <mdz> jdub: I don't think it should
[10:50] <mjg59> Lathiat: Hm. It needs 0.1-2, which doesn't seem to have hit the archive yet
[10:50] <infinity> jdub : I hate reinventing wheels.
[10:50] <jdub> infinity: such as having static/dhcp/managed in interfaces, stuff like that
[10:50] <mdz> jdub: I think NM should stay the hell out of the way if ifupdown is managing an interface
[10:50] <jdub> infinity: i wish i did - i'll ping thom about it
[10:50] <jstr> what group should i join?
[10:50] <jdub> mdz: yeah, exactly, that's the idea
[10:50] <Lathiat> mjg59: usplash?
[10:51] <mdz> jdub: how does that equate to ifupdown understanding n-m?
[10:51] <Lathiat> mjg59: i think the buildds were a little hosed last check
[10:51] <jsgotangco> jstr: help the MOTU: https://wiki.ubuntu.com/MOTU
[10:51] <infinity> mdz : Well, the design goal of NM was to have it manage things independently of other system tools like ifupdown.  OTOH, if they can be made to not hate each other, I'm not opposed to the concept.
[10:51] <Lathiat> well ifup/down marks if it has brough tan interface up or down
[10:51] <jstr> thank you
[10:51] <Lathiat> n-m could look at that, and not touch the interface if its been brought up
[10:51] <mdz> infinity: to rephrase, NM is broken if it interferes with existing ifupdown configurations
[10:51] <mdz> infinity: that is a showstopper bug
[10:51] <infinity> mdz : What if I bring the iface up with ifupdown, but then I want to fiddle with it (say, associate with another WAP) with NM?
[10:52] <Lathiat> infinity: the real problem right now is that if you bring an interface up, it screws with it immediately, not if you click on something or whatever
[10:52] <mdz> infinity: for a given interface, you should either use NM xor ifupdown
[10:52] <doko> Mithrandir: could you use openoffice.org2_1.9.121-1ubuntu7 as a base for the amd64 packages?
[10:52] <jstr> jsgotangco: is there a channel for MOTU?
[10:52] <Lathiat> jstr: #ubuntu-motu
[10:53] <jsgotangco> jstr: #ubuntu-motu
[10:53] <Lathiat> jstr: http://wiki.ubuntu.com/MOTU
[10:53] <jstr> thank you
[10:53] <jdub> mdz: so the basic idea was configuring an interface as a managed interface
[10:53] <jdub> infinity: thom should hve logs at home
[10:53] <mdz> jstr: it's one of the first things on http://wiki.ubuntu.com/MOTU
[10:53] <mdz> jdub: what we need is the "by tomorrow" solution
[10:54] <mdz> which lets us get NM into desktop and start testing it
[10:54] <mdz> otherwise it's not going to make breezy
[10:54] <infinity> jdub : "iface eth0 managed", and then ifupdown doesn't own it, and "grep -v managed iface" are the interfaces NM should stay the hell away from?
[10:54] <Mithrandir> doko: I'm using whatever is in breezy
[10:54] <doko> Mithrandir: just freshly built.
[10:54] <mdz> the day of reckoning is upon us
[10:55] <infinity> jdub : That would require exactly 0 changes to ifupdown (since it'll just ignore those stanzas anyway), and could be hackable into NM..
[10:55] <jdub> infinity: yeah, at least that's one of the ideas i started with - the conversation went from there (thom is looking for logs now)
[10:55] <jdub> infinity: i like to dabble in simplicity 8)
[10:56] <infinity> jdub : But how do you cover the "I just plugges a new USB wifi interface in that I didn't have before" use case?... Does NM just toss it into /etc/network/interfaces, so users don't have to set it to managed on their own?
[10:56] <jdub> infinity: unconfigured in interfaces means it's up for grabs
[10:56] <infinity> Having to update a config file to declare something as "managed" sounds kinda dodgy, I guess.
[10:56] <mdz> infinity: interfaces which are configured in interfaces(5) should be left alone by NM.  others should be managed by NM.
[10:56] <mdz> it's backwards
[10:57] <jdub> yes
[10:57] <mdz> there's no need to add new syntax either
[10:57] <infinity> jdub : Ahh, then there's no need to declare something "managed" at all.
[10:57] <jdub> thom's found the logs
[10:57] <infinity> Gimme.
[10:57] <infinity> :)
[10:58] <seb128> hey jdub
[10:59] <jdub> yo seb128 
[10:59] <jdub> infinity: http://planetarytramp.net/nm-interfaces
[11:01] <jdub> oh, hey, i made more sense then than i do now
[11:03] <jdub> pitti: are you buying the "system bus restart means reboot time" stuff?
[11:03] <alberto> hi
[11:03] <alberto> someone in powerpc? ibook?
[11:03] <alberto> I installed ubuntu in a iBook 12" G3
[11:03] <pitti> jdub: we had this discussion on the utopia list
[11:03] <jdub> pitti: yeah, saw it
[11:03] <alberto> and sound in speakers is very low, when I play something it first sound a bit and after is ultra low
[11:03] <Lathiat> alberto: This is a development channel for discussion of ubuntu devleopment, please goto #ubuntu for user support
[11:04] <alberto> Lathiat: is a bug
[11:04] <pitti> jdub: the argument is not bad, I didn't finally made up my mind about this yet
[11:04] <alberto> alsaconf is not in alsa-utils
[11:04] <alberto> that is a bug
[11:04] <alberto> I'm sure
[11:04] <mdz> alberto: it isn't a bug, and this isn't the place to report bugs
[11:04] <mdz> alsaconf was intentionally removed
[11:04] <pitti> alberto: please open the mixer and push up the DRC range (or disable DRC)
[11:05] <pitti> jdub: we have reconnection patches for update-notifier and g-v-m, it is certainly possible for the battery applet, too
[11:05] <pitti> jdub: if we can make it work with reconnection, I'd prefer that
[11:05] <jdub> pitti: yeah
[11:05] <pitti> jdub: what do you think?
[11:05] <alberto> mdz: why was removed?
[11:06] <mdz> alberto: it is obsolete
[11:06] <jdub> pitti: i'd like to think we were not absolutely lame, but sometimes i wonder about the rh guys ;)
[11:06] <alberto> ok
[11:06] <mdz> alberto: you should never need to use alsaconf; if it isn't configured automatically out of the box, then that is a bug
[11:07] <alberto> mdz: I am debian user since years ago, and I used to do all manually
[11:07] <alberto> I thought that could be a bug, sorry
[11:08] <infinity> jdub : Okay, you guys were talking a level of complexity beyond what we were just talking about here.
[11:09] <infinity> jdub : And something that's not realistic for "can I have it done in a day? (or a few, if mdz cuts NM some slack)"
[11:10] <seb128> jdub, pitti: we should probably drop on the "restart dbus on update". I've talked with walters on #gnome-hacker yesterday. Upstream/Redhat/Suse are not going this way, and dbus is going to be used by a lot of stuff, that will require some good patching all over the place and probably create some bugs ...
[11:10] <jdub> infinity: well, if you ignore the mandatory settings stuff, it's exactly what we've just described
[11:10] <jdub> infinity: n-m to own what interfaces doesn't
[11:11] <jdub> infinity: (which, in effect, leaves interfaces as the mandatory settings layer for the time being)
[11:11] <infinity> jdub : Yeah, and the crazy "ifupdown should talk to NM via dbus" stuff. :)
[11:11] <pitti> alberto: does the DRC setting help?
[11:11] <jdub> oh, that was early in the conversation
[11:11] <jdub> much crack
[11:11] <alberto> pitti: for sure
[11:11] <alberto> I am happy XD
[11:11] <alberto> :D
[11:11] <infinity> jdub : Still, there was the valid point raised about "how the heck do I get a network when I boot in reocovery mode?"
[11:11] <jdub> yeah
[11:11] <nomed^> hi all .. just a question .. i sow that debian is workin on a script: xserver-xorg.init .. "http://necrotic.deadbeast.net/svn/xorg-x11/trunk/debian/changelog" is ubuntu planing something similar?
[11:11] <alberto> why is disabled drc channel by default?
[11:12] <infinity> jdub : If an interface can't be configured in /etc/n/i for NM to manage it, then you've got a catch-22 there.
[11:12] <infinity> jdub : No network until the GUI comes up for the normal use case means recovery is much more difficult for the clueless.
[11:12] <mdz> nomed^: no; we already solved this problem in a simpler way, but Petter wanted to do it differently
[11:12] <jdub> infinity: in that case, our first run having a slight negative impact on recovery mode is probably something we can handle
[11:12] <pitti> alberto: that's fixed in breezy btw
[11:13] <jdub> infinity: won't the NM daemon do something sensible before the GUI is up?
[11:13] <nomed^> mdz, could you give me a link or more infos about this .. ?
[11:14] <mdz> nomed^: for the live CD, it is done by casper, for thin clients, it is done by ltsp
[11:14] <infinity> jdub : Oh, yes, in runlevel 2 it will, but DBUS doesn't even run in runlevel 1.
[11:14] <nomed^> mdz, ok thanks
[11:14] <jdub> infinity: so i don't think we need to worry about recovery mode
[11:14] <infinity> jdub : So, we should get a network when DBUS kicks in in rc2.
[11:14] <mjg59> Lathiat: Hngk.
[11:15] <mjg59> Lathiat: Yes, usplash. Looks like it's the buildds
[11:15] <infinity> jdub : I dunno.  It makes it much harder to do user-to-user support, if you have to tell someone how to manually configure their network interface before they can "ifup eth0 ; wget some_random_file ; perform fix"
[11:15] <Lathiat> mjg59: indeed
[11:15] <infinity> jdub : I'm not sure if losing that is really worth the shininess of NM being shoved in prematurely.
[11:16] <mdz> infinity: "dhclient eth0" fills that use case nicely
[11:16] <infinity> Oh, fair enough.
[11:16] <jdub> infinity: it's not that hard, in the simple case, you should just be able to dhclient
[11:16] <Lathiat> perhaps in recovery dhcp could be attempted on all interfaces or something
[11:16] <jdub> infinity: and the non-simple case involves configuring interfaces ;)
[11:16] <infinity> Alright, objection withdrawn then.  We can go with the simplest "if it ain't in interface, NM owns it" path, then.
[11:17] <infinity> Lathiat : "recovery mode" isn't really a "mode" at all, it's just runlevel 1.
[11:17] <daniels> paolo: undefined colour: black means that X is missing its RGB database, which is actually sort of somewhat true for new installs ...
[11:17] <infinity> Lathiat : We don't do anything special in that mode, we just stop booting half way.
[11:17] <Lathiat> infinity: you could add a grub flag tho 
[11:17] <Lathiat> but true
[11:17] <infinity> Well, yes.
[11:17] <jdub> The following extra packages will be installed:
[11:17] <jdub>   libslang2-dev
[11:17] <jdub> The following packages will be REMOVED:
[11:17] <jdub>   aalib1-dev libxine-dev slang1-dev
[11:17] <jdub> The following NEW packages will be installed:
[11:17] <jdub>   libslang2-dev
[11:17] <infinity> We can parse /proc/cmdline and do something spiffy, but I'm not sure how worth it that is.
[11:18] <jdub> The following packages will be upgraded:
[11:18] <jdub>   libcaca-dev
[11:18] <paolo> daniels, indeed.  I replaced the 4 lines long rgb.txt that comes with the default install with the 700+ lines long xorg one.  Now Emacs start correctly.  Should I file a bug?
[11:18] <jdub> 
[11:18] <jdub> seb128: know about that ^ ?
[11:18] <infinity> "run ifup eth0" and "run dhclient eth0" are pretty much equivalent from a "I have no idea what either of those commands mean because I like mice" perspective.
[11:19] <jdub> infinity: figlet in base -> "WELCOME TO RECOVERY MODE, THIS IS YOUR SHELL" :)
[11:19] <jdub> having to use recovery mode is bad to start with
[11:19] <mjg59> Hm. No exciting DCC announcements?
[11:19] <alberto> thanks pitti and mdz 
[11:19] <jamesh> not cowsay?
[11:20] <jdub> mjg59: dude, the booth was EMPTY today
[11:20] <daniels> paolo: no, I already have it in hand
[11:20] <daniels> mjg59: HA HA HA
[11:20] <mdz> pitti: my firefox crash is at 0xb7e9304d in nsCOMPtr_base::begin_assignment ()
[11:20] <infinity> jdub : Agred, single user is not something we should ever have to dump anyone into.
[11:20] <paolo> daniels, ok great.  It is also missing the binary "showrgb".
[11:20] <daniels> paolo: yes
[11:20] <mjg59> jdub: No Userlinux either?
[11:21] <mjg59> "Jim Zemlin, executive director of the Free Standards Group, the organization behind the LSB, will be speaking at the DCCA's launch Tuesday at LinuxWorld."
[11:21] <seb128> jdub: what are you trying to install?
[11:21] <infinity> mdz : Alright, if we're agreed on the single user use case being irelevant, and that "not in interfaces means NM owns it", then I think we're good to go.
[11:21] <jdub> seb128: libcaca-dev
[11:21] <infinity> mdz : Assuming the bind9/bind9-bin split is acceptable for the other glaring issue.
[11:21] <mdz> infinity: yes
[11:21] <jdub> mjg59: saw bruce around
[11:21] <seb128> jdub: I'm not maintainer for that :p
[11:22] <jdub> seb128: cheeky :)
[11:22] <seb128> jdub: xine is the one broken here
[11:22] <jdub> yeah
[11:22] <jdub> should depend on slang2
[11:22] <infinity> mdz : Given that the current packages are in rather poor shape and poorly tested, I assume there's no argument with updating to a more recent CVS snapshot?  It's a bit less broken in general upstream, it seems.
[11:22] <seb128> jdub: I'll fix that
[11:23] <jdub> seb128: want me to turn it around for you?
[11:23] <seb128> feel free :)
[11:23] <jdub> dum-de-dum :-)
[11:24] <Simira> morning, jdub 
[11:24] <HiddenWolf> What's the deal with DCC anyhow? Looks like they're infighting even before launch, and everyone has a different idea about what it should/will be.
[11:24] <jdub> HiddenWolf: falling apart before they can even announce.
[11:24] <Lathiat> whats that the debian commercial thing?
[11:25] <HiddenWolf> jdub: how so?
[11:25] <jdub> HiddenWolf: sun wah and others bailing out
[11:26] <HiddenWolf> jdub: omg. I'm not sure what I should think of that.
[11:27] <jdub> how about, "oh, already?"
[11:27] <mjg59> jdub: Sun Wah bailing out?
[11:27] <Lathiat> sun wah?
[11:27] <mjg59> I knew VA had
[11:27] <Amaranth> not funny
[11:27] <jdub> mjg59: was written up in eweek
[11:27] <HiddenWolf> jdub: I'm doubting between "sucks to be debian" or just plain "sucks"
[11:27] <jdub> HiddenWolf: note that DCCA is *not* debian
[11:28] <Amaranth> xutils and xbase-clients are showing as obsolete in synaptic but lots of things use them :P
[11:28] <mjg59> jdub: Eweek wrote about VA - Sun Wah still seemed positive
[11:28] <HiddenWolf> jdub: yeah, I know. But they'll need some focus in order to get a grip, and this could have been just the thing.
[11:28] <daniels> Amaranth: that'd be 'cause they don't exist in the archive in any version at the moment.  wait 'till the next pulse kicks.
[11:28] <jdub> $ dpkg -L libxine1c2 | grep so$ | while read i; do ldd $i; done | grep slang
[11:28] <jdub>         libslang.so.1 => /lib/libslang.so.1 (0xb7ef9000)
[11:28] <jdub>         libslang.so.2 => /lib/libslang.so.2 (0xb7cd1000)
[11:28] <Amaranth> oh!
[11:28] <jdub>         libslang.so.1 => /lib/libslang.so.1 (0xb7eb2000)
[11:28] <Amaranth> ouch
[11:28] <jdub> ^ ha ha
[11:29] <mjg59> HiddenWolf: If it had actually involved Debian in any way, it's possible that it would have led to good things
[11:29] <Treenaks> jdub: omg?!
[11:29] <Amaranth> xine links against both at once?
[11:29] <jdub> er, even worse
[11:30] <jdub> /usr/lib/xine/plugins/1.0.1/xineplug_vo_out_aa.so links against both at once
[11:30] <HiddenWolf> mjg59: well, yeah, perhaps. if you give debian a say tho, you have to reach a concencus among thousands of devesl rather than a few CEO/CTO's - it'd be braindead rather than falling apart
[11:31] <mjg59> HiddenWolf: Debian developers are never going to do anything to benefit a set of companies that aren't working with Debian
[11:31] <Lathiat> it'l make good flamewords on ddl tho
[11:31] <paolo> daniels, you do probably know it too, but I wanted to make sure: the xbase-clients package do install more or less nothing.
[11:31] <HiddenWolf> mjg59: and there you have a reason for going outside of debian. :)
[11:32] <mjg59> HiddenWolf: Right. Which probably means you shouldn't use their trademark...
[11:32] <Amaranth> paolo: that's a feature, not a bug
[11:32] <paolo> Amaranth, cool.  Do you know where to find everything missing there? (e.g. xfontsel)
[11:33] <Amaranth> they've gone to a better place
[11:33] <Amaranth> hrm, daniels is rubbing off on me
[11:33] <HiddenWolf> mjg59: depends on how you do things. Perhaps the plan was to build a corporate debian deriviate.
[11:33] <HiddenWolf> Amaranth: do we want to know? ;)
[11:33] <mjg59> HiddenWolf: Which would still be a violation of the trademark
[11:33] <jdub> HiddenWolf: which shouldn't use the trademark...
[11:34] <HiddenWolf> mjg59, jdub, I never said they where smart, did I?
[11:34] <Amaranth> hey, i thought ubuntu was the corporate debian derivitive ;)
[11:34] <Amaranth> corporate == workstation
[11:34] <HiddenWolf> Amaranth: ubuntu has debian and others wetting their pants, really.
[11:34] <mjg59> Not so much Debian
[11:34] <daniels> paolo: this is fixed in -46
[11:35] <daniels> paolo: which is probably waiting in NEW
[11:35] <mjg59> More the people whose revenue streams depend on people buying their distribution
[11:35] <Amaranth> daniels: oh, xbase-clients has stuff in it again in -46?
[11:35] <jdub> Amaranth: ubuntu is not a desktop/workstation OS
[11:35] <highvoltage> HiddenWolf: Ubuntu relies on Debian.
[11:35] <daniels> Amaranth: 'stuff in it' -> 'dependencies'
[11:35] <HiddenWolf> mjg59: no, debian is just grinding its teeth.
[11:35] <Amaranth> ah
[11:35] <highvoltage> HiddenWolf: if Debian has to wet its pants, then Ubuntu has to too.
[11:35] <paolo> daniels, great - thank you for the informations.
[11:36] <mjg59> HiddenWolf: Uh. No.
[11:36] <jstr> mdz:  Ive signed up for doing some work with MOTU.  Im just wondering if there is also some coding work that i can get involved with?
[11:37] <HiddenWolf> highvoltage: I doubt it. If ubuntu gets things done, and debian does not, devels might choose to upload here rather than at debian. The projects rely on eachother, but if debian messes up, ubuntu might just be the bigger brother eventually.
[11:37] <sivang> Amaranth: it will be excellent as a server too ;-)
[11:38] <ajmitch> HiddenWolf: and we try & get things back into debian that we put into ubuntu
[11:38] <Amaranth> HiddenWolf: the way we do things in universe would never scale to the level of developers debian has
[11:39] <jdub> HiddenWolf: long term, perhaps, but short/medium term, not really
[11:39] <HiddenWolf> Amaranth: I know, but organisations and methods change. as do goals. my piont was: Ubuntu is a wake-up call for debian, and they have to do it right, or they'll lose users first, then developers. 
[11:39] <HiddenWolf> jdub: notice the eventually
[11:40] <daniels> i don't think that ubuntu will ever function as a centre of more generalised development in such a way that it surpasses debian
[11:40] <HiddenWolf> Amaranth: judging from that is going on now in debian, and this DCC thingy, Debian is not awake yet.
[11:40] <paolo> daniels, is there a place where I can find this kind of informations by myself instead of begging here?
[11:40] <daniels> we do two sorts of things: big, big things (gnome, xorg, nm, whatever) that get back, and small cool usability tweaks
[11:40] <daniels> paolo: the xorg changelogs on breezy-changes
[11:41] <daniels> HiddenWolf: i don't think DCC is any serious challenge.  it's not like any of those vendors (progeny, va, sun wah, linspire, xandros), have ever made any constructive effort to engage with debian anyway.
[11:42] <HiddenWolf> daniels: let us hope we don't have to, but let's face it, ubuntu gets stuff done, debian, dcc or what they'll think of next, probably won't. That is hurting debian and it's reputation.
[11:42] <Lathiat> wtf is sun wah
[11:42] <Lathiat> ive never heard of it
[11:42] <daniels> HiddenWolf: i think Debian does a lot more than you give it credit for.
[11:42] <jdub> Lathiat: chinese commercialised debian
[11:42] <Lathiat> jdub: ah
[11:42] <Amaranth> HiddenWolf: Standing on the shoulders of giants.
[11:43] <jdub> Amaranth: don't be rude
[11:43] <Amaranth> ?
[11:43] <jdub> HiddenWolf: debian gets our packages done... please don't take that for granted
[11:43] <daniels> HiddenWolf: try scaling motu to 10,000 packages.  say what you like about debian, but it has a massive field of maintainer who generally care deeply about their packages, which we just cannot replicate unless we scale to the same degree.
[11:43] <Amaranth> jdub: How was that rude?
[11:44] <jdub> Amaranth: it was not originally said as a positive statement :)
[11:44] <Lathiat> i was wondering that
[11:44] <HiddenWolf> daniels: I know they're great, and I hope they stay great. I just don't see them moving forward. but let's drop it. only time can tell any way.
[11:44] <Amaranth> jdub: It just means what you said.
[11:44] <jdub> Amaranth: might want to check the history of it :)
[11:44] <Amaranth> jdub: Ubuntu gets the cool things done because of what debian gives us.
[11:45] <mjg59> Amaranth: The "Standing on the shoulders of giants" thing referred to a short person
[11:46] <\sh> yes...a new ejabberd version
[11:46] <mdz> jstr: it's too late to develop new features for the 5.10 release, but you can start working on something for 6.04
[11:47] <jstr> thats fine.  is there a group that needs members?
[11:48] <Mithrandir> doko: [Java framework] sunjavaplugin.so could not load Java runtime library:
[11:48] <Mithrandir> file:///usr/lib/libgcj.so.6.
[11:48] <Lathiat> mjg59: a giant can stand on another giant
[11:49] <Lathiat> heh
[11:49] <Lathiat> i think i took it the way amaranth did
[11:50] <Lathiat> jdub: mm friday, avahi 0.1, :)
[11:50] <Lathiat> altho ross thinks its not a 0.1 because it has documentation and man pages
[11:51] <jdub> Lathiat: yay
[11:55] <pitti> /usr/bin/ld: /tmp/ccVIzjHe.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
[11:55] <pitti> /tmp/ccVIzjHe.o: could not read symbols: Bad value
[11:55] <pitti> meh???
[11:55] <Lathiat> nice
[11:57] <daniels> i like `a local symbol'
[11:57] <pitti> anyway,  -fPIC helped
[11:57] <Lathiat> heh
[11:58] <tseng> Kamion: better to just drop mcs completely.
[11:58] <tseng> Kamion: i will mail elmo.
[12:00] <doko> Mithrandir: hmm, can you try lib32gcj6 ?
[12:00] <Mithrandir> doko: it's installed
[12:04] <Mithrandir> doko: apart from that, ooo2-amd64 is there
[12:04] <Mithrandir> (missing -kde, still)
[12:08] <doko> yep, sunjavaplugin.so wants that ... don't know yet how to fix that. maybe edit sunjavaplugin.so and point it to the correct location?
[12:09] <jdub> seb128: http://people.ubuntu.com/~jdub/xine-lib.diff
[12:09] <Mithrandir> I would seriously want not to run sed on random .so-s :-P
[12:09] <doko> s,/lib/libgcj.so.6,/lib32/libj.so.6, 
[12:10] <doko> well, the applications should work, as long as you don't touch the java things ...
[12:13] <doko> Mithrandir: and if you go this way, libofficebean.so is the other one to edit ...
[12:13] <Kamion> tseng: no need, I already removed it
[12:13] <Kamion> jdub: pong
[12:13] <Kamion> infinity: sorry, I crashed, I'll have a look now
[12:14] <daniels> gdb Kamion core
[12:14] <daniels> (gdb) bt
[12:14] <jdub> Kamion: hey, um, really sorry to lump you with this,
[12:14] <jdub> Kamion: but we have a late goal we need to integrate for breezy
[12:15] <Mithrandir> doko: I've nuked the openoffice2-officebean
[12:15] <jdub> Kamion: think you may be able to manage this one quickly
[12:15] <jdub> Kamion: reference document here -> http://forums.gentoo.org/viewtopic-t-365647.html
[12:15] <Mithrandir> doko: problem is ooo2-base is mostly unusable without the java stuff.
[12:15] <jdub> Kamion: need it to work out of the box on ppc
[12:16] <Lathiat> jdub: haha thats interesting
[12:16] <Kamion> jdub: not a hope. I cannot take extra goals right now, I'm sorry
[12:16] <doko> Mithrandir: yes, that's known. although it's ugly, I chan check, if the hex-editing would help. The OOo2 build expects a JAVA_HOME, I cannot change that easily
[12:17] <Kamion> I have two days to deal with everything I have to do for feature freeze, and three days to organise a wedding
[12:17] <jdub> Kamion: *love* :-)
[12:17] <Mithrandir> jdub: that's utter crack.
[12:17] <Kamion> and also, that's ... what Mithrandir said. :-)
[12:17] <Kamion> I hadn't even looked at the URL before refusing :)
[12:18] <Kamion> wow, that's totally insane
[12:18] <Mithrandir> it's _bad_ and utter crack. :-)
[12:18] <jdub> :-)
[12:18] <daniels> jdub: OH MY GOD, DUDE
[12:18] <jdub> thought you'd enjoy that one :)
[12:18] <Kamion> I'm really impressed that shit works at all
[12:18] <Mithrandir> jdub: you need to lower your dose of bad drugs.
[12:19] <Kamion> not impressed enough to actually use it, but ... ;)
[12:19] <jdub> OUT OF THE BOX! :)
[12:19] <daniels> can we kill xlibs-dev before feature freeze?
[12:20] <Mithrandir> doko: I would rather ship an ooo2 without -base on amd64, really.
[12:21] <doko> jdub: xine-lib 1.0.1 has issues with GCC-4.0 ... there are a new 1.0.2 and a 1.1 upstream
[12:21] <jdub> doko: boh!
[12:21] <Kamion> infinity: looks like elmo removed all that stuff though
[12:21] <doko> Mithrandir: it's not just -base, you find the java stuff in other places as well. i.e. most wizards, docbook-save in oowriter
[12:22] <jdub> seb128_: oops, wrong url anyway: http://people.ubuntu.com/~jdub/random/xine-lib.diff
[12:23] <Mithrandir> doko: ew
[12:24] <Lathiat> doko: i thought it all worked with free java stuff now? (or is it a stuff in main issue?)
[12:24] <tseng> Kamion: ok.
[12:24] <doko> Lathiat: it does
[12:25] <seb128_> jdub: thanks :)
[12:25] <Mithrandir> doko: can you provide me with something that ooo will find when looking for JREs?
[12:25] <jdub> seb128_: you approve?
[12:25] <jdub> seb128_: if that's okay, i'll try upping to 1.0.2
[12:26] <doko> Mithrandir: ?
[12:27] <Mithrandir> doko: I refuse to sed random shared objects to mangle paths, can't it have a search path or something?
[12:29] <seb128_> jdub: do you need to Build-Depends on libslang2-dev ?
[12:29] <seb128_> jdub: no you don't, libaa1-dev Depends on it
[12:30] <crispin> daniels: where should the /etc/X11/X symlink point ? Mine is currently a broken link to /usr/bin/X11/Xorg
[12:30] <Gandalfar> can anyone point me to more documentation about 'casper'?
[12:31] <Kamion> seb128: indeed - much of the point of the aalib transition was to remove explicit slang dependencies
[12:31] <jdub> seb128: ok, ta
[12:31] <Kamion> unless you're actually using slang directly of course
[12:31] <jdub> nah, that was my add
[12:31] <jdub> is it ok to build-conflict with slang1-dev tho?
[12:32] <jdub> otherwise it can (and did) build against both
[12:32] <Kamion> pretty unnecessary if you build-dep on libaa1-dev
[12:32] <Kamion> given that there's never been a version of libaa1-dev (as opposed to aalib1-dev) that depends on slang1
[12:32] <Kamion> but I guess it's ok
[12:32] <doko> Mithrandir: not before feature freeze ...
[12:32] <daniels> crispin: /usr/bin/X11/Xorg should point to /usr/X11R6/bin/Xorg
[12:32] <jdub> Kamion: well, that's changed in this patch too, so i may as well not
[12:33] <Mithrandir> doko: ok, any other good ideas?
[12:33] <Lathiat> daniels: yay dbus patch works
[12:33] <Kamion> daniels: oh! Xorg is a symlink to ../X11R6/bin/Xorg
[12:34] <Kamion> daniels: can't do that, it's going to have to be an absolute symlink, considering that /usr/bin/X11 -> .
[12:34] <Kamion> ... or not, it seems to work anyway, hmm
[12:34] <doko> Mithrandir: please can you check out, if the java stuff actually works with the hack, I don't want to waste time adding a search path, and then it doesn't work anyway ...
[12:34] <seb128> daniels: it points to /usr/bin/X11/Xorg too here
[12:34] <daniels> yes
[12:35] <daniels> /usr/bin/X11 -> /usr/bin, /usr/bin/Xorg -> /usr/X11R6/bin/Xorg
[12:35] <seb128> and there is no /usr/bin/X11/Xorg
[12:35] <Kamion> evidently the kernel is cleverer than I thought
[12:35] <mvo> Kamion: I need approval for a update-manager upload (bugfix only)
[12:35] <Kamion> mvo: what's in it?
[12:36] <mvo> Kamion: more carefull mirror preserve and updates so that breezy source lines are created by default
[12:36] <daniels> seb128: there's no /usr/bin/X11/anything
[12:36] <mvo> hardly any code changes (~5 lines)
[12:37] <crispin> daniels: thanks, that fixed it, although I notice now non-root can run X, is that intentional ?
[12:37] <mvo> Kamion: I can do you a debdiff if you want
[12:37] <Mithrandir> doko: segfault; the strings aren't the same length.
[12:38] <doko> s,/lib/libgcj.so.6,/lib32/libj.so.6, 
[12:38] <doko> they are.
[12:38] <Kamion> mvo: that's fine
[12:39] <daniels> crispin: 'can' or 'can't'?
[12:40] <seb128> daniels: after a purge/reinstall /etc/X11/X point to /usr/bin/X11/Xorg here ...
[12:41] <crispin> daniels: 'can'
[12:41] <daniels> seb128: yes.  that's intentional.
[12:41] <mvo> Kamion: thanks
[12:41] <HiddenWolf>   Guys, why isn't there a pointer to the national ubuntu channels in the topic of #ubuntu?
[12:42] <jdub> because there are buttloads of them ;)
[12:42] <seb128> daniels: it's intentional to point to something not here?
[12:42] <tseng> HiddenWolf: you could make/find an appropriate wiki page to link?
[12:43] <jdub> doko: so, updating to 1.0.2 is beyond my meagre skills :)
[12:43] <daniels> seb128: if x-common isn't installed already, install it
[12:43] <daniels> seb128: if it is, then something went badly wrong
[12:43] <seb128> daniels: it's installed
[12:43] <HiddenWolf> tseng, I might
[12:43] <seb128> ii  x-common       1.05           common files for X implementations
[12:43] <daniels> seb128: 'then something went badly wrong'
[12:43] <seb128> grumpf, k
[12:43] <daniels> seb128: /usr/bin/X11 should point to /usr/bin
[12:44] <Kamion> daniels: there's a batch of xorg uninstallables on http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html still; have you looked into them yet, or shall I?
[12:44] <seb128> daniels: 
[12:44] <seb128> $ ll /usr/bin | grep X11
[12:44] <seb128> lrwxrwxrwx  1 root   root         14 2005-08-06 13:56 X -> ../X11R6/bin/X
[12:44] <seb128> drwxr-xr-x  2 root   root       4096 2005-07-27 20:23 X11
[12:44] <seb128> lrwxrwxrwx  1 root   root         17 2005-08-06 13:56 Xorg -> ../X11R6/bin/Xorg
[12:45] <daniels> Kamion: let me get some sugar to prop myself up and sort it out, 'k
[12:45] <jdub> (the bed in this hotel is *extremely* comfortable)
[12:45] <john6000> can you make a update which changes grub? (if its not too hard)
[12:45] <john6000> :-)
[12:45] <doko> jdub: yep, maybe that can be done after feature freeze as a bug fix ...
[12:45] <john6000> ok
[12:45] <john6000> ty
[12:45] <hmrocha> hi
[12:46] <daniels> oh
[12:46] <hmrocha> breezy has some problems with keyboard mappings
[12:46] <hmrocha> after the upgrade, i've some characters
[12:46] <hmrocha> i'm using a pt layout
[12:46] <daniels> Kamion: i suspect that xb-c and xutils are uninstallable because they're still in NEW, maybe? x-w-s-c depends on them
[12:46] <hmrocha> and i can type braces or brackets for example
[12:46] <daniels> Kamion: failing that, I suppose more complete output would be nice
[12:47] <ogra> jdub, try not to snore to loud into the channel please :)
[12:47] <chz> hello
[12:47] <Mithrandir> doko: hm, sed-ing seemed to work
[12:48] <chz> never knew bout this channel, got referred by hmrocha from #ubuntu...having issues with breezy upgrade and understand that X is still very buggy....true..?
[12:48] <Kamion> daniels: sorry, nothing in NEW
[12:48] <Kamion> chz: this isn't a help channel, I'm afraid
[12:49] <chz> Kamion: o...ok
[12:49] <jordi> does anyone know if there's some effort from the Ubuntu folks to fix all the bugs in VEra and maybe get them release a new version?
[12:49] <Kamion> daniels: xbase-clients Depends: xprop, xutils Depends: sessreg
[12:50] <Kamion> daniels: xprop's in universe, I'll fix that now
[12:50] <Kamion> sessreg is nowhere
[12:50] <doko> Mithrandir: ok, let's put this on a list, however that won't make it for feature freeze
[12:50] <daniels> Kamion: thanks.  i'm working on sessreg now, just got to sort out a couple of fun political issues.
[12:50] <Mithrandir> doko: ok, I'll just upload ooo-amd64 for now
[12:50] <chz> Kamion: curious..what is this channel for ?
[12:50] <Kamion> daniels: is it today/tomorrow kind of material
[12:50] <Kamion> chz: development
[12:51] <Kamion> s/material/material?/
[12:51] <doko> daniels: if debconf priority is set to low, I'm ask for the xserver settings three times on an upgrade
[12:51] <daniels> Kamion: i set it as a 'if you guys can't come up with anything compelling within the next couple of hours, I'm going to do it anyway'
[12:51] <Kamion> chz: i.e. coordination among developers, discussion of bug-fixes and code for new features, etc.
[12:51] <Kamion> daniels: cool
[12:51] <daniels> doko: lies.  lies and deceit.
[12:52] <daniels> Kamion: any compelling objections, of course
[12:52] <Kamion> doko: s/low/low or medium/
[12:52] <daniels> and which settings?
[12:52] <chz> Kamion: towards Ubuntu distro...or applications?
[12:52] <daniels> i want to know which versions you're upgrading from and to
[12:52] <daniels> and which templates are getting asked
[12:52] <Kamion> chz: mostly distro, but whatever's necessary
[12:52] <hmrocha> is it easy to fix the keyboard issues?
[12:52] <Kamion> daniels: for me it happens on every single upgrade; e.g. both -44 to -45 and -45 to -46
[12:53] <hmrocha> maybe there is some misconfiguration in some keyboard package
[12:53] <Kamion> I get the PCI bus id question at least, afraid I can't remember the exact list
[12:53] <doko> Kamion: low
[12:53] <chz> Kamion: interesting...thanks. i noticed the topic and am interested in helping with development. i will goto #ubuntu-motu as i see you are all busy...thank you anyway... =)
[12:54] <daniels> Kamion: if you can trigger it again and find the exact questions, that would be good
[12:54] <daniels> Kamion: because I cannot reproduce it here
[12:54] <daniels> hmrocha: as kamion says, this is not a support channel
[12:55] <Mithrandir> doko: ok, I'll look at -kde then upload ooo2 in the current state.  It's mostly usable
[12:55] <ajmitch> daniels: I see the questions about pci id, & asking if I want to use kernel framebuffer
[12:55] <hmrocha> daniels, i'm trying to work on a development issue here
[12:55] <daniels> ajmitch: thanks
[12:55] <hmrocha> daniels, since hoary was working
[12:56] <daniels> hmrocha: it's not a development issue, it's a user support issue that happens to be with the development *tree*.  the two ideas are fundamentally different.
[12:56] <doko> daniels: /Select the desired X server driver/Enter an identifier for your video card/Please enter the video card's bus identifier/RAM size of graphics card/Use Frambuffer?/
[12:56] <Kamion> daniels: hmm, just a thought though, you might try in LANG=de_DE.UTF-8
[12:56] <daniels> doko: thankyou
[12:57] <daniels> i suspect they need some auto_answer akshun
[12:57] <Kamion> hmrocha: daniels posted recently to ubuntu-devel@lists explaining certain things you needed to install
[12:57] <daniels> did I mention that I hate the steaming pile of crap that we inherited in terms of xserver-xorg debconfiscation? and the fact that we made it even worse ...
[12:57] <daniels> Kamion: in german?
[12:58] <Kamion> that was what I happened to be in when it just happened to me, and I'm guessing it's doko's locale, that's all
[12:58] <Kamion> daniels: was one of the metapackages supposed to depend on xkeyboard-config?
[12:58] <Mithrandir> Kamion: well, I've seen it once in a while in nb_NO.UTF8, fwiw
[12:59] <janimo> daniels, I got asked 3 times as well using default locale
[12:59] <daniels> Kamion: x-w-s-c depends on it, xserver-xorg recommends it, and it should also be in the desktop seed
[01:01] <Kamion> daniels: yeah, was wondering if x-w-s-c was low-level enough; that functionality used to be in xlibs-data or something, didn't it?
[01:01] <daniels> Kamion: xlibs, yeah
[01:01] <Kamion> could xlibs depend on it for the upgrade?
[01:01] <ogra> somehow xinit is missing here in my test installs.... is that intentional ?
[01:02] <daniels> Kamion: the reason xlibs didn't eepend on it is because xk-c was pre-depending on xlibs for a while
[01:02] <ogra> it seems not to get pulled in by x-w-s-c
[01:02] <daniels> ogra: no, and it will be fixed when a cd build contains xbase-clients -46
[01:02] <ogra> or any of its deps
[01:02] <Kamion> ogra: should be fixed in about fifteen minutes
[01:02] <ogra> ah, great
[01:02] <Kamion> on the archive, anyway
[01:03] <Kamion> I'll wait for a CD rebuild until we have sessreg, then I can do the whole lot at once
[01:03] <daniels> yeah
[01:04] <doko> Kamion, daniels: I've only LANGUAGE=de_DE:de:en_GB:en , no LANG, no LC_*
[01:04] <Kamion> $ sudo -u katie ./alicia.new slang1a-utf8 optional
[01:04] <Kamion> I: Will change priority from required to optional
[01:04] <Kamion> hooray
[01:04] <ogra> pitti, main inclusion reports are only done for source packages, right ?
[01:05] <pitti> ogra: yes; if not all debs are requested for main, this should be mentioned in the report
[01:05] <ogra> sigh....
[01:09] <Kamion> jdub: cool, if I'm reading this right, that xine-lib upload should be enough to chuck slang1 out of main entirely
[01:09] <daniels> right, so xbase-clients and xutils are now entirely installable here
[01:09] <Kamion> daniels: the xserver-xorg/amd64 one seems to be depending on -driver-atimisc when it isn't built
[01:10] <Kamion> oh, -ati provides it
[01:10] <Kamion> I'll reboot into an amd64 system and test
[01:12] <daniels> you're right that it probably shouldn't dep -atimisc though, just -ati
[01:13] <doko> seb128: gnome-menus has a python SyntaxWarning
[01:13] <seb128> doko: I've noticed thankis
[01:15] <jdub> Kamion: YAY!
[01:17] <madduck> anyone seen Keybuk?
[01:17] <doko> Mithrandir: 12893 and 13196 are still present with the new ia32-libs
[01:18] <daniels> Kamion: Uploading via ftp sessreg_0.99.0-1_source.changes: done.
[01:18] <daniels> Successfully uploaded packages.
[01:18] <daniels> Not running dinstall.
[01:18] <jdub> pitti: yay libnotify!
[01:19] <pitti> jdub: ;-) just uploaded g-v-m that actually uses it now
[01:19] <pitti> mvo wants to use it too
[01:19] <Mithrandir> doko: which version of the fglrx driver?
[01:19] <Kamion> daniels: hooray
[01:19] <pitti> (or, I made him want to :-) )
[01:20] <doko> Mithrandir: 6.8.0-8.14.14-0ubuntu3
[01:22] <jdub> pitti: yeah, reacting to upload :)
[01:23] <daniels> Kamion: (now watch it get rejected because I'm a complete meathead and screwed something up)
[01:25] <Nafallo> daniels: xserver-xorg wants xserver-xorg-driver-v4l that is not installable on amd64 (-46).
[01:25] <daniels> Nafallo: that's because it's waiting in binary NEW.  either that or I'm a meathead and screwed something up.
[01:26] <janimo> when writing maininclusion wiki pages does every source package need a separate page or can they be put together if they are part of a larger meta?
[01:26] <daniels> i'll take 'i'm a meathead and screwed something up' for $20, dennis
[01:26] <janimo> I am thinking of xfce - same packager, same security record, same upstream
[01:26] <Nafallo> daniels: hehe, oki. great job anyway! :-)
[01:26] <janimo> I see it's done that way with koffice
[01:26] <Kamion> daniels: source looked fine to me anyway, processed
[01:26] <daniels> janimo: koffice is a single source package
[01:27] <Kamion> daniels: you can't end up with just one binary from a source package in NEW, it's all or nothing ...
[01:27] <daniels> Mithrandir: the dude who did it for debian ... flavio?
[01:27] <janimo> I see it depends on kivio & co 
[01:27] <janimo> aren't those implicitely requested by that page?
[01:27] <Mithrandir> doko: can you remove the xorg-driver-fglrx then add it again and see if it solves the problem?
[01:27] <Lathiat> what is with kde and big fat source packages
[01:28] <janimo> kivio,kword,krita,kspread are all built from same source?hmm, ok
[01:28] <daniels> yes
[01:29] <janimo> so returning to my question separate pages for separate source pkgs? (about a dozen)
[01:30] <hmrocha> daniels, i upgraded to the last breezy, my keyboard is working again
[01:30] <daniels> Kamion: thanks for shoving it through.  i'm going to go pass out on the couch or some shit.
[01:30] <janimo> daniels, btw are there already known screenblack issues with libvgahw or should I file a bug? Using trident
[01:30] <Mithrandir> Riddell: if you want to have ia32-libs-kde you need to have a kde which doesn't fall over if you look at it. :-/
[01:30] <janimo> I saw debian had some miscompilation problem on that module a while back
[01:31] <_d4vid> play Sido - Fuffies Im Club.mp3
[01:33] <doko> Mithrandir: no, only if I deinstall the driver, make the ia32-libs update, and then reinstall the driver
[01:33] <Mithrandir> doko: ok, that's right.  The driver is broken and should be fixed, then.
[01:34] <Mithrandir> doko: I can do that, but it looked right from the first skim
[01:37] <doko> Mithrandir: ok, not that important, doesn't effect the buildds
[01:43] <Mithrandir> Riddell: ping?
[01:43] <DanielN> seb128, ping
[01:45] <seb128> DanielN: pong
[01:48] <DanielN> did you tried the published patch on gnome bugzilla? (the keyboard thing)
[01:50] <seb128> nop
[01:50] <seb128> what bug is that? the crasher when adding new layout?
[01:51] <Amaranth> *boggle*
[01:51] <Amaranth> python2.4-apt build-deps on python2.3 and python2.3-dev
[01:52] <seb128> lol
[01:52] <DanielN> seb128, yes tat one
[01:52] <seb128> it doesn't crash here
[01:52] <seb128> so no point to try a patch
[01:52] <DanielN> and the patch don't work... it says that only garbage is in the input file :)
[01:52] <DanielN> so i can't test it too
[02:00] <Mez> pitti: you still around?
[02:00] <pitti> Mez: yes
[02:00] <pitti> Mez: it's only 2pm here :-)
[02:00] <Mez> pitti: I'm having lots and lots of problems with thunderbird and enigmail - It's crashing all over the place
[02:01] <Mez> pitti: yeah, but you could have gone the pub for lunch or somehting
[02:01] <Mithrandir> Mez: no, I haven't done guifications yet.
[02:01] <Mez> Mithrandir, that's ok :D
[02:01] <pitti> Kamion: there is a new upstream microrelease for notification-daemon (still universe, but scheduled for main); it incorporates my patches and fixes two other smal bugs; I reviewed the complete diff (not much). Permission to breaUVF?
[02:02] <Riddell> Mithrandir: hi
[02:02] <pitti> Mez: me too, ffox and moz crash, too since recently
[02:02] <janimo> any way to tell apt-cache to only provide info about latest packages, not also on the ones installed
[02:02] <Mez> pitti: I just realised I should be talking to infinity not you :D
[02:02] <Mez> pitti, my FF is working fine, just my thunderbird sint
[02:02] <Mithrandir> Riddell: hi, there you are.  It appears that the style loader in KDE becomes slightly unhappy when mixing 32 and 64 bit stuff.
[02:03] <pitti> Mez: so far we don't have an official moz maintainer 
[02:03] <Mez> pitti: fair enough :D but we need one... cause thunderbird is getting ridiculous
[02:03] <pitti> agreed
[02:03] <Mez> It's crashing neaar enough every time I try and send an email
[02:04] <Mez> pitti: asac doesnt want to jump on the ubuntu train I presume?
[02:04] <pitti> no idea
[02:05] <Mez> pitti: I'm gonna try building 1.06-3 from debian
[02:05] <Mez> see if that works any better
[02:06] <pitti> would be interesting to compare the patches
[02:06] <pitti> tbird has a proper patch system which makes this easy 
[02:06] <Riddell> Mithrandir: hmm, not sure what to say to that.  style loader can get very tempremental about having been compiled with exact same version of gcc as qt, it should default back to a win95 style though
[02:07] <janimo> pitti do you know if building a non-gnome enabled ff package would be troublesome?
[02:07] <Mez> pitti: be interesting to see if the damn thing WORKS
[02:07] <pitti> janimo: no, sorry
[02:07] <Mithrandir> Riddell: ok, and you're fine with that, if ooo2-amd64 looks win95 style?
[02:09] <Riddell> Mithrandir: what is 32 bit and what is 64 bit here?
[02:09] <Mithrandir> Riddell: ooo2 is 32 bit, rest of the system is 64 bit.
[02:09] <Mithrandir> that is ooo2 and any libs it needs.
[02:10] <Riddell> Mithrandir: so qt and kdelibs are 32 bit?
[02:10] <Mithrandir> they exist in both 32 and 64 bit versions, yes
[02:10] <Mithrandir> elmo: please nuke the ia32-libs-kde 1 upload, it broke.
[02:11] <Riddell> Mithrandir: which style are you set to use?
[02:12] <Mithrandir> Riddell: no idea, I just installed kubuntu-desktop, made a test user and logged in in "KDE" through gdm.
[02:12] <seb128> pitti: libnotify is main now?
[02:12] <pitti> seb128: I added inclusion reports and g-v-m depends on it
[02:12] <Riddell> Mithrandir: you need a version of qt, kdelibs and kde-style-lipstik all compiled with the same gcc version (and presumably all 32 bit)
[02:12] <pitti> seb128: gnome-power and update-notifer want it, too
[02:13] <seb128> pitti: k, so I can make gnome-applets using it now?
[02:13] <pitti> yes
[02:13] <seb128> cool, you rock
[02:13] <pitti> hehe :-)
[02:13] <pitti> seb128: upstream fixed n-d upstream now
[02:13] <Mithrandir> Riddell: ok, and if I put anything kde-style-lipstik needs in /usr/lib32 instead of /usr/lib, it'll work?
[02:14] <Riddell> Mithrandir: in theory, yes
[02:14] <janimo> elmo, please sync ecosconfig has the correct wx2.4 depends in debian, thanks
[02:15] <Mithrandir> Riddell: ok, let's see if we can make this pig fly, then.
[02:21] <pef> hello
[02:26] <Kamion> pitti: yes, that's fine
[02:29] <seb128> can anybody try what keycode he gets for "volume down" with the gnome keyboard stuff?
[02:29] <seb128> and for "media"
[02:30] <Lathiat> 0xae here
[02:30] <seb128> thanks
[02:30] <seb128> same here
[02:30] <Lathiat> dell inspiron laptop
[02:30] <paolo> seb128, how do you bind them?
[02:30] <seb128> mjg59: is "volume_down     0xa3" a typo? Seems to be 0xae
[02:30] <Lathiat> theres a list of some on the wiki
[02:31] <Lathiat> seb128: its hardware dependant..
[02:31] <seb128> Lathiat: https://bugzilla.ubuntu.com/show_bug.cgi?id=13050
[02:31] <seb128> Lathiat: are you sure?
[02:31] <Lathiat> seb128: yes, while many may share similarities, it varies wildly
[02:32] <Lathiat> look at one of th ekeyboard packages
[02:32] <seb128> Lathiat: so it doesn't make sense to put defaults?
[02:32] <Lathiat> seb128: you could try and find the "most common"
[02:32] <seb128> how?
[02:32] <Lathiat> get a list of various keycodes
[02:32] <Mithrandir> Riddell: that was a theory.  It didn't appear to hold.
[02:32] <Lathiat> try find similarities
[02:32] <Lathiat> best way to do that
[02:33] <seb128> Lathiat: very funny
[02:33] <Lathiat> is to get one of the other shortcut packages
[02:33] <Lathiat> which have definitions for lots of keyboards
[02:33] <Lathiat> im trying to find one
[02:33] <Lathiat> lieankd, hotkeys
[02:33] <Lathiat> *lineakd, hotkeys
[02:34] <Lathiat> fortunately mine matches that list apart from 0xa3
[02:35] <seb128> same here
[02:36] <Lathiat> i can tell you what my two normal keyboards have later this week
[02:36] <mjg59> seb128: Looks like it, yes
[02:36] <mjg59> Sorry, my mistake
[02:36] <seb128> np, don't worry
[02:36] <Lathiat> it'd rock if the volume buttons worked in gdm. :)
[02:36] <Lathiat> or there was a mute button, or something
[02:36] <Lathiat> for like, logging in in a lecture
[02:37] <mjg59> Lathiat: The idea is to use hotkey-setup to map other keyboards to the "standard" (read "Microsoft") mappings
[02:37] <Lathiat> mjg59: ah cool
[02:38] <seb128> mjg59: what key is "music"?
[02:38] <paolo> Here 0xae matches volum down.
[02:39] <seb128> I've a "media" key "0xed" here
[02:39] <mjg59> seb128: Hrm. Probably launch music player.
[02:39] <seb128> mjg59: no, but the key .. is that a different of "media"? 
[02:40] <seb128> my keyboard has few multimedia keys
[02:40] <mjg59> seb128: Unsure
[02:40] <rob^^^> that reminds me, Ive got a couple of keys that aren't recognized for binding purposes on my keyboard
[02:40] <rob^^^> in the config utility, if I press it, it just sits there waiting for me to press a key
[02:40] <seb128> mjg59: k, let's say the media is different from music 
[02:41] <rob^^^> I think calculator, logoff, and sleep but im in OS X for now...
[02:41] <Riddell> Mithrandir: what does this give you `strings /usr/lib/kde3/plugins/styles/lipstik.so | grep -i build`
[02:41] <Riddell> s/lib/lib32/ presumably
[02:42] <rob^^^> my keyboard does have both "My Music" and "Media" keys
[02:43] <seb128> mjg59: k, I'm uploading the package
[02:43] <mjg59> seb128: Rock, thanks
[02:43] <seb128> rob^^^: is music "0xbc"?
[02:43] <seb128> mjg59: np, thank you for the list
[02:44] <rob^^^> seb: I can check, but I'd need to reboot. Is that okay?
[02:44] <seb128> rob^^^: don't bother
[02:45] <rob^^^> "Microsoft Wireless 
[02:45] <seb128> rob^^^: the value is probably fine, I've uploaded with it ... we can fix it with an another version if somebody notice an issue
[02:45] <rob^^^> err "Microsoft Wireless Natural MultiMedia Keyboard" (accidentally hit enter turning it over)
[02:46] <rob^^^> (btw, it's a good keyboard)
[02:46] <Lathiat> ugh those natural stupid pos
[02:46] <rob^^^> I'v been toying about trying to hack up to cheap ergonomic keyboards to create to independent bluetooth keyboard halfs
[02:47] <rob^^^> Natural is good. I'm mad they don't make a USB natural anymore though
[02:47] <rob^^^> also you can get em for <$20, so thats a plus
[02:47] <sladen> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-5.html and http://www.nirvani.net/docs/Microsoft_natural_multimedia_keyboard_scancodes.html 
[02:48] <rob^^^> why were sleep and friends not being assigned then? Are those in a reserved range or something?
[02:51] <rob^^^> btw, there are a bunch of xml files in /System/Library/Keyboard\ Layouts on 10.4 that might prove helpful to someone
[02:52] <rob^^^> can't assign those keys in OS X either
[02:53] <rob^^^> http://developer.apple.com/technotes/tn2002/tn2056.html has more info
[02:54] <Lathiat> yeh lineakd has similar
[02:54] <Lathiat> and hotkeys
[03:18] <Kamion> oh, bugger
[03:19] <Kamion> libdps1 was only built from xfree86, and is now removed
[03:19] <Kamion> but libmagick6 depends on it
[03:19] <lu|sleep> could someone approve my non-member post to ubuntu-devel@ from last night?
[03:20] <Kamion> seb128: could you please rebuild gnome-applets and gnome-system-monitor against libwnck18?
[03:21] <ogra> lu|sleep, try to wake up jdub or get mako to do it
[03:22] <lu|sleep> they are the only two moderators? OK.
[03:23] <lu|sleep> mako should be awake, he has no excuse ;)
[03:24] <ogra> heh
[03:24] <rob^^^> some of these mails from -devel are rather sad "if we remove the workspace switcher app from the default panel there will be no reason for anyone to use Ubuntu! It will be Windows!"
[03:24] <Amaranth> jdub is still on the west coast?
[03:25] <seb128> Kamion: sure
[03:25] <lu|sleep> Amaranth: LWE DF
[03:25] <lu|sleep> s/DF/SF?
[03:25] <lu|sleep> s/DF/SF/
[03:25] <Amaranth> whatever you just said
[03:25] <lu|sleep> he is at linux world expo san francisco
[03:26] <mako> lu|sleep: hey
[03:26] <mako> lu|sleep: i am awake.. but still pre-coffee
[03:27] <lu|sleep> mako: I have a perfect task for someone not yet sentient
[03:27] <lu|sleep> mako: I emailed ubuntu-devel last night,but am not subscribed; could you pull my email out of the queue?
[03:27] <mako> lu|sleep: sure.. what's your email?
[03:27] <lu|sleep> luis.villa@gmail.com
[03:28] <mako> lu|sleep: cool
[03:28] <lu|sleep> subject 'breezy liveCD issues' I believe
[03:28] <mako> lu|sleep: i'll approve all future email from you too
[03:29] <mako> lu|sleep: why don't you subscribe
[03:29] <mako> lu|sleep: you know you can subscribe and then select to not recieve mail
[03:29] <lu|sleep> oh, hrm, had forgotten about that option
[03:29] <mako> well, it's a bit, er, counterintuitive
[03:29] <mako> that tends to be a smart option
[03:29] <mako> ubuntu-devel is better than most
[03:29] <mako> i've not followed debian-devel actively in a long time
[03:30] <lu|sleep> it still looks pretty high traffic, though admittedly traffic I'm curious about
[03:31] <rob^^^> lu: I dont have a problem with it, the key is to have your filters set up right to et it out of your inbox
[03:31] <rob^^^> I still haven't changed my subscription mode to devel from digest though
[03:31] <lu|sleep> rob^^^: I won't read it, and I don't like being on lists I don't read
[03:32] <lu|sleep> no matter how well filtered it is
[03:32] <Kamion> seb128: thanks. that's two of the three ubuntu-desktop uninstallables, and I'm fixing the other one now
[03:32] <lu|sleep> (and I don't really believe in filters, either, except for bugmail, since it again leads to lists that don't get read)
[03:32] <Lathiat> hrm
[03:32] <Lathiat> i filter things
[03:32] <Lathiat> makes it easy to look for specific things
[03:32] <Lathiat> i dont really care to read all mail to the lists im on
[03:33] <lu|sleep> if you need filtering to look for specific things, that means your mail software has poor searching :)
[03:33] <Lathiat> i just pick things out that look relevant or interesting, and if someone mentions something i can pull it up later
[03:33] <Lathiat> lu|sleep: no it means i already have all my lists split out, no need to setup a bunch of views or searches or whatever and then i can easily, on either mutt or evolution or thunderbird or webmail read through what i want
[03:33] <Lathiat> (i read my mail with imap)
[03:39] <mako> lu|sleep: cool, message approved
[03:42] <Mithrandir> Riddell: buildkey=i686 Linux g++-4.* full-config
[03:43] <lu|sleep> mako: thanks
[03:43] <Riddell> Mithrandir: and `strings /usr/lib32/libqt-mt.so | grep i686`
[03:43] <Mithrandir> Riddell: i686 Linux g++-4.* full-config
[03:43] <Mithrandir> Riddell: that's not the problem, it doesn't complain, but it doesn't work either.
[03:43] <Mithrandir> Riddell: it complained before
[03:45] <Riddell> Mithrandir: so its still defaulting to win95 style?
[03:45] <Mithrandir> Riddell: yes
[03:46] <Riddell> Mithrandir: try rm -r ~/.kde ~/.kderc ~/.qt  and then launching openoffice
[03:46] <pvanhoof> how secure would it be if I upgrade my breezy today? will xserver still work? :)
[03:47] <pvanhoof> or is the xserver packager dude still not finished with his changes?
[03:47] <pvanhoof> and/or how "unfinished" is it?
[03:47] <pvanhoof> -- if I can get it working without having to recompile an X11 server/implementation, it's okay --
[03:48] <Kamion> a few things are uninstallable and are being worked on, but it's mostly fine
[03:48] <pvanhoof> Kamion, aha ok. But it's not "important" things today?
[03:49] <pvanhoof> so I'll get my X environment up and running?
[03:49] <Mithrandir> Riddell: it's a fresh user.
[03:49] <pvanhoof> A few weeks ago I first had to fix a few xfonts problems .. I can manage such problems :p
[03:49] <pvanhoof> but if the x package this time removes all bins in my /usr/bin/X11 :)
[03:49] <Kamion> pvanhoof: nothing big, no
[03:49] <pvanhoof> that wouldn't be cool
[03:50] <pvanhoof> ok
[03:50] <Riddell> Mithrandir: if you start kcontrol in appearance and themes->styles what is available?
[03:50] <pvanhoof> going to upgrade the x-* packages tomorrow then ..
[03:50] <pvanhoof> :)
[03:50] <Kamion> pvanhoof: you might have to do a second install pass to cope with a small file overwrite bug in xserver-xorg / xserver-xorg-core
[03:50] <pvanhoof> Kamion, doable :
[03:50] <pvanhoof> :)
[03:50] <Kamion> but that's just "run apt-get dist-upgrade twice"
[03:51] <pvanhoof> I'm atm installing some of the trivial upgrades .. like the gstreamer ones etcetera :)
[03:51] <pvanhoof> you guys have been working hard for the last three/four weeks :)
[03:51] <pvanhoof> lol
[03:51] <Mithrandir> Riddell: loads, lipstik is the chosen one.
[03:52] <Mithrandir> Riddell: and, it appears it doesn't open anything matching lib32, but it's kinda hard to see because strace is icky
[03:54] <Riddell> Mithrandir: try setting to plastik and see if openoffice loads with that
[03:58] <Mithrandir> Riddell: hmm, it did then just complain about the buildstring.
[03:58] <Mithrandir> Riddell: I'll hack around it.
[03:58] <pitti_> seb128: do you know which part of gnome starts esd with the session?
[03:58] <pitti_> seb128: I would like to change esd to autospawn by default, but the esd started by gnome session does not time out automatically
[03:58] <Riddell> Mithrandir: what sort of hack?
[03:59] <Mithrandir> Riddell: override open, I think.
[03:59] <Mithrandir> similar to the pangohack in -gtk
[04:00] <seb128> pitti_: gnome-session starts it
[04:01] <seb128> pitti_: have you changed the autospawn key for /etc/esound/esd.conf ?
[04:02] <pitti_> seb128: yes, and if I kill esd, then the following spawned esds work fine
[04:02] <pitti_> seb128: the manpage says that autospawn is not recommended for sound events
[04:02] <pitti_> seb128: but without autospawn I have a dilemma
[04:03] <pitti_> seb128: if I remove the default device, esd still has an open connection to it, and thus the module is not unloaded and I don't get a hotplug notification
[04:03] <pitti_> seb128: after I kill esd, then the modules are freed, and the device disappears
[04:04] <pitti_> seb128: but I can't react to a removed device wihtout any hotplug notification
[04:04] <pitti_> seb128: polypaudio solves this, but it's too late for breezy
[04:05] <pitti_> seb128: ah, I think I know what to change, nevermind
[04:12] <seb128> pitti_: what was it?
[04:12] <sivang> jamesh: any news about the lib?
[04:12] <seb128> sivang: did you send it? I didn't get the mail
[04:24] <jbailey> infinity: Eh?  What happened?
[04:45] <BenC> anyone know how to get back the ctrl+alt+Fn behavior in breezy's X?
[04:45] <BenC> doesn't let me switch back to a vt like it should
[04:47] <mdke> you need to sort out your xkb probably
[04:48] <mdke> see this thread: http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/009421.html
[04:48] <BenC> thanks
[04:49] <Kamion> BenC: a dist-upgrade should sort it out, too
[04:50] <Kamion> as of the last couple of hours
[04:50] <BenC> ok
[04:57] <BenC> yeah, that works now
[04:58] <john6000> hello i have a suggestion
[04:58] <john6000> in the install can you have a choice of either GRUB or lilo
[04:58] <john6000> it would help everyone a lot
[04:58] <HrdwrBoB>  the average user doesn't know or care
[04:59] <john6000> but think of the advantages not disadvantages
[04:59] <mdke> you have to think of both
[04:59] <john6000> ok maybe you do
[05:00] <john6000> you stick with your 0.8 grub even thow version 1 was out well before ubuntu 5.04 so why didnt you just use that?
[05:07] <Kamion> I've sorted out john6000 in /query
[05:15] <skora> nice.
[05:16] <skora> now he's trying to give out incorrect info in the main channel 
[05:18] <chmj> shackan, ping 
[05:21] <shackan> chmj, boing
[05:25] <pitti> have to leave early today, cu tomorrow!
[05:29] <bddebian> Heya
[05:36] <Mithrandir> jbailey: any idea why I seem unable to override libc functions in an LD_PRELOADed object?
[05:41] <doko> ouch, dpkg segfaults on the amd64 buildd as well ...
[05:43] <\sh> doko: yes...but this is an old symptom...I reported that last week?
[05:59] <WaterSevenUb> is anyone here using firestarter? I need to confirm a bug... in outbound connection events tab, click with the right button of the mouse. In my case, appears the same options as in an inbound event.
[06:01] <WaterSevenUb> at least using a translated firestarter.. not sure if the same happens in pure english. In other words, select "outbound event" - "select with right button of the mouse" , compare the options with those of an "inbound event"
[06:01] <WaterSevenUb> oops.. breezy is universe...
[06:09] <carstenh> WaterSevenUb: LC_MESSAGES=C firestarter should start it in english
[06:26] <mvo> seb128: do you know notification-daemon upstream? are they available on irc?
[06:29] <koke> mvo: isn't it #galago? or it's another different thing?
[06:30] <mvo> koke: I think that's it, thanks
[06:32] <Kamion> damn, dpkg segfaults on the amd64 buildd are going to make my partman->partman-base transition painful
[06:46] <Kamion> jbailey: does initramfs-tools 0.17 fix the install problem I reported?
[06:46] <Kamion> jbailey: I need to make base-installer deal with initramfs-tools all of a sudden, so I need to be able to install it from scratch ;-)
[06:48] <jbailey> Kamion: Dunno. Where's the report?
[06:48] <jbailey> =)
[06:48] <jbailey> Sorry, I'm not up on all my email atm.
[06:48] <Kamion> #13334
[06:49] <Kamion> (also #13335, less important)
[06:49] <jbailey> 13334 is fixed, yes.
[06:50] <Kamion> ah, you ship initramfs.conf but the sed hit mkinitramfs.conf
[06:50] <Kamion> I assume initramfs.conf is right
[06:50] <jbailey> Yup. =)
[06:50] <jbailey> Fixed in 0.17
[06:50] <jbailey> 13335 isn't, but I  hadn't hit that one.  Hmm
[06:50] <Kamion> ok, will hack up something in base-installer for that
[06:50] <jbailey> I usually drop a blank modules file in at upgrade time, but I suppose the user could delete it.
[06:51] <jbailey> Kamion: Thanks! =)
[06:51] <Kamion> jbailey: is there any equivalent of initrd-tools' DELAY in initramfs-tools
[06:51] <Kamion> ?
[06:51] <jbailey> Kamion: No.  If you want to break, just add 'break' to the kernel command line.
[06:52] <jbailey> Kamion: Do you need a delay setting?
[06:52] <Kamion> no, it's just that base-installer was setting DELAY=0 in mkinitrd.conf and I wanted to check the equivalent
[06:52] <jbailey> Ah, makes sense.
[06:52] <Kamion> it also sets ROOT=
[06:52] <Kamion> should I omit that too?
[06:52] <jbailey> Hmm
[06:53] <jbailey> I wonder if it's ever the right thing to have it in the initramfs instead of the kernel command line.
[06:53] <doko> Mithrandir: OOo2 1ubuntu8 should look in /usr/lib32 first
[06:53] <seb128> mvo: ChipX86 on #gnome-hackers on the GNOME IRC ... why ?
[06:53] <Kamion> d-i arranges for it to be on the kernel command line too; if that's enough, that's fine
[06:55] <paolo> To the person mantaining Xorg: http://paste.ubuntulinux.nl/1111
[06:56] <Kamion> paolo: I'm guessing daniels has gone to bed
[06:56] <mdz> ogra: if you're having problems with the ldm password thing and using echo fixes it, you're encountering a unionfs bug
[06:56] <mdz> ogra: the latest ltsp should worka round it
[06:57] <ogra> great
[06:57] <paolo> Kamion, ouch!  This is gonna be a problem, I think.
[06:57] <Kamion> paolo: I'm checking now, if it's easy I'll release a quick bugfix
[06:58] <paolo> Kamion, you rock.
[06:58] <ogra> mdz, i have a themed version of ldm running over here... and fixed the cursors a bit last night... building a mousetrap for the window will get a bit trickier...
[06:58] <madduck> mdz: did you see James Blackwell's post to the deity list?
[06:58] <mdz> madduck: no
[06:59] <madduck> mdz: if you have a minute...
[06:59] <mdz> madduck: I am working
[06:59] <madduck> mdz: it's not irrelevant. but take your time...
[06:59] <madduck> http://lists.debian.org/deity/2005/08/msg00087.html
[06:59] <mayco> the new xorg package gives an erro when installing: internal error: auto_answer() called with wrong number of arguments: db_input low xserver-xorg/config/write_files_section
[06:59] <mayco> should I file a bug?
[07:00] <madduck> mdz: i am just not sure that this is in accordance with bzr and hct plans.
[07:00] <Kamion> mayco: paolo just mentioned the same thing, I'm investigating now
[07:00] <mayco> okay
[07:01] <Kamion> madduck: James Blackwell is a Canonical employee; it seems unlikely that it would be wildly out of step
[07:01] <madduck> ok. i did not know. excellent.
[07:01] <mdz> madduck: Bazaar 2 = bzr
[07:01] <madduck> so now there is bzr, baz2, and hct. how the heck to make sense out of all those? :)
[07:01] <madduck> mdz: then it's curious why James didn't just say so.
[07:01] <Kamion> baz is converging with bzr
[07:02] <madduck> that's what i thought.
[07:02] <mdz> madduck: that would be a question for jblack, or #bazaar, or a bazaar mailing list
[07:04] <fabbione> hey guys
[07:04] <fabbione> enjoy the last days without me :)
[07:05] <janimo> hey fabbione, a question:
[07:05] <janimo> is providing vmlinux (no full debug) possible for breezy kernel images?
[07:06] <janimo> needed for oprofile 
[07:06] <fabbione> janimo: i am in vac.. don't trust my answers.. my brain is fuly disconnected :)
[07:06] <janimo> it's not the 150M scary package that's been rumored
[07:06] <fabbione> janimo: if i will remember.. i might..
[07:06] <janimo> I am not trusting them ;)
[07:06] <janimo> cool, if I can I'll help
[07:07] <janimo> have a good vac
[07:07] <fabbione> janimo: you might want to look into kernel package. it's the one creating the .debs for the -images-
[07:07] <janimo> ok I will, I just wanted to know if it would be ok or was there a decision against it
[07:08] <fabbione> it shouldn't be an issue...
[07:08] <janimo> I see the bug on debian requesting vmlinux ended unconclusively
[07:08] <fabbione> but if you can gimme a patch, it will be faster
[07:08] <janimo> ok then I put it on my TODO ;)
[07:11] <fabbione> thanks
[07:12] <bddebian> mako is IT? :)
[07:15] <robitaille> "the and a mako it mako"?  
[07:16] <mako> robitaille: watch planet in like 10 minutes .. you'll see
[07:20] <jbailey> mako: Quick, everyone ddos mako's blog with the refresh button. =)
[07:21] <mako> jbailey: it won't take all of you :)
[07:22] <dieman> so
[07:22] <mdz> lamont-away,infinity: livefs build on terranova seems busted (stale lockfile?)
[07:22] <dieman> how long do old releases stay in the archive?
[07:23] <dieman> im trying to size out new disks for a machine to move our mirror over to
[07:23] <mattyJ> is mono currently broken in breezy (just want to make sure its not my setup)
[07:25] <infinito> is there any way to make a pkg depend on another source pkg to build?
[07:26] <fabbione> infinito: no
[07:26] <infinito> fabbione: ummm, latest mail-notification needs evolution sources to compile an evo plugin...
[07:28] <fabbione> infinito: are you sure you are not looking for something like evolution-dev ?
[07:28] <Treenaks> Kamion: any news from the sysfs/grep/sed front?
[07:29] <mdz> elmo: could you confirm that no live build is running on terranova, and upon confirmation, rm -f /home/buildd/buildLiveCD.lock ?
[07:29] <infinito> fabbione: i think so... while compiling it looks for some .h files which seems not to be included on evolution-dev
[07:31] <paolo> Kamion, what do you suggest?  If I power off the laptop, will xorg be broken when I turn it up again?  I mean, should I wait for the fix or it is not crucial?
[07:32] <fabbione> infinito: it depends what it is looking for.. the includes might a) not shipped b) not be there anymore c) in other -dev packages
[07:33] <infinito> fabbione: i've looked for the files on packages.ubuntu.com search and they seem not to be included in any pkg
[07:34] <fabbione> infinito: than the best thing to do is to talk with the evo maintainer and see why they are not included. Are you 100% sure they come from evo source?
[07:34] <sivang> lol
[07:35] <Kamion> paolo: quick fix: edit /var/lib/dpkg/info/xserver-xorg.config as root, go to the very end, look for the pair of 'auto_answer db_input' lines, change '||' into 'true ||' on each of those two lines, and run 'dpkg --configure -a'
[07:35] <infinito> fabbione: the files are evolution-2.2.1.1/mail/em-event.h and 3 more in this folder of evo source
[07:35] <fabbione> infinito: than talk to the evo maintainer.
[07:36] <fabbione> these files might not be shipped because they are not supposed to expose private evo interfaces
[07:36] <Kamion> xorg fix uploading, anyway
[07:37] <Kamion> infinito: packages.ubuntu.com isn't always up to date (not its fault, we only generate the Contents files it needs a bit irregularly)
[07:37] <paolo> Kamion, do you mean the "true" part of this?  auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xorg/autodetect_video_card "true"
[07:37] <Kamion> paolo: wrong line
[07:37] <Kamion> paolo: you're looking for xserver-xorg/config/write_files_section and xserver-xorg/config/write_dri_section
[07:37] <Kamion> but "true" in that position, yes
[07:37] <infinito> Kamion: is there any way to look for a file between packages other than this?
[07:38] <Kamion> infinito: not really
[07:42] <paolo> auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xorg/autodetect_keyboard "$AUTODETECT_KB" || debug_echo "db_input xserver-xorg/autodetect_keyboard" ?
[07:42] <paolo> Kamion, I think line numbers would be better :-)
[07:43] <Kamion> paolo: yeah but deriving those from the source was tricky, and I was in a hurry :)
[07:43] <Kamion> paolo: it's *right* at the end
[07:43] <Kamion> paolo: lines 2048 and 2049
[07:44] <paolo> 2048 is empty, 2049 is #vim:set ai et sts=2 sw=2 tw=80
[07:46] <mvo> Kamion: permission to upload notification-daemon? it fixes a bug in the arrow placement when the target x-coordinate is set to the far right corner
[07:51] <elmo> mdz: done
[07:51] <Kamion> mvo: yes
[07:51] <paolo> Kamion, how is the fix going to reach local apt?
[07:52] <Kamion> paolo: meh, it might be somewhere else while partially configured. I've uploaded a fix, it's building
[07:58] <mdz> elmo: thanks much
[08:00] <paolo> Kamion, the mail hit breezy-change, good!
[08:00] <paolo> changes, even
[08:04] <pef> bye !
[08:04] <pef> !bye
[08:06] <paolo> To anybody on breezy - does xfont-terminus work for you?
[08:07] <robitaille> mako... now your nick-changing act makes sense :)    
[08:10] <mako> robitaille: it all makes sense eventually
[08:14] <mdz> Kamion: thanks for the xorg fix; just noticed that it broke the livefs build
[08:43] <mdz>     if $FANCYTTY; then
[08:43] <mdz> that isn't valid posix sh, is it?
[08:43] <mdz> where $FANCYTTY is 1 or 0
[08:43] <Kamion> no; if $FANCYTTY were : or false, it would be
[08:44] <Kamion> (idiom for doing booleans in shell without having to fork [)
[08:46] <shaya> /usr/include/evolution-2.4/mail/mail-component.h:31:28: error: Evolution-Mail.h: No such file or directory
[08:46] <shaya> seems to be a bug in evolution-dev package
[08:53] <Kamion> mdz: for the purposes of UE review, does the installer team consist of more than me? :)
[08:53] <Kamion> I'm just worried about being a blocker, considering my busyness level right now
[08:55] <mdz> Kamion: that shell snippet was from the new lsb in experimental which attempts to merge our changes
[08:55] <mdz> but as far as I can tell it has no chance of working at all in its current form
[08:57] <Kamion> mdz: didn't lsb in unstable take our lsb-base ages ago?
[08:58] <mdz> Kamion: hmm, so it did.  though we still have a diff relative to unstable, and experimental makes other changes
[08:59] <mdz> oh, the version in experimental is older than unstable
[08:59] <mdz> unstable seems to fix the syntax
[09:01] <Kamion> indeed, should be NVIU'ed
[09:04] <Kamion> lamont-away,infinity: please give-back partman-base once the chroot is fixed; that's a somewhat delicate transition there and I want to get it through
[09:04] <Kamion> lamont-away,infinity: er, on amd64, that is
[09:13] <Mithrandir> doko: ok, is it uploaded?
[09:15] <Kamion> jbailey: just as a thought, would it be worth attempting to fetch RESUME from mkinitrd.conf in initramfs-tools' postinst?
[09:15] <Kamion> migration, and all that
[09:16] <marcin> hi all
[09:16] <marcin> I got a question about general packaging procedure
[09:16] <marcin> do you guys got some tools to build packages recursively?
[09:17] <bddebian> Oh no, he's back :-)
[09:17] <marcin> bddebian: hi :D
[09:17] <Kamion> packages don't contain other packages, so there's no concept of recursion involved
[09:17] <doko> Mithrandir: uploaded, but the build did fail ... the uno bridge now fails to build ...
[09:18] <marcin> Kamion: right but I mean something to build a bunch of packages at once
[09:18] <Kamion> you could try pbuilder
[09:18] <Kamion> we use wanna-build/buildd/sbuild, but it's much more effort to set up; pbuilder is more designed for personal use
[09:18] <Mithrandir> doko: ok, can you prod me once a working version is in the archive?
[09:18] <marcin> I need to build a lot (about 400) packages with simmilar content
[09:18] <Kamion> normally such things would all be built from a single source package
[09:19] <Mithrandir> elmo: can you nuke the b0rked ia32-libs-kde upload for me, please?
[09:19] <Kamion> if that is not possible, you're mostly on your own because that's quite an unusual thing to do
[09:19] <Kamion> Mithrandir: I've done so
[09:20] <Kamion> assuming you meant the orphaned .dsc in queue/unchecked/
[09:20] <Mithrandir> Kamion: yes, thanks.
[09:20] <marcin> Kamion: hmmm and how you guys synchronize your packages with debian repositories?
[09:21] <marcin> Kamion: you do all 'manually' ?
[09:21] <Mithrandir> marcin: no, it's usually done automatically, if we don't have any changes wrt the debian version
[09:22] <Kamion> if we do have changes, there's a tool called merge-o-matic that files bugs against the packages for us with suggested merge output
[09:22] <marcin> Mithrandir: you got some scripts or specific tools to perform this synchronization?
[09:22] <Kamion> developers then review that output, tweak as necessary (or sometimes redo from scratch) and upload
[09:23] <Kamion> but it's not rocket science, it's just three-way diff and patch application
[09:23] <Mithrandir> marcin: yes, there's a tool which compares.  I don't think it's available, but it should be fairly trivial to write one which does the same.  Note that the merge-o-matic is another piece of machinery which is more complicated.
[09:23] <Mithrandir> Kamion: and some attempts at extraction of different parts, AIUI
[09:25] <marcin> Mithrandir: hmmm what machinery?
[09:25] <Mithrandir> marcin: merge-o-matic, as Kamion just described
[09:26] <Kamion> merge output publication, bugzilla interaction, that sort of thing
[09:26] <Kamion> it's all fairly boring scriptage I think
[09:29] <paolo> http://paste.ubuntulinux.nl/1115 do you know what it could be?  (I'm on an USB2 external drive breezy installation, I use initrd to load the usb modules)
[09:31] <Kamion> paolo: the kernel just switched from initrd to initramfs, and base-installer doesn't support that yet. I'm working on it at this very moment.
[09:32] <Kamion> but it will take me some hours
[09:32] <paolo> Kamion, nice.  I can't reboot yet, so :-)
[09:33] <Kamion> paolo: oh, is this in the middle of a fresh installation, or are you upgrading?
[09:33] <paolo> The former.  I'm keeping it upgraded to the bleeding edge because I need this terminus font and I hope for xorg eating it at some point.
[09:34] <Kamion> you're keeping it upgraded by repeatedly reinstalling? :)
[09:34] <paolo> no no :-D  update/upgrade/dist-upgrade
[09:34] <Kamion> so then you mean "the latter", not "the former"
[09:35] <paolo> Sorry I misunderstood previously - I mean it's not an upgrade from hoary or something.
[09:35] <Kamion> right, I'm asking whether you're actually in the installer right now
[09:35] <paolo> Nope, the system is installed and I have rebooted it before this last xorg upgrades.
[09:35] <Kamion> ok, disregard what I said, then
[09:35] <Kamion> is initramfs-tools installed?
[09:36] <paolo> Nope.
[09:37] <Kamion> Hah, somebody forgot to update linux-image-*'s dependencies.
[09:37] <paolo> I like being helpful :-)
[09:37] <Kamion> jbailey: ^-- linux-image-*'s depends needs to change from initrd-tools to initramfs-tools
[09:38] <paolo> Kamion, is there any doc about it?  I have found some HOWTO on ubuntuforums about how to make this external USB2 harddrive installation work.
[09:38] <paolo> But it only talked about mkinitrd.
[09:38] <mdz> Kamion: didn't it?
[09:39] <mdz> oh, it didn't
[09:39] <mdz> I had it installed already
[09:39] <Kamion> paolo: it's very new, and I haven't even had time to look at it much myself yet
[09:39] <mdz> Kamion: why should base-installer need to care, if the dependencies are correct?
[09:39] <Kamion> mdz: because base-installer needs to put the resume partition into initramfs.conf
[09:39] <mdz> ah
[09:40] <Kamion> mdz: in order to do that, it first has to install mkinitramfs-tools
[09:40] <Kamion> (so that the template config file is there)
[09:40] <mdz> I thought initramfs-tools did that itself
[09:40] <Kamion> it tries, but it doesn't have as much information
[09:41] <Kamion> well, theoretically at least. in practice the code is similar at the moment, but I can easily imagine partman hooks to let the user identify the resume partition
[09:41] <Kamion> perhaps in automatic installs
[09:42] <Kamion> base-installer's fiddling is more relevant for initrd-tools really, but at the very least I'd have to disable it
[09:42] <Kamion> and while I'm there anyway, it's not very difficult to make it do the analogous initramfs things
[09:43] <mdz> for some reason I thought /etc/exports wasn't a conffile, but it is.  I'll need to do something about that for ltsp
[09:52] <mdke> Simira, nice work on the Tshirts :D
[09:53] <mdz> argh, livefs builds still broken
[09:53] <mdz> Setting up ubuntu-artwork (0.2.24-1) ...
[09:53] <mdz> update-alternatives: unable to make /usr/X11R6/lib/X11/icons/default/index.theme.dpkg-tmp a symlink to /etc/alternatives/x-cursor-theme: No such file or directory
[09:56] <paolo> Kamion, is there a specific reason because there is no "xfontsel" in every xorg released today?
[09:57] <Kamion> paolo: probably still being modularised; the answer is the same for most missing binaries from xorg
[09:58] <Simira> mdke: thanks :)
[09:59] <paolo> Kamion, do you know how can I safely switch to the previous kernel?  So that I could reboot without messing with initramfs.
[09:59] <Kamion> paolo: you can just install the initramfs-tools package and the kernel should then configure cleanly
[10:00] <paolo> The following NEW packages will be installed:
[10:00] <paolo>   busybox-cvs-initramfs initramfs-tools klibc-utils libklibc
[10:00] <paolo> OK...
[10:00] <Kamion>  yes
[10:00] <mdke> Simira, do you envisage the thing becoming a fundraising initiative for Ubuntu?
[10:02] <paolo> Kamion, http://paste.ubuntulinux.nl/1116  any clues about what it did?
[10:02] <Kamion> mdz: looks like I should replace initrd-tools in the minimal seed with initramfs-tools, and bump initrd-tools out to supported?
[10:02] <mdz> Kamion: why was initrd-tools seeded anyway?
[10:03] <mdz> Kamion: I'm about to change the deps in l-s-2.6.12 unless you've already done it...
[10:03] <Kamion> mdz: no, I haven't; possibly because we explicitly avoid considering the kernel packages in debootstrap, so it avoids confusion to seed their deps
[10:03] <Kamion> paolo: interesting
[10:04] <mdke> mjg59, around?
[10:04] <Simira> mdke : I haven't really thought about it yet. I just provide t-shirts :p 
[10:04] <Kamion> paolo: that will stop happening once the kernel image properly depends on initramfs-tools, because apt won't try to configure the kernel image while initramfs-tools is only unpacked as opposed to configured
[10:05] <Kamion> paolo: nevertheless, it appears to have recovered successfully
[10:05] <Kamion> paolo: (as I would expect)
[10:05] <mdke> Simira, ok, but you must have thought about how much to charge right?
[10:05] <paolo> Kamion, good - so are you saying it kept my configuration about initrd?
[10:05] <Kamion> paolo: no, it's built an initramfs
[10:06] <paolo> Kaloz, which I need to configure?
[10:06] <Kamion> congratulations, you're a tester :)
[10:06] <paolo> I'm very pleased to help - I hope it compensates the begging I did here :-)
[10:07] <paolo> Furthermore I need the newer Gtk for my summer of code project, so messing with the bleeding edge was expected :-)
[10:07] <Kamion> might want to check that your grub configuration refers to it properly
[10:07] <Simira> mdke: sure. I take as little as possible, so it's mostly the cost of printing them and shipping. A little revenue goes to further t-shirt orders. If I'd make a webshop of it in time, a part will go back to Ubuntu.
[10:08] <Kamion> actually, it should be fine
[10:08] <paolo> initrd          /boot/initrd.img-2.6.12-6-386
[10:08] <Kamion> I'm just rebooting my own test system now
[10:08] <Kamion> yeah, that's actually an initramfs despite the name
[10:08] <mdke> Simira, yeah, i reckon if Ubuntu was interested, you could charge a little more
[10:08] <paolo> Cool.
[10:08] <mdke> Simira, anyway, thanks a bunch for doing it
[10:09] <Simira> :)
[10:09] <Kamion> I get a ton of "sed: Unsupported comand I" on boot, but otherwise it seems fine
[10:09] <paolo> What's wrong with sed.
[10:11] <paolo> By the way, it's a good news.
[10:11] <Kamion> nothing's wrong with sed
[10:11] <paolo> Kamion, do you use any initrd customized options?
[10:11] <Kamion> no
[10:11] <paolo> OK.
[10:11] <Kamion> udev is trying to use a GNU sed feature, which doesn't work with busybox
[10:12] <Kamion> but it's only in cdsymlinks.sh, so it's cosmetic at that stage
[10:12] <paolo> Hmm, udev here does strange things, too
[10:12] <paolo> For example it does not create some devices like /dev/hda* and /dev/hdc* which are respectively the harddrive and the dvddrive of my laptop.
[10:16] <eazel7> hi
[10:16] <eazel7> is sessmgr package missing?
[10:16] <mdz> mjg59: I whipped up an lsb init-functions which talks to usplash, but it looks like the fifo isn't there yet (on the real root)
[10:17] <paolo> eazel7, I've all updated and it seems to not be there, is it a xorg one?
[10:17] <eazel7> paolo yes
[10:17] <eazel7> I updated at home and it was there everything was nice
[10:17] <paolo> eazel7, it could be because of the modularization in act these days.
[10:17] <eazel7> but now it's missing in the space again
[10:17] <eazel7> lost in the space
[10:17] <eazel7> yup... too modularized :-P
[10:18] <paolo> Something is leaking, it will come.
[10:19] <eazel7> paolo stop saying things like that
[10:19] <eazel7> I think on sexual jokes :-P
[10:19] <paolo> Missing? :-)
[10:19] <Kamion> eazel7: sessmgr? do you mean sessreg?
[10:19] <paolo> sessreg is there.
[10:19] <eazel7> Kamion let me see
[10:20] <eazel7> yup
[10:20] <eazel7> sessreg
[10:20] <eazel7> not here =(
[10:20] <Kamion> sessreg is definitely there, I processed it this morning
[10:20] <Kamion> if you're using a mirror other than archive.ubuntu.com, it may not have reached it yet
[10:20] <eazel7> I've seen it at home
[10:20] <eazel7> but now I'm at work and it disappeared =(
[10:20] <paolo> eazel7, update, it's version 0.99.0-1
[10:21] <eazel7> Kamion I was using ar.arch... when I got it, now I changed to archive.ubuntu.com and it disappeared in both
[10:21] <eazel7> I've update a sec ago
[10:21] <Kamion> $ ssh jackass sudo -u katie madison sessreg
[10:21] <Kamion>    sessreg |   0.99.0-1 |        breezy | source, i386, ia64, powerpc
[10:21] <Kamion> it's most definitely there.
[10:21] <eazel7> don't know how to get it...
[10:21] <eazel7> through the web page
[10:22] <eazel7> it's a way, isn't it?
[10:22] <Kamion> we've determined that it is not missing, so there's no development issue involved; please take the rest to #ubuntu
[10:22] <eazel7> nope, it isn't
[10:37] <paolo> * Update hardcoded initrd-tools dependencies to initramfs-tools
[10:37] <mdz> paolo-changes?
[10:38] <paolo> Would you like a service like that?!
[10:40] <Kamion> I'm fixing that udev warning spewage now; it's easily worked around
[10:40] <paolo> Cool.
[10:48] <mdke> during the install guide, my wifi network was brought up and worked perfectly, but it didn't give me a choice of various AP's around here, just plumped straight for mine. how did it know, and how come I didn't get given a choice?
[10:48] <mdke> s/install guide/install process
[10:48] <Seveas> mdke, pure black magic
[10:48] <ajmitch> it probably looked for the strongest signal
[10:48] <mdke> that's what I figured, i just wanted to check
[10:48] <ajmitch> or luck
[10:49] <Kamion> it tries to do DHCP after association, to check
[10:49] <mdke> yeah I saw that
[10:49] <Kamion> and yeah, it just tries the blank essid
[10:50] <Kamion> so probably strongest signal
[10:50] <mdke> ah k
[10:50] <Kamion> I'd like to improve that (bug #1242); but netcfg is a pig to work on
[10:51] <Kamion> and I have no wireless cards that support scanning, annoyingly enough
[10:51] <Kamion> and only one local AP for that matter
[10:53] <mdke> well I only have one too, but there are a few closed networks around, i was just curious
[10:54] <seb128> clearlooks is shipped by gnome-themes/gtk2-engines packages now, what is the correct way to make that ... just a Replaces on the previous package?
[10:54] <seb128> or a Conflicts/Provides too?
[10:54] <paolo> seb128, did you see the cairo issue we pointed out on #cairo with cworth?
[10:55] <seb128> paolo: devhelp API?
[10:55] <paolo> seb128, yup, the devhelp thing.
[10:55] <seb128> I'm reading it atm
[10:55] <paolo> Cool, thank you.
[10:56] <seb128> paolo: what is basically the issue? We don't have libcairo-doc package?
[10:58] <paolo> seb128, yes, no documentation is installed with libcairo1, nor with libcairo1-dev
[10:58] <seb128> right
[10:58] <seb128> Debian package has a -doc
[10:58] <seb128> I've planned to sync with it but didn't come here yet
[10:58] <paolo> seb128, also the cairo doc doesn't have a title, I don't know if the debian guys fixed it.
[10:59] <seb128> not sure but that would be an upstream issue
[10:59] <paolo> Yup, I notified them.
[10:59] <paolo> I don't know how it goes for this kind of issues.
[11:01] <paolo> seb128, if I could ask: it passed the announce for rhythmbox-0.9.0 but it isn't on the repos, is there a particular reason?
[11:02] <seb128> mkdir .libs
[11:02] <seb128> libtool: link: cannot find the library `/usr/lib/libdbus-1.la'
[11:02] <seb128> 
[11:02] <seb128> daniels !!!!!
[11:02] <seb128> he keeps doing that
[11:02] <seb128> dropping .la files and breaking other packages
[11:03] <paolo> Argh :-)
[11:04] <seb128> is somebody going to upload a hal package for that or should I do it?
[11:06] <seb128>    * Remove *.la files from installation.
[11:06] <seb128>      + Gross hack to remove dbus_bindings.{a,la} from python2.4-dbus.
[11:06] <seb128> WTF
[11:07] <seb128> Kamion, mdz: what is the right fix here? Changing dbus to install libdbus-1.la or doing a rebuild of other stuff to drop the .la mention?
[11:09] <seb128> k, all the stuff using hal are FTBFSing now
[11:09] <seb128> thanks daniels
[11:09] <elmo> seb128: dude, you are getting more bitter by the day
[11:10] <elmo> I think soon you might wrap around, and become all happy and positive again ;P
[11:10] <seb128> ah ah
[11:10] <seb128> I'm not bitter :p
[11:10] <seb128> I've just enough to do without having daniels making half of GNOME FTBFSing every week
[11:18] <mdz> seb128: the .la file is supposed to be in a -dev package, right?
[11:19] <seb128> mdz: the dbus upload has
[11:19] <seb128>    * Remove *.la files from installation.
[11:19] <seb128>      + Gross hack to remove dbus_bindings.{a,la} from python2.4-dbus.
[11:19] <seb128> mdz: and the dropped the .la from the -dev too
[11:19] <ogra> phew...
[11:20] <seb128> but libhal.la mention it by example, which breaks the builds
[11:20] <seb128> mdz: I guess the correct fix is to only drop the .la from the python dbus package?
[11:21] <jbailey> Kamion: Yeah, that might work.  Right now I had been doing the same autodetection that the installer would do.
[11:21] <mdz> seb128: I can understand removing it from the python package; that doesn't make sense.  but surely it should be in -dev
[11:21] <seb128> mdz: k, I'm going to fix dbus then, thanks
[11:21] <Kamion> jbailey: I think doing both would make sense
[11:22] <jbailey> Yup
[11:22] <Kamion> ok, udev upload fixing those warnings done, so re-mkinitramfs with that and all should be happy
[11:22] <shaya> is anyone having a problem w/ initrd creation and new linux kernel?
[11:23] <Kamion> shaya: install initramfs-tools
[11:23] <Kamion> jbailey: mdz fixed it already
[11:23] <shaya> missing dependecy?
[11:23] <jbailey> Kamion, mdz: thanks.
[11:23] <mdz> it should be building about now
[11:23] <Kamion> shaya: right; there's a new kernel on its way
[11:23] <mdz> -6.10
[11:23] <shaya> would my old initrd have owrked?
[11:23] <mdz> yes
[11:23] <shaya> or would I have had to reboot to .10?
[11:23] <shaya> ah
[11:24] <shaya> so not hte biggest deal
[11:24] <mdz> shaya: do you think it's at all feasible that the other change from http://www.fsl.cs.sunysb.edu/pipermail/unionfs-cvs/2005-August/000260.html broke things for me?
[11:24] <mdz> it's either that, or some non-unionfs difference between our configurations, if you can't reproduce my bug
[11:24] <Kamion> shaya: if you had the new linux-image-* unpacked, then configuring linux-image-* will fail initially, but then apt will retry after configuring initramfs-tools and all should be happy
[11:24] <shaya> mdz: I made one line change and it worked
[11:24] <shaya> yes
[11:24] <shaya> everything's happy
[11:25] <shaya> mdz: I guess it's possible the dentry.c change made some problems for you
[11:25] <shaya> mdz: stick a printk() in that code to see if you're hitting it
[11:25] <shaya> as it sort of would make sense
[11:26] <shaya> as d_unhashed means unlinked
[11:26] <shaya> and that's what bash is doing, unlinked file
[11:26] <mdz> shaya: I'm going to try reverting to the same code you're using and see if that helps
[11:26] <robertj> mdz: did you see my lowly post about whether workspace-switcher applet should remain on the default panel?
[11:27] <shaya> mdz: in this case, it's not really the unionfs guys fault, this dentry revalidation is black magic, I've been looking for documentation about what it means, and havent found any
[11:27] <mdz> robertj: no
[11:27] <robertj> mdz: well err, that's pretty much the post...I've seen a few people lose apps on various virtual workspaces
[11:27] <shaya> anyone here read long: ?
[11:27] <shaya> login: that is
[11:28] <robertj> mdz: basically I figure the people who need them can find them but the people who don't might not know how/be afraid to remove them
[11:29] <mdz> robertj: as far as I'm concerned, that's a desktop team decision
[11:29] <mdz> robertj: ->seb128
[11:29] <robertj> oky
[11:30] <seb128> I've not strong opinion on the topic but imho that's fine this way
[11:30] <seb128> there is no real point to have an empty panel and it's quite useful
[11:30] <robertj> it is useful but its bad if you don't know what your doing and manage to "lose your icons"
[11:31] <seb128> next you will ask to configure with 1 desktop by default?
[11:31] <robertj> yup
[11:31] <seb128> there is other way than the applet to change desktop
[11:31] <seb128> the real fix would be to set the number of desktop to 1
[11:32] <paolo> Which automake/autoconf version do you suggest to install?  And why do you provide so many versions?
[11:32] <seb128> because upstream provide those version
[11:32] <robertj> yeah, I think I forgot to include that in my email, but yes, I'd think that would be needed as well
[11:32] <seb128> robertj: that's not going to happen imho
[11:33] <BenC> W: GPG error: http://bazaar.canonical.com ./ Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A817561ED2DFA262
[11:33] <seb128> robertj: what you want is a linux with 0 feature so you are you sure users don't use something they may not know :)
[11:33] <BenC> how do I get the pub key for bazaar release?
[11:34] <robertj> seb128: I think the interface should be very plain by default
[11:34] <seb128> paolo: I've 1.9 as default automake versionhere, works fine for GNOME
[11:34] <robertj> that's why i'm against My Documents, My Music, My Whatever.
[11:34] <seb128> robertj: you will not get any consensus on a such discussion imho
[11:35] <seb128> that's basically why I've not replied to the thread
[11:35] <robertj> Yeah, probably not. But it's a better way of doing things than having every application want to have itself on your panel and such.
[11:35] <paolo> seb128, thanks.  OK works seamlessy for me too.
[11:35] <seb128> you can try to go upstream, they will probably close it and maybe ping usability before
[11:36] <paolo> seb128, about cairo "--enable-gtk-doc        use gtk-doc to build documentation default=no" that's probably the reason for the lack of documentation.
[11:37] <seb128> paolo: I know why it lack it and the Debian package has a binary package for it, I just need to sync ... I'll do that after the colony CD from this week when uploading 0.9 and GTK 2.8
[11:37] <seb128> paolo: thanks anyway :)
[11:38] <mdz> shaya: still broken for me using 1.0.13 + the one-character fix
[11:38] <shaya> hmm
[11:38] <paolo> seb128, ok sorry.  Thank you, instead :-)
[11:38] <shaya> weird
[11:38] <seb128> paolo: no need to be sorry, don't worry :)
[11:38] <mdz> shaya: are you using delete=whiteout?
[11:39] <shaya> hmm
[11:39] <shaya> no
[11:39] <Kamion> BenC: it's /home/warthogs/archives/pqm@canonical.com.pub on chinstrap
[11:39] <shaya> or not specifying
[11:39] <shaya> let me see
[11:39] <shaya> hmm
[11:39] <shaya> this is funny
[11:40] <shaya> mdz: sometime since I sent that message unionfs oopsed on me :)
[11:40] <shaya> hit an assertion
[11:42] <shaya> hmm, why are perl and perl5.8.7 hardlinks to each other?
[11:42] <shaya> why is a hardlink better than a symlink (ala gcc)
[11:43] <robertj> seb128: thanks for your suggestion. I sent it upstream at # 313167
[11:43] <seb128> robertj: np
[11:46] <Kamion> shaya: makes no particular difference in that case
[11:49] <shaya> kamion: confused?
[11:49] <shaya> oh
[11:49] <shaya> perl
[11:49] <shaya> sorry, lost focus
[11:56] <kwa> join #ubuntu-motu
[11:58] <sivang> seb128: did you hear from jamesh re lpint-bonobo ? (I sent him a link so he can review)
[11:58] <seb128> no
[11:58] <seb128> but you were supposed to send a mail to me and jamesh today no?
[11:59] <sivang> I posted it on my web corner, and did it here, so I figured you'd notice (all the discussions were in this channel)
[12:00] <seb128> nop, was quite busy and my IRC is not running when I'm not around
[12:00] <seb128> I read some discussion
[12:00] <seb128> but not pointer to a patch
[12:00] <sivang> 10:19 < sivang> jamesh: ok, noted. pkg is here: http://muse.19inch.net/~sivan/lpint/lpint-bonnobo-0.0.tar.gz