[12:00] <seb128> ok ok
[12:00] <enrico> elmo: around?
[12:00] <seb128> so go with the compatibility stuff
[12:19] (lamont/#ubuntu-devel) hrm... gonna have to reboot
[12:19] (lamont/#ubuntu-devel) changing IP's will do that to you...
[12:30] <enrico> wiki login has been fixed
[12:36] <pitti> mdz: ping
[12:37] <seb128> 'night
[12:37] <jdub> night seb128
[12:37] <pitti> night seb128
[12:37] <jdub> elmo: did you see my paste above?
[12:37] <__daniel> bye seb128
[12:51] <pitti> elmo: one last upload from chinstrap, because the mysql package was already there anyway. Sorry...
[12:51] <elmo> jdub: err, yes, why is that a surprise?
[12:51] <elmo> your key isn't in the debian keyring?
[12:51] <elmo> pitti: why doesn't ftp work for you?  is it just with this server or in general?
[12:51] <pitti> elmo: it's a general problem with my ISP
[12:51] <pitti> elmo: it works, but it is sloooooooooow
[12:51] <pitti> elmo: that's why I scp it onto another host and ftp from there
[12:51] <pitti> elmo: if chinstrap is to be avoided, I can also route it through my own server
[12:51] <elmo> pitti: ok - I just want to encourage people to test out the new upload daemon - if ftp is fux0red for you, you can use chinstrap
[12:51] <jdub> elmo: boh
[12:51] <pitti> elmo: tomorrow I have some smaller packages to fix, I will test it then
[12:51] <jdub> i thought putting those in DEFAULTS would default to ubuntu
[12:51] <jdub> bong
[12:58] <pitti> night
[01:19] <doko> night
[01:22] <lamont> maybe re-iping things wasn't the best timed act of the day... :-(
[01:35] <lamont> grumble.  bounced mail.  only about 60 messages though. :-(
[02:02] <lucas_> hi
[02:02] <lucas_> somebody with some debian-cd knowledge ?
[02:02] <lucas_> I need to build iso with software from (uni|multi)verse
[02:02] <lucas_> it isn't supported, right ?
[02:03] <lucas_> am I right when I think that the easiest way to fix this is to grep for "restricted" and see what was changed to add "restricted" support ?
[02:27] <lamont> lucas_: I started with a copy of the CD, added files, replaced the Packages/Sources/Release files, and reburned the CD
[02:28] <lamont> the rune to make the ISO is "mkisofs -r -V 'Ubuntu 4.10 i386 Bin-1' -o warty-install-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table wherever-your-new-tree-is"
[02:28] <lamont> understanding what that means is left as an exercise.
[02:34] <lupus_> is discover only called on install of ubuntu?
[02:34] <lupus_> or each boot
[02:35] <jdub> only on install
[02:35] <jdub> during install
[02:38] <lupus_> why only durring install?
[02:40] <lamont> lupus_: because warty doesn't use discover.
[02:40] <lamont> well, mostly
[02:41] <elmo> hotplug is better, basically and we're migrating to it
[02:41] <elmo> +even in the installer
[02:41] <lupus_> ah so hotplug is not used in the installer at the moment
[02:41] <lupus_> only discover
[02:44] <elmo> yeah
[02:44] <elmo> tho, that's already changed in hoary
[03:00] <lupus_> so /etc/hotplug is for coldplugging and /etc/hotplug.d to have hotplugging? sorry I'm trying to understand how hardware is detected and configured
[03:03] <lupus_> nm I'm wrong :)
[03:20] <jdub> http://mail.nl.linux.org/humorix/2004-11/msg00002.html
[03:39] <lamont> jdub: heh
[03:49] <jdub> the final live cd looks brill
[03:50] (sladen/#ubuntu-devel) "final" ?
[03:50] <ironwolf> warty? yeah, it's pretty.
[03:52] <jdub> sladen: the release version, on the pretty printed cds :)
[03:52] <jdub> i didn't have the b/w to pull many live cd releases
[03:54] <lamont> ironwolf: did your order show up yet, btw?
[03:54] <ironwolf> lamont: no, only 3 days left too...
[03:55] <ironwolf> lamont: although I have had lots more local interest in them when they arrive.
[03:56] <eruin> blah, I can't rightclick files and create an archive anymore
[03:58] <jdub> vino + damage == rock!
[04:02] <lamont> well, night
[04:02] <jdub> later lamont
[04:03] <ironwolf> night lamont
[05:00] <ironwolf> lamont around?
[06:20] <fabbione> morning guys
[07:55] <fabbione> lamont: ping
[08:38] <pitti> Hi all
[08:44] <jdub> doko: woo!
[08:55] <lifeless> jdub: what were you pinging about before ?
[08:58] <jdub> don't remember :)
[08:58] <jdub> oh
[08:58] <jdub> here's something though
[08:58] <jdub> baz register-archive -> do you ever register anything other than an archive?
[08:58] <lifeless> oh, ui names ?
[08:58] <lifeless> ie baz register ?
[08:58] <jdub> yeah
[08:59] <lifeless> sounds good, chuck it in the mockup UI :)
[08:59] <pitti> ping lamont
[08:59] <jdub> lifeless: also, what do you think about splitting that page up a bit? it's getting unwieldy
[08:59] <jdub> lifeless: happy to take an initial stab at it
[08:59] <lifeless> please do
[09:03] <pitti> elmo: here?
[09:18] <jdub> doko: ping?
[09:39] <seb128> morning
[09:40] <seb128> jdub: #4092 is WONTFIX, right ?
[09:41] <jdub> yeah, atm
[09:42] <pitti> Hi seb128
[09:43] <seb128> hey pitti
[10:24] <Kamion> I really must actually upload our modified debian-cd to hoary for this release
[10:27] <fabbione> hey Kamion
[10:27] <fabbione> Kamion: kernel-wedge doesn't like symlinks :(
[10:27] <fabbione> things need to be copied in proper places for it to work
[10:28] <Kamion> can you elaborate?
[10:28] <Kamion> oh, make-links and clean
[10:28] <fabbione> sure...
[10:28] <Kamion> yeah, but dpkg-source doesn't much like symlinks in diffs either
[10:28] <Kamion> at best they'll get expanded into real files
[10:28] <fabbione> remeber we agreed on the dir structure of debian/d-i/<arch> ?
[10:28] <Kamion> so you might as well copy
[10:28] <Kamion> yes
[10:29] <fabbione> perfect.. to generate debian/control from control.stub, kernel-wedge accesses a bunch of files like modules/<arch>/
[10:29] <fabbione> the original idea was to symlink those from the top level directory
[10:29] <fabbione> but kernel-wedge just delete the symlinks
[10:29] <fabbione> so they need to be copied and removed
[10:29] <fabbione> in order to keep the top level dir clean
[10:30] <fabbione> perhaps it would be nice for kernel-wedge to understand symlinks
[10:30] <Kamion> right, but all the modules/<arch> directories are separate anyway
[10:30] <Kamion> you might as well just copy them
[10:30] <fabbione> no big deal.. just some extra cp rm work
[10:30] <fabbione> Kamion: yes.. i agree. i don't want to clutter the top level dir.
[10:30] <fabbione> since it is the top level of the kernel
[10:30] <fabbione> and still other files need to be copied per arch
[10:31] <fabbione> and this will also keep the merging easier
[10:39] <mdz> pitti: pong
[10:40] <pitti> mdz: Hi!
[10:40] <pitti> mdz: can you please take a look at the mysql USN?
[10:40] <pitti> mdz: I try to reach lamont or elmo to investigate the missing build from ppc, but as soon as this is sorted out, I can publish it
[10:40] <mdz> pitti: ok
[10:40] <mdz> pitti: you can reproduce the problem, right?  it is not just me?
[10:41] <pitti> mdz: "the problem" ==?
[10:41] <mdz> I straced it and it is not calling mlock(2)
[10:41] <mdz> pitti: gpg
[10:41] <pitti> mdz: ah
[10:41] <pitti> mdz: I followed up the bug report
[10:41] <pitti> mdz: it's a buildd problem
[10:41] <mdz> yes, very strange
[10:41] <pitti> mdz: it works fine when I build it on my machine and I investigated the cause of the problem
[10:41] <pitti> mdz: luckily the warty version was built correctly
[10:41] <mdz> I saw
[10:42] <mdz> pitti: what do you want me to look at for mysql?
[10:42] <pitti> mdz: just the USN text
[10:42] <mdz> I sent email to the list regarding the diffs
[10:42] <mdz> ok
[10:43] <fabbione> i think some buildd chroots are having problems
[10:43] <pitti> mdz: https://chinstrap.warthogs.hbd.com/~pitti/usn-mysql.txt
[10:43] <fabbione> like having too many apt entries
[10:43] <pitti> fabbione: so far I only had problems with amd64, it's my first ppc failure
[10:43] <mdz> pitti: it should note explicitly that -0837 and -0956 require an authenticated mysql user in order to exploit
[10:44] <fabbione> pitti: i noticed gdb has been built
[10:44] <fabbione> but using universe packages
[10:44] <fabbione> that means that some stuff might be actually building for mistake
[10:44] <fabbione> (talking about hoary)
[10:44] <lucas_> Hi
[10:45] <lucas_> I've always been confused by "warty-updates" vs "warty" dists on the mirror
[10:45] <lucas_> from what I understand, some updates go in "warty", but not all of them ?
[10:45] <lucas_> or is "warty" totally frozen ?
[10:45] <daniels> warty's totally frozen
[10:45] <lucas_> ok
[10:46] <pitti> mdz: fixed
[10:48] <seb128> lucas_: changes in warty are mainly security fixes
[10:48] <lucas_> those go in warty-security right ?
[10:49] <seb128> yes
[10:49] <seb128> why ?
[10:55] <mdz> lucas_: as described on the website, stable releases receive only security fixes and other critical bug fixes
[10:56] <mdz> pitti: the advisory text needs a few more changes, I will send you an updated version
[10:56] <pitti> mdz: okay, thanks
[10:57] <lucas_> yup, my question was about building warty CDs that include the security/bug fixes
[10:57] <lucas_> but I need to read more debian-cd code
[10:57] <Kamion> (I'm only limited help here because I've never actually tried doing that ...)
[10:58] <lucas_> ok, I think I'll start by building CDs based on released warty packages, ignoring updates
[11:00] <Kamion> that will certainly be easier
[11:00] <lucas_> no plans to release ubuntu 4.10r(0..n) ?
[11:00] <Kamion> don't believe so
[11:01] <lucas_> ok
[11:01] <smurfix> lucas_: not much point, with a 6-month release schedule. This isn't Debian. ;)
[11:02] <lucas_> yeah I know, I was just asking because it would have helped me a lot ;)
[11:02] <Kamion> you could investigate update-cd I guess, but that's *really* never been tested with Ubuntu
[11:02] <lucas_> ok
[11:07] <lucas_> the easiest would probably be to write a tool that would merge warty-update and warty-security inside warty
[11:07] <lucas_> so there's no need to hack debian-cd
[11:07] <lucas_> (merge in the local mirror)
[11:09] <seb128> lucas_: do you really need the security updates on the CD ?
[11:09] <lucas_> it's not high priority, but it would be better
[11:10] <lucas_> some of my "customers" don't have broadband
[11:10] <Kamion> lucas_: that's a bit scary; debian-cd *is* capable of reading multiple Packages files in general so it shouldn't be necessary
[11:10] <lucas_> don't forget grenoble != la doua ;)
[11:10] <lucas_> ok
[11:10] <seb128> lucas_:  people who have a network connection just have to download these updates, what's the security issue with people who don't have a network connection ?
[11:11] <lucas_> the problem is for people who have a network connection but not broadband
[11:11] <seb128> lucas_: bah, just wondering if a student with no connection really needs the security updates
[11:11] <seb128> lucas_: security updates already are that big ?
[11:11] <lucas_> not sure
[11:11] <lucas_> depends on what is updated ;)
[11:12] <mdz> lucas_: we have talked about producing CDs containing only security updates
[11:12] <Kamion> seb128: yes, often
[11:12] <seb128> ok
[11:12] <mdz> seb128: xfree86 has been updated, e.g.
[11:12] <seb128> right
[11:12] <mdz> lucas_: that is what I recommend that you do, if you are interested in pursuing this
[11:12] <jdub> doko: around?
[11:13] <lucas_> mdz: it might be difficult regarding my user base
[11:13] <__daniel> hai
[11:13] <lucas_> well, that's not high priority anyway
[11:14] <lucas_> bbl
[11:21] <Kamion> mdz: lucas_ is doing a single CD with a number of other modifications anyway
[11:22] <Kamion> mdz: it makes little sense for him to waste time creating a separate security update CD
[11:24] <mdz> Kamion: except that the work would be reusable
[11:25] <Kamion> sure, but it's not what his userbase wants
[11:26] <Kamion> see ubuntu-devel@
[11:26] <Kamion> there's no point trying to get reusable work out of somebody when it's not usable for them
[11:28] <Kamion> mdz: oh, if you didn't notice, I moved mozilla-browser/mozilla-psm from ship to supported yesterday
[11:28] <Kamion> there seemed to be reasonable consensus for at least that step
[11:29] <mdz> that's fine by me
[11:36] <elmo> % linda *.changes
[11:36] <elmo> Happy birthday to me!
[11:36] <elmo> I'm 3 today!
[11:36] <elmo> oh dear
[11:38] <mdz> Kamion: his userbase will eventually need to download security updates; creating an updated CD doesn't solve that problem at all
[11:38] <mdz> the security update CD approach has the clear advantage of actually working on an ongoing basis
[11:38] <Kamion> it'll be no worse than for our own CDs though
[11:39] <Kamion> I don't think he has a problem either with his userbase having to download some updates or with updating his CD every so often
[11:40] <Kamion> elmo: linda scares me
[11:40] <mdz> ok, I guess I don't understand the use case then
[11:41] <pitti> elmo: can you please look why the mysql security update did not built on ppc?
[11:44] <elmo> err, it looks like lamont disabled warty-security on the powerpc buildds by mistake
[11:44] <pitti> elmo: can you fix that or shall I wait for lamont?
[11:44] <elmo> I'll have a quick look in a bit
[11:44] <pitti> thank
[11:44] <pitti> s
[11:45] <Kamion> mdz: he's lending CDs to other students in his student union who aren't very computer-knowledgeable; he needs to remove/add some packages to provide for the students' special needs, and he needs to make some changes to the installer too
[11:45] <Kamion> mdz: the ones that can't download security updates are the ones who don't have an internet connection, so that's not such a big deal
[11:45] <Kamion> mdz: I think his rationale for updating the CD with security updates is just that he might as well, it's a nice-to-have
[11:45] <mdz> in that case, I don't see the point of bothering with security updates at all
[11:46] <mdz> ok
[11:47] <Kamion> I can certainly see the rationale; if you're going to build a CD now, it might as well be current
[11:48] <pitti> mdz: oh, have a happy holiday! :-)
[11:48] <mdz> thanks
[11:48] <pitti> mdz: thanksgiving is another opportunity to stuff one's stomach with far too much food, right?
[11:49] <mdz> correct
[11:49] <pitti> mdz: enjoy :-))
[11:49] <fabbione> hehehe
[11:56] <elmo> # list of distributions that buildd should take packages from
[11:56] <elmo> @take_from_dists = qw(stable frozen unstable);
[11:56] <elmo> *boggle*
[11:57] <Kamion> hooray for buildd
[11:57] <daniels> elmo: looks like someone installed a new w-b, heh
[11:58] <Kamion> yeesh, pciutils still has no DH_COMPAT or debian/compat? bleh
[11:58] <daniels> elmo: do you have access to the ia64 thingies?
[11:59] <elmo> daniels: blink - of course?
[11:59] <daniels> elmo: do you care to spin a build around them, or should I harass lamont when he wakes?
[12:01] <elmo> harass lamont to get debootstrap working, then I can create a hoary chroot on the port box
[12:01] <daniels> elmo: k, cheers
[12:01] <daniels> lamont: harass, harass, p.u.c/~daniels/xorg, etc
[12:02] <elmo> pitti: ok, should be fixed now
[12:02] <pitti> elmo: thanks
[12:02] <elmo> (or at least the powerpc buildds will start building things now)
[12:02] <pitti> elmo: it will automatically arrive at rookery now?
[12:02] <pitti> elmo: or must there be a trigger of some kind?
[12:02] <mdz> night, all
[12:02] <pitti> night mdz
[12:02] <seb128> 'night mdz
[12:02] <Kamion> sleep well
[12:03] <elmo> pitti: err, jackass you mean? yes
[12:03] <daniels> mdz: night
[12:03] <pitti> elmo: yes, of course. jackass
[12:04] <Mithrandir> why doesn't nautilus allow one to open a folder multiple times on multiple desktops?
[12:06] <seb128> bug ?
[12:06] <jdub> Mithrandir: you can in browse mode; spatial is spatial.
[12:06] <seb128> oh, doesn't
[12:06] <seb128> I misread
[12:06] <jdub> Mithrandir: the window *is* the folder.
[12:06] <Mithrandir> jdub: but the window is on another desktop.
[12:07] <Mithrandir> jdub: it means I have to race xpdf to make it open on the right desktop.
[12:07] <seb128> ?
[12:07] <seb128> what are you trying to open/start, and how ?
[12:07] <jdub> Mithrandir: you're saying that the window is open, and you try to open it again, but it does nothing (because it's already open on the other desktop)?
[12:08] <Mithrandir> jdub: no, it moves me to the other desktop.
[12:08] <Mithrandir> which is totally surprising.
[12:08] <seb128> it should move the window on the current one
[12:08] <Mithrandir> seb128: agreed.
[12:08] <seb128> it does here
[12:08] <Mithrandir> not here, but I'm using openbox.
[12:09] <seb128> oh, so probably an openbox bug
[12:09] <jdub> it does here too
[12:17] <pitti> elmo: $ ps aux|grep ntpd
[12:17] <pitti> ntp       2052  0.0  0.4  3516 3516 ?        SLs  12:16   0:00 ./ntpd
[12:17] <pitti> elmo: :-)
[12:19] <elmo> pitti: sweet thanks
[12:19] <gicmo> hi
[12:19] <pitti> elmo: well, it needs some tweaks (to work also on non-cap kernels and such), but it works in principle
[12:20] <daniels> elmo: so is davis fully set up to be abused?
[12:20] <elmo> pitti: next I need you to fix... ssh, cron, klogd, sylogd, postfix and getty.. kthxbye
[12:20] <elmo> ;-)
[12:20] <elmo> daniels: AFAIK, yeah
[12:20] <pitti> elmo: ssh? easy, it just could lack a _little_ functionality...
[12:20] <Kamion> *ahem*
[12:20] <pitti> elmo: btw, syslogd?
[12:21] <pitti> elmo: I fixed that yesterday
[12:21] <elmo> pitti: both syslogd and klogd?
[12:21] <pitti> elmo: no, it's impossible for klogd
[12:22] <pitti> elmo: klogd needs CAP_SYS_ADMIN, which is equivalent to root
[12:22] <pitti> elmo: the odd thing is, you cannot open /proc/kmsg as root and read from the descriptor as user
[12:22] <pitti> elmo: this works for normal files, but not for /proc/kmsg
[12:22] <pitti> elmo: with the current kernel there's nothing I can do
[12:23] <elmo> oh well.. nice for syslogd anyways
[12:23] <elmo> s/for/to get/
[12:24] <daniels> elmo: cool
[12:33] <Kamion> -rw-rw-r--    1 cjwatson cdimage  636405760 Nov 24 08:49 20041124/hoary-install-powerpc.iso
[12:33] <Kamion> -rw-rw-r--    1 cjwatson cdimage  625797120 Nov 25 08:49 20041125/hoary-install-powerpc.iso
[12:33] <Kamion> \o/
[12:34] <daniels> Kamion: congrats :)
[12:34] <daniels> Kamion: how did you shave that much off?
[12:35] <Kamion> mozilla-browser
[12:35] <daniels> ahr
[12:36] <daniels> elmo: btw, would it be possible to get access to an ia64 port box once lamont makes chroots work and stuff?
[12:36] <elmo> sure
[12:36] <elmo> I just need working debootstrap
[12:36] <Kamion> yeah, waiting on gcc-3.4
[12:37] <daniels> elmo: awesome, thanks
[12:37] <elmo> oh, ok, thought Lamont had bodged that
[12:37] <Kamion> think it's the last thing left to do
[12:37] <elmo> and why on earth do.. oh libgcc
[12:37] <Kamion> at least, it was last time I heard
[12:37] <Kamion> elmo: yeah
[12:37] <Kamion> I'm kind of refusing to do debootstrap until I can do it automatically from germinate output :-/
[12:38] <Kamion> lamont has a hacked script though I believe, if you want to ask him for it
[12:39] <elmo> no, that's fair enough
[12:39] <Kamion> anyone object to me adding pciutils-udeb to the installer seed?
[12:45] <daniels> Kamion: seems eminently sensible
[12:46] <elmo> daniels: btw, don't forget to add that fd candy to the appopriate seed
[12:46] <elmo> seb128: you too for gnome-python-extras
[12:46] <elmo> doko: and you too for zope
[12:46] <seb128> ok
[12:47] <daniels> elmo: good catch
[12:49] <Keybuk> jdub: btw. I've mailed the hotplug-ng and udevsend/udevd guys to see what they think the future should be
[12:49] <jdub> elmo, daniels: do we actually want the fd candy in any of the seeds?
[12:49] <jdub> Keybuk: rad
[12:49] <daniels> jdub: i put fdclock/xcompmgr/transset in supported
[12:50] <daniels> jdub: fdclock might be sorta kinda neat, but the compmgr is really just too slow
[12:50] <jdub> daniels: i don't think there's any reason to support them
[12:50] <Keybuk> jdub: I also sent them grepmap as a "here's the C modules.*map parser for you" :)
[12:50] <daniels> jdub: oh?
[12:51] <daniels> jdub: i think enough people will want to use them to support them
[12:51] <daniels> jdub: but not enough, and it's not general-purpose enough, to ship them per default
[12:51] <daniels> jdub: but, your call
[12:51] <elmo> yes, sorry, please remember when I say "add to the appropriate seed" there's a hidden subtext of "and get sign off for it, if you need to" :-P
[12:52] <jdub> yeah, these things should be added to the seed proposals page
[12:52] <jdub> daniels: they're not useful to support though, surely they're fine for universe
[12:53] <daniels> jdub: done
[12:53] <jdub> daniels: please put them on the proposals page though, we may come back to it
[12:54] <daniels> jdub: k
[12:56] <jdub> anyone mind if i patch out the openoffice.org kde stuff, so we can get a build?
[12:58] <daniels> oh frig, this means I need to edit the wiki
[12:59] <elmo> god I would KILL for sysklogd to use fricking logrotate
[01:01] <jdub> far out
[01:01] <jdub> 171MB
[01:02] <rburton> daniels: i hear you are off to see mallum on monday
[01:02] <daniels> rburton: i hear you are too!
[01:02] <rburton> daniels: indeed. want to meet at victoria?
[01:03] <daniels> rburton: rockin'
[01:03] <daniels> rburton: easy to get to from south ken?
[01:03] <rburton> yeah, along on the circle for a bit
[01:03] <rburton> or the district. yellow or green.
[01:03] <daniels> swoit
[01:03] <daniels> ahr, right
[01:03] <daniels> yeah
[01:04] <daniels> which means it's easy from earl's court also -- phat
[01:04] <rburton> daniels: what time were you planning on going?
[01:04] <daniels> rburton: *shrug*, whenever
[01:05] <haggai> jdub: sure.  I was thinking we're gonna have problems sometime with OOo needing GTK and KDE libs to build
[01:06] <daniels> haggai: availability isn't a huge problem, it's just that that would drag kde into main
[01:06] <haggai> jdub: I want to split some of the -dev sort of headers out and make an installable .deb from them but like everything with OOo it takes ages & ages to do
[01:06] <haggai> daniels: but that would suit KDE users ;)
[01:06] <Kamion> we could imaginably end up stripping out the KDE build-dep for Ubuntu; it wouldn't be the first package we've done that for ...
[01:07] <jdub> yeah, that's the main issue
[01:07] <fabbione> elmo: (wishlist) any eta for sparc.u.c =
[01:07] <Kamion> life will be easier once we have community maintenance for KDE
[01:07] <jdub> atm we can't build it because kdelibs4-dev isn't in universe
[01:07] <fabbione> s/=/?
[01:07] <jdub> Kamion: but that doesn't necessarily mean kde in main :)
[01:07] <haggai> is there any way we can tell if we're building for Ubuntu?  We have a lot of optional stuff in the pkgs controlled by DEB_BUILD_OPTIONS and it would be handy if we could do the same with the KDE bits too
[01:07] <_rene_> yeah, good idea
[01:07] <Kamion> haggai: nope, we just upload a *ubuntuN version
[01:08] <daniels> Kamion: is it worth setting a default DEB_BUILD_OPTIONS="ubuntu"?
[01:08] <Kamion> although having our changes integrated that way could make life easier
[01:08] <Kamion> daniels: users rebuilding our source packages won't set that
[01:08] <haggai> daniels: yeah, might be a good idea
[01:08] <daniels> Kamion: like, within dpkg-buildpackage, or /etc/environment, or something
[01:08] <elmo> fabbione: I'm trying to ping sabdfl about sparc boxes - I'd really like to know if we're going to do that first
[01:08] <Kamion> that's always the problem with DEB_BUILD_OPTIONS and similar; they can only be used for optional features, not what the buildd needs
[01:09] <Kamion> daniels: EWWW
[01:09] <daniels> Kamion: (sorry)
[01:09] <Kamion> daniels: (what if somebody wants to build the Debian source package on Ubuntu?)
[01:09] <daniels> Kamion: (good question)
[01:09] <jdub> (stop whispering)
[01:09] <Kamion> source packages pretty much have to be self-contained, unfortunately
[01:09] <daniels> Kamion: (of course, dpkg-buildpackage could only set D_B_O if the source version contained 'ubuntu' ...)
[01:09] <haggai> so what about adding some sort of DEB_BUILD_OPTIONS+=ubuntu in debian/rules?
[01:10] <haggai> (as an ubuntu-only patch)
[01:10] <Kamion> haggai: if our diff were just that one line, that'd rock
[01:10] <haggai> Kamion: that's my idea
[01:10] <rburton> daniels: meet at victoria train station, around platforms 1-8, about 11:30-40? there is a train at 11:53
[01:10] <daniels> Kamion: to every package?
[01:10] <daniels> rburton: sounds awesome
[01:10] <Kamion> not sure DEB_BUILD_OPTIONS is *quite* the right place, but anyway
[01:10] <jdub> haggai: what would the kde package have in it, if we did that?
[01:10] <_rene_> jdub: we could just disable it
[01:10] <Kamion> I think I'd prefer DEB_DISTRIBUTION or something
[01:10] <haggai> the advantage of DEB_BUILD_OPTIONS+= means you can build the ubuntu variant on Debian.. :)
[01:11] <_rene_> jdub: -Nopenoffice.org-kde etc
[01:11] <rburton> daniels: sweet. mail me your mobile so i can find you when you are lost ;)
[01:11] <daniels> rburton: heh :)
[01:11] <Kamion> yeah, just trying to avoid overloading DEB_BUILD_OPTIONS itself
[01:11] <fabbione> elmo: didn't we agree that i was going to offer "main" in an unofficial archive and that if the port will take off, we were going to buy buildd?
[01:11] <_rene_> jdub: so we could make -lde not even built
[01:11] <daniels> rburton: sent
[01:11] <Kamion> _rene_: or generate the control file
[01:11] <elmo> oh, maybe we did. blah, my brain sucks
[01:11] <Kamion> so that -kde isn't in the .dsc either
[01:11] <fabbione> elmo: because i am already building the "golden debs" for main at this stage...
[01:12] <jdub> _rene_: ahr :)
[01:12] <jdub> _rene_: handy
[01:12] <fabbione> elmo: and when they will finish i can add universe & co.
[01:12] <_rene_> jdub: we actually do that now like this with the java/nonjava flag
[01:13] <daniels> thom: kaping
[01:14] <haggai> Kamion: we actually generate the control file anyway so yeah we could take it out but I think just using -Nopenoffice.org-kde, like we do for the optional -java pkg, should be enough
[01:14] <elmo> fabbione: okay, I'll try and have a look at doing s.u.c in the next couple of days - it has to be below a few other things in my todo list tho
[01:14] <fabbione> elmo: sure... that will be more than perfect
[01:15] <_rene_> hmm. that still leaves the builddep, though ;-)
[01:15] <fabbione> elmo: when you will be ready to test the setup i will send you the gpg key for the buildd
[01:15] <fabbione> elmo: if you don't mind i want to keep them separate
[01:16] <haggai> _rene_: oh, yeah good point
[01:16] <haggai> _rene_: we can always do our trick of depending on something in the distro :)
[01:16] <haggai> _rene_: like the woody bp
[01:16] <elmo> fabbione: of course - tho, if we go ahead with the port, I think one of the things we do when we get our buildds, is rebuild the world on them ?
[01:16] <_rene_> ah, yeah
[01:16] <haggai> Build-depends: kdelibs | ubuntu-somthing
[01:16] <rburton> daniels: where did you send the mail? it's not here yet
[01:16] <_rene_> kdelibs4-dev | some-ubuntu-stuff
[01:17] <daniels> rburton<EMAIL_ADDRESS>[01:17] <jdub> haggai: oof. :)
[01:17] <rburton> daniels: ross@
[01:17] <daniels> ... which just bounced, rock on
[01:17] <_rene_> jdub: works, we did that already with woody and dpkg-dev ;-)
[01:17] <haggai> jdub: you haven't seen all our hacky^W neat stuff for our woody backport from the same OOo source? :)
[01:17] <fabbione> elmo: we can still use my "golden debs" to start with
[01:17] <jdub> haggai: i saw the 171MB download and turned back :)
[01:17] <daniels> rburton: try that
[01:17] <fabbione> elmo: there is no point in starting from scratch again
[01:18] <_rene_> jdub: heh
[01:18] <fabbione> elmo: i can already bootstrap ubuntu sparc chroots
[01:18] <haggai> jdub: ok, you failed the real h4ck3r test then
[01:18] <jdub> heh
[01:18] <fabbione> elmo: and with a bit of love we might be able to install ubuntu on them directly ;)
[01:18] <jdub> .au has lots of real hackers :)
[01:18] <jdub> we just don't ahve a lot of real bandwidth :)
[01:18] <fabbione> jdub: s/real/fake/
[01:19] <fabbione> ;)
[01:19] <daniels> we don't have much fake bandwidth, either
[01:21] <fabbione> daniels: well it was for the hackers
[01:22] <fabbione> daniels: mtools is another FTBFS from xlibs split :( i uploaded the fix.. mind to keep an eye on it?
[01:23] <daniels> fabbione: sure
[01:23] <fabbione> daniels: where is xorg crack? :P
[01:25] <daniels> fabbione: concordia has finished (like 20min ago), davis has just started -dbg, and catsby (my laptop) is meandering through
[01:25] <fabbione> davis ?
[01:25] <fabbione> ia64?
[01:25] <elmo> davis is adare
[01:25] <daniels> nope, new powerpc port box
[01:25] <elmo> er
[01:25] <fabbione> ah ok
[01:25] <daniels> adare's motd told me to use davis for chroot builds, so I did
[01:25] <elmo> davis is powerpc, it replaces adare
[01:25] <elmo> halley is the ia64 port box, but it doesn't have a hoary chroot yet
[01:26] <Kamion> haggai: something in the distro> that's really sick and twisted ;)
[01:26] <fabbione> ok
[01:26] <fabbione> thanks
[01:28] <_rene_> Kamion: you haven't seen the foo | dpkg-dev (<< something) builddeps, have you? ;-)
[01:28] <lupus_> libgnome2-common_2.8.0-5ubuntu1_all.deb the 5=debian release? and the 1=ubuntu release? or how does the versioning system work?
[01:28] <jdub> night all
[01:28] <bob2> 'night jdub
[01:28] <daniels> jdub: 'nacht
[01:29] <daniels> _rene_: oh man, that's hideous
[01:29] <_rene_> daniels: hackish, but works
[01:29] <Kamion> _rene_: I think I noticed them once and RAN AWAY SCREAMING
[01:30] <Kamion> lupus_: first Ubuntu revision on top of 2.8.0-5
[01:31] <_rene_> Kamion: :)
[01:31] <fabbione> Kamion: we need to do a really hackish thing to merge the udeb creation :(
[01:31] <Kamion> fabbione: oh?
[01:31] <fabbione> Kamion: because the install target doesn't actually install in debian/<pkgname> (that i was hoping for)
[01:31] <daniels> fabbione: what's mtools doing with libxau?!?
[01:32] <fabbione> Kamion: and later binary-arch calls make-kpkg to create the debs, that are than moved to the right place
[01:32] <Kamion> fabbione: which install target?
[01:32] <fabbione> daniels: you ask me?
[01:32] <fabbione> Kamion: then one in the top level debian/rules
[01:32] <fabbione> daniels: it FTBFS without
[01:32] <Kamion> fabbione: oh, you clearly have to run kernel-wedge after most of binary-arch is finished
[01:33] <daniels> fabbione: oh man
[01:33] <fabbione> Kamion: yep
[01:35] <fabbione> daniels:
[01:35] <fabbione> floppyd.c:28:23: X11/Xauth.h: No such file or directory
[01:35] <fabbione> floppyd.c: In function `do_auth':
[01:43] <seb128> herzi: your testcase doesn't work and I think than bastien doesn't want to debug it
[01:50] <herzi> well, it works on my machines, maybe it's locale-dependent?
[01:50] <seb128> $ ./compile.sh
[01:50] <seb128> gcc: -E required when input is from standard input
[01:50] <seb128> here
[01:51] <seb128> BTW don't bother to fix it, I've added a tarball to the BR
[01:51] <herzi> i saw that
[01:51] <herzi> it's good for non-english people to have this fixed
[01:52] <seb128> yeah
[02:11] <seb128> elmo: eog sync please
[02:11] <elmo> seb128: done
[02:11] <seb128> thanks
[02:11] <fabbione> Kamion: regarding the kernel-versions file
[02:11] <fabbione> Kamion: the last entry is the build-dep field, that we don't need anymore, since we build everything from the same source
[02:11] <fabbione> Kamion: problem is: if i leave a build-dep in there it finishes into debian/control
[02:11] <fabbione> Kamion: if i remove it kernel-wedge install-files will fail a sanity check
[02:12] <fabbione> Kamion: and i have 2 options to fix it:
[02:12] <fabbione> Kamion: a) patch kernel-wedge to be less anal in that sanity check
[02:12] <daniels> fabbione: if you want to give ubuntu4 a test run around sparc (p.u.c/~daniels/xorg), that would be cool
[02:12] <fabbione> Kamion: b) insert a fake build-dep in kernel-versions
[02:13] <fabbione> Kamion: fake as in writing for ex. tar
[02:13] <fabbione> Kamion: or something like that
[02:13] <fabbione> daniels: it would take hours to build and don't worry about sparc until there is a need for it :-)
[02:14] <fabbione> Kamion: what would you prefer?
[02:14] <fabbione> Kamion: the change in kernel-wedge would be limited to commands/install-files
[02:15] <fabbione> Kamion: the var is not even used.. just checked for len > 0
[02:15] <daniels> fabbione: heh, ok
[02:15] <daniels> fabbione: waiting on lamont for an ia64 test build anyway
[02:16] <Kamion> fabbione: uh, wait a sec, I want to look at this carefully
[02:16] <fabbione> Kamion: sure
[02:16] <Kamion> fabbione: we must not break kernel-wedge in such a way that you can't build Debian's installer on Ubuntu any more
[02:17] <fabbione> Kamion: removing the sanity check shouldn't break
[02:17] <Kamion> yeah, but it sucks
[02:17] <fabbione> otherwise we need to patch gen-control
[02:17] <fabbione> or create a gen-control-ubuntu
[02:17] <Kamion> noooo
[02:17] <Kamion> this is why I said "wait a sec"
[02:17] <fabbione> eheh
[02:17] <Kamion> let's not do random things just to hack it into working; this should be done properly
[02:18] <fabbione> i agree.. that's why i am discussing it with you :-)
[02:18] <Kamion> ok
[02:18] <Kamion> I don't see this sanity check?
[02:18] <fabbione>             ! length $builddep ) {
[02:19] <fabbione> in commands/install-files
[02:19] <Kamion> ah
[02:19] <Kamion> why not just not call gen-control?
[02:19] <Kamion> oh, no, you need it
[02:19] <fabbione> Kamion: because we need the control? ;)
[02:20] <fabbione> kernel-wedge is correct assuming that there must be a build-dep
[02:20] <fabbione> it's our merge that goes against it
[02:21] <Kamion> hmmm
[02:21] <fabbione> actually...
[02:21] <fabbione> i think the best approach would be to change gen-control
[02:21] <Kamion> I don't think I'd object to changing install-files, actually
[02:21] <Kamion> that seems the most compatible approach
[02:22] <fabbione> or create an ubuntu copy of it
[02:22] <Kamion> no
[02:22] <Kamion> no copies
[02:22] <fabbione> hmm why not?
[02:22] <fabbione> it would make merge very simple
[02:22] <Kamion> have you heard the term "clone-and-hack"?
[02:22] <fabbione> hmmm no
[02:22] <Kamion> if we copy, we do not get the benefit of bug fixes
[02:22] <Kamion> it's not a complimentary term
[02:23] <fabbione> Kamion: let me see one thing
[02:23] <Kamion> what gen-control change were you thinking of?
[02:25] <fabbione> Kamion: well on our system should not add the entry in the Build-Dep field
[02:25] <fabbione> Kamion: otherwise you will get a source that build-dep on itseld
[02:25] <fabbione> itself binaries
[02:25] <Kamion> I don't like that, I'd much rather remove the check from install-files
[02:26] <Kamion> that seems fairly harmless, looking at it
[02:26] <fabbione> Kamion: otherwise how would you feel in NOT touching the code at all
[02:26] <Kamion> especially since gen-control does not perform that sanity check
[02:26] <fabbione> and just add a fake build-dep ?
[02:26] <Kamion> nah, let's remove the check, that's better
[02:26] <fabbione> ok.. do you want to do it, or should i?
[02:27] <Kamion> no point adding fake cruft to lots of kernel-versions files
[02:27] <fabbione> hmm no
[02:27] <fabbione> it's only on one line
[02:27] <Kamion> I've got the change here, will upload
[02:27] <fabbione> the Build-Dep
[02:27] <fabbione> ok thanks
[02:27] <Kamion> per-arch, remember
[02:27] <fabbione> not in this case
[02:27] <fabbione> it will add it to linux-source
[02:27] <fabbione> but ok...
[02:28] <fabbione> the change to the code is ok with me :-)
[02:28] <Kamion> um, you still have multiple kernel-versions files surely?
[02:28] <Kamion> I mean, you have to
[02:28] <fabbione> yes, but the gen-control changes only the Build-Dep to add the ones listed in kernel-versions
[02:28] <fabbione> anyway it's ok the change to the code :-)
[02:29] <Kamion> right, but if you were adding a fake build-dep you'd have to do that on every kernel-versions line; that's where the check was being applied
[02:29] <fabbione> oh yes
[02:29] <fabbione> i misunderstood you before :-)
[02:29] <Kamion> I'll talk to joeyh next time I remember, see if this can go upstream
[02:30] <fabbione> good idea
[02:30] <Kamion> uploaded, thanks
[02:30] <fabbione> thanks to you :-)
[02:30] <fabbione> i think i can give you the first -17 -> -18 interdiff tomorrow to create debs...
[02:31] <fabbione> tho there is still the versioning problem that i need evaluate
[02:31] <fabbione> if we are going to create newer or older udebs
[02:31] <Kamion> cooooooool
[02:31] <Kamion> udebs don't have an upgrade problem technically, but katie may hate you
[02:31] <fabbione> Kamion: i am taking my time to be as less intrusive as possible
[02:32] <fabbione> even if i don't fully understand the reason of this merge :-)))
[02:32] <Kamion> wouldn't it be a much newer version by default?
[02:32] <fabbione> imho it will make user's life more complicate with a bunch of extra kernel updates, only to change udebs
[02:32] <fabbione> Kamion: i didn't check.. i just had the flash while talking with you 3 seconds ago
[02:32] <Kamion> it's basically so that a kernel upgrade doesn't involve "build linux-source-<IP_ADDRESS>, wait, get Kamion to build linux-kernel-di-* so that the changes propagate to the installer"
[02:33] <fabbione> Kamion: yes.. i grok that :-)
[02:33] <Kamion> which can be important when we're doing stuff in a hurry, and mdz wants it for security uploads
[02:33] <fabbione> but on the other side
[02:33] <fabbione> "hey another kernel upgrade to fix the usb udev" ;)
[02:34] <Kamion> yep; I kind of regard that as "unlucky for running a development release"
[02:34] <Kamion> it'll be easier once our kernel package is in arch
[02:34] <fabbione> oh yeah...
[02:34] <fabbione> ehhehe
[02:34] <Kamion> then I can commit as I do stuff rather than uploading for every change
[02:36] <fabbione> linux-source-<IP_ADDRESS>-<IP_ADDRESS>$ kernel-wedge install-files
[02:36] <fabbione>         kernel-wedge copy-modules <IP_ADDRESS>-3 386 <IP_ADDRESS>-3-386
[02:36] <fabbione>         kernel-wedge copy-firmware <IP_ADDRESS>-3 386 <IP_ADDRESS>-3-386
[02:36] <fabbione>         kernel-wedge find-dups <IP_ADDRESS>-3-386
[02:36] <fabbione> fabbione@gordian:/usr/src/wartydevel/kernel/linux-source-<IP_ADDRESS>-<IP_ADDRESS>$
[02:36] <fabbione> sweet :-)
[02:36] <Kamion> bonus :)
[02:36] <fabbione> let see what it did :-)
[02:36] <fabbione> impressing
[02:37] <fabbione> it's working :-)
[02:37] <fabbione> Kamion: probably later this evening...
[02:37] <fabbione> i was expecting more problems
[02:37] <Kamion> nifty, nice work
[02:42] <fabbione> xfs-modules-<IP_ADDRESS>-3-386-di_<IP_ADDRESS>-18_i386.udeb
[02:42] <fabbione> it almost work :-)
[02:43] <Kamion> that looks ok ...
[02:44] <fabbione> Kamion: yes.. all the udebs are ok...
[02:45] <fabbione> the debs aren't
[02:45] <fabbione> but it should be easy to do it nice and clean
[03:14] <zul> gday
[03:16] <pitti> die, evil ntp root privileges, die!
[03:16] <tseng> mmm, openntpd
[03:17] <tseng> privelage seperation + no listening by default
[03:17] <pitti> tseng: I just uploaded a new ntp package which lets ntpd run as normal user
[03:17] <tseng> mm, nice.
[03:17] <elmo> by day, pitti is just another programmer - but by night he turns into the DEROOTER - a shadowy figure fighting the wars others fear to wage, rooting out (har har) evildoers who retain priviledges they don't deserve
[03:19] <pitti> tseng: the funny thing is that it took me about half an hour to fix the code, and about one and a half to fix the broken init script handling
[03:19] <tseng> ew
[03:19] <smurfix> pitti: *sigh* yet more work for me.
[03:19] <tseng> so it now starts as root and drops?
[03:20] <fabbione> lol
[03:20] <pitti> smurfix: why, are you the Debian NTP team?
[03:20] <pitti> tseng: yes, it drops to ntp:ntp and only keeps CAP_SYS_TIME
[03:20] <smurfix> not quite "the", bu close.
[03:20] <fabbione> pitti: yes he is
[03:20] <tseng> great.
[03:20] <fabbione> smurfix: btw.. that mail about evdev
[03:20] <pitti> tseng: the code already kind of supported that, it just needed some tweaking
[03:20] <fabbione> smurfix: please discuss it either in ubuntu-devel or debian-x
[03:20] <pitti> tseng: the hard part was to get a smooth transition on package upgrading
[03:21] <fabbione> smurfix: i don't maintain X in ubuntu anymore :-D
[03:21] <smurfix> fabbione: OK
[03:21] <fabbione> smurfix: can't you see the difference yet?
[03:21] <fabbione> no caps lock..
[03:21] <fabbione> no irritation to my skin
[03:21] <sivang> fabbione : who is ?
[03:21] <sivang> :)
[03:21] <fabbione> i don't wake up yelling at the elfloader
[03:22] <fabbione> sivang: daniel the kid
[03:22] <smurfix> fabbione: the relevant changhelog entry was yours, though, so I thought maybe you'd feel responsible. ;-)
[03:22] <fabbione> smurfix: i did only one change to make it more flexible for certain corner cases
[03:22] <fabbione> smurfix: not as default protocol
[03:22] <fabbione> but you can discuss it
[03:23] <fabbione> with enough arguments you can convince daniels
[03:34] <pitti> smurfix: I sent the patch as a wishlist bug. Have fun with it :-)
[03:35] <smurfix> pitti: thanks. I guess. ;-)
[03:36] <Kamion> smurfix: one-handed typing> I don't want to know
[03:37] <smurfix> Kamion: read my blog... (or not)
[03:42] <daniels> smurfix: so!  evdev as default, eh?  sell me.
[03:44] <smurfix> daniels: (a) I like the ability to actually use the multiple buttons on mine.
[03:45] <daniels> smurfix: er, most people have working multi-button mice without evdev (by 'most people', I mean 'everyone not running Apple hardware')
[03:45] <smurfix> multi := >3
[03:47] <Kamion> smurfix: ouch :(
[03:47] <smurfix> my lowly Explorer has five and I didn't even have to configure $BROWSER to use the additional ones as back+forward
[03:47] <smurfix> Kamion: my thoughts exactly.
[03:47] <smurfix> Kamion: I thought you didn't want to know :-/
[03:50] <daniels> smurfix: so change to ExplorerPS/2
[03:50] <fabbione> daniels: evdev seems to autodetect that
[03:51] <fabbione> [debian-ntp]  Bug#282941: ntp-server: Please run ntpd as non-root
[03:51] <smurfix> daniels: why ask the poor user what mouse protocol he should use on his USB bus?
[03:51] <fabbione> tsk :-)
[03:52] <daniels> smurfix: yeah, I dunno whether it's safe for standard ImPS/2 or not; if it is, I'll make it the default
[03:52] <daniels> smurfix: unfortunately all I have here is my laptop, but if you want to do some research, it would be hugely appreciated (feel free to open a bug in Bugzilla, assigned to<EMAIL_ADDRESS>status NEEDINFO)
[03:53] <daniels> smurfix: and yeah, I agree that asking a question like that is tremendously shit
[03:53] <smurfix> daniels: OK, will do.
[03:53] <daniels> cheers
[03:59] <smurfix> daniels: #4106
[04:00] <daniels> smurfix: thanks
[04:27] <fabbione> Kamion: testing a full build now :-)
[04:31] <fabbione> ccache orgy :-)
[04:43] <daniels> http://gstreamer.freedesktop.org/releases/gst-plugins/0.8.6.html <- polypaudio support
[04:44] <seb128> they have finally release 0.8.6 ?
[04:44] <daniels> yahuh
[04:45] <daniels> to be fair, they were blocked for about four or five days on fd.o
[04:46] <lifeless> rock
[04:47] <elmo> have polypaudio's problems been resolved?
[04:47] <daniels> elmo: not sure, but I would assume lack of a GStreamer sink would be one of them ...
[04:48] <daniels> fabbione: eh papa
[04:50] <fabbione> daniels: yes kid?
[04:51] <daniels> fabbione: wanna test the new nvidia packages?
[04:51] <daniels> fabbione: actually, wait until I merge the AGP patch -- nevermind
[04:51] <azeem> daniels: polypaudio can be transparently used as esound sink, no?
[04:51] <fabbione> daniels: not right now.. i am building a kernel package
[04:51] <azeem> now, a GStreamer source is something different, but AFAIK polypaudio handles that somehow as well
[04:52] <fabbione> UltraSPARC IV <- this is not supported by linux
[04:52] <fabbione> ops
[04:52] <daniels> azeem: unsure
[04:52] <daniels> fabbione: k
[04:56] <lamont> daniels: that died quickly yesterday...
[04:56] <fabbione> hey lamont
[04:56] <lamont> (xort that is)
[04:56] <fabbione> lamont: the chroots that are building hoary/main are broken
[04:57] <fabbione> lamont: they manage to build gdb that build-dep on type-handling
[04:57] <fabbione> that is in universe
[04:58] <fabbione> lamont: btw.. good morning :-p
[04:58] <lamont> fabbione: is this a new gdb upload?
[04:58] <elmo> drow used type-handling?!
[04:58] <fabbione> lamont: it's a sync from debian
[04:59] <fabbione> E: Couldn't find package type-handling
[04:59] <elmo> dear god, what is the world coming to
[05:00] <daniels> lamont: yeah, there's a new one up there today
[05:00] <daniels> lamont: i told you you had to delete 000_stolen_from_fedora.diff :)
[05:00] <lamont> fabbione: gdb 6.3-4 predates the fix
[05:01] <lamont> daniels: missed that.  I can just regrab?
[05:01] <daniels> elmo: what does type-handling even do?
[05:01] <daniels> lamont: yah, same source version, lasted through clean builds on i386/powerpc/amd64
[05:01] <daniels> (in reverse order of speed to compltee)
[05:01] <fabbione> lamont: ok
[05:01] <fabbione> lamont: thanks for checking
[05:04] <lamont> daniels: build running
[05:05] <daniels> lamont: thanks dude
[05:05] <lamont> fabbione: there was a bug in the ogre-model implementation.  damn perl.
[05:05] <lamont> (fixed 23 nov)
[05:10] <fabbione> lamont: ogre-model?
[05:12] <Kamion> fabbione: seen Shrek?
[05:12] <fabbione> yes
[05:12] <Kamion> onions
[05:12] <fabbione> but i have seen it in italians
[05:12] <fabbione> ah ok
[05:13] <fabbione> so ogre-models is like onions and orks.. they have layers :P
[05:13] <lamont> fabbione: that, and it's smelly
[05:13] <fabbione> ehhe
[05:14] <daniels> elmo: could I please get linux-restricted-modules build-deps on concordia?
[05:19] <elmo> daniels: done
[05:19] <daniels> elmo: cheers
[05:20] <daniels> shitting hell, the l-r-m build goes into an infinite loop if it fails
[05:20] <thom>  "From: psychoelmo<EMAIL_ADDRESS>*giggle*
[05:20] <thom> elmo: is that your pseudonym these days?
[05:20] <daniels> heh
[05:21] <lamont> Applying patch
[05:21] <lamont> +debian/patches/024_ati_r128_and_radeon_enable_build_without_vgahw.diff ...
[05:21] <lamont> +failed! (check
[05:21] <lamont> +stampdir/log/patches/024_ati_r128_and_radeon_enable_build_without_vgahw.diff
[05:21] <lamont> +for reason)
[05:21] <fabbione> why am i not surprised?
[05:21] <fabbione> daniels: let me guess
[05:21] <zul> its ati...go figure
[05:21] <fabbione> you renamed 020 to 025
[05:22] <fabbione> and not done a patch-audit
[05:22] <daniels> fabbione: dude, ease off it, will you?
[05:22] <fabbione> daniels: tell me if i am right or not..
[05:22] <fabbione> ;)
[05:22] <lamont> 8 out of 12 hunks FAILED -- saving rejects to file xc/programs/Xserver/hw/xfree8
[05:22] <lamont> 6/drivers/ati/radeon_driver.c.rej
[05:23] <lamont> elmo: elilo-installer/ia64 needs some unknown-love.
[05:23] <daniels> that's exactly what I copied to concordia and davis
[05:23] <daniels> fabbione: actually, you're wrong
[05:26] <fabbione> daniels: good :-)
[05:27] <fabbione> daniels: if what you have around is the same as what is in baz, here they all apply ok
[05:28] <daniels> fabbione: yeah, that one had to be updated because benh's patch lets you configure vgahw or not at runtime also
[05:28] <daniels> fabbione: so presumably after I did it, I copied to concordia and davis, but not rookery
[05:29] <fabbione> daniels: can you give the changelog some love before uploading please?
[05:30] <eruin> what's herbert xu's nick?
[05:30] <daniels> eruin: he doesn't IRC
[05:30] <thom> he doesn't use irc afaik
[05:30] <fabbione> eruin: afaik he doesn't irc
[05:30] <daniels> fabbione: it's not final, more stuff will change before then
[05:30] <eruin> crap, and I wanted to whine about nvidia6629 ;)
[05:31] <daniels> apparently 6629 is known broken
[05:31] <daniels> (says the man who doesn't own any nvidia hardware)
[05:31] <eruin> hmm, gotta google that.. they work fine here
[05:32] <fabbione> eruin: the problem seems to affect certain AGP busses
[05:32] <daniels> eruin: there's a patch on some forums somewhere supplied by an nvidia dude that I'm testing
[05:32] <fabbione> in specific conditions
[05:32] <fabbione> eruin: that makes it no no for us
[05:32] <daniels> 'testing' -> 'beating at until the package builds with it, then releasing to suck^Wtesters'
[05:32] <eruin> :D
[05:33] <lamont> hrm.. thumb cuffs for $6.99...
[05:33] <eruin> owell, as long as I have these alienified ooo1.9 debs installed 'm happy
[05:35] <_rene_> erm, you don't need to installl alienated debs when there are "normal" debs...
[05:35] <eruin> of 1.9?
[05:35] <_rene_> yes
[05:35] <eruin> and where might those be?
[05:35] <daniels> lamont: ...
[05:36] <_rene_> eruin: read debian-openoffice
[05:36] <lamont> it's a fun catalog, you see..
[05:36] <_rene_> eruin: http://lists.debian.org/debian-openoffice/2004/11/msg00216.html
[05:37] <shaya> how is one supposed to use smbmount if it cant be suid root?
[05:37] <shaya> used to always just smbmount as a regular user
[05:38] <eruin> _rene_: ah, yeah, I'm using those.. synaptic dupes them "alienated"
[05:38] <_rene_> ah. probably because you installed them with dpkg -i etc
[05:39] <eruin> what's the diff between java and nonjava?
[05:39] <haggai> eruin: the nonjava is a build without java support
[05:39] <_rene_> the java one ist built with java support, the other one is without ;-)
[05:39] <eruin> okay, I was foolishly thinking gtk
[05:40] <rburton> has oo.o 1.9 got anything really cool?
[05:41] <eruin> somehow the ooo1.9 I have on my fedora partition blend in with the rest of my gnome desktop, whereas these don't
[05:41] <eruin> well, .oot support
[05:41] <eruin> :)
[05:41] <rburton> .oot?
[05:41] <_rene_> the new file format :)
[05:41] <eruin> the new default format
[05:41] <rburton> ah
[05:42] <haggai> eruin: that's because I didn't enable the gtk or kde plugins yet
[05:42] <tseng> 1.1.3 is being built for hoary now
[05:42] <tseng> which has some of the visual improvements
[05:42] <eruin> all my old docs from my windows days are in .oot, that's why I need it :)
[05:42] <eruin> tseng: no oot support I suppose?
[05:42] <_rene_> err? this must be a different oot?
[05:42] <tseng> not afaik
[05:42] <haggai> what is oot?
[05:43] <_rene_> the new OASIS format
[05:43] <haggai> ah, yeah
[05:43] <eruin> _rene_: nah, I used an ooo1.9 release there too
[05:43] <_rene_> ah
[05:43] <_rene_> ok
[05:43] <haggai> eruin: oot format is scheduled for 1.1.5 I believe
[05:43] <azeem> "old docs from my windows days" <- IT landscape is moving fast these days, huh?
[05:43] <_rene_> tseng: there are rumours 1.1.5 will have backported support for OASIS
[05:45] <eruin> what does ooo use anyway? for the interface I mean
[05:45] <tseng> it has its own toolkit
[05:45] <_rene_> an own toolkit
[05:45] <tseng> its just being modified recently to emulate native toolkits
[05:46] <eruin> yeah, .56 milestone seemed to do that, while the one I'm running, .62 looks butt-ugly ;)
[05:47] <_rene_> you have to enable it during configure
[05:47] <_rene_> and the resulting stuff then of course is linked against gtk and kde/qt...
[05:47] <eruin> damn me for using those debs then
[05:48] <_rene_> tose debs in  no way have the usual quality. they are just made from a stock upstream build ;)
[05:48] <eruin> time to lobby the maintainer ;>
[05:48] <_rene_> erm? you are talking with them atm...
[05:49] <eruin> eek
[05:49] <eruin> you do the ones at ~halls/ ?
[05:49] <_rene_> haggai does
[05:50] <eruin> oooh haggaaii?
[05:50] <shaya> cant let security get in my way
[05:55] <haggai> eruin: as I said in the mail, it was a first cut and there's lots to improve on
[05:55] <haggai> eruin: I was just happy to have any .debs at all.. and many people asked for them so I put them up as they were
[05:56] <haggai> eruin: I'll turn on the gtk & kde interfaces for my next build, ok?
[05:56] <shaya> haggai: debs of what?
[05:56] <eruin> haggai: that'd be great! :)
[05:56] <haggai> shaya: openoffice 1.9.62
[05:56] <shaya> open office
[05:56] <shaya> aren't there gtk/kde interfaces in debian already?
[05:56] <eruin> for 1.1
[05:56] <haggai> shaya: we're talking about 1.9.x
[05:57] <_rene_> shaya: if you count experimental.. ;)
[06:01] <daniels> pitti: ah, dude!  want to test out a new radeon_drv?
[06:01] <daniels> thom: what sort of machine is your radeon in?
[06:01] <pitti> daniels: sure
[06:01] <thom> daniels: amd64
[06:02] <pitti> daniels: can you please mail it to me?
[06:02] <daniels> pitti: jah
[06:02] <pitti> daniels: I'm in a hurry, gotta go soon
[06:02] <daniels> pitti: sure thing
[06:02] <daniels> thom: dvi, yeah?  did it Just Work beforehand?
[06:02] <pitti> daniels: fixed the vga out?
[06:02] <daniels> pitti: hopefully!
[06:03] <daniels> thom: if you wouldn't mind giving http://people.ubuntu.com/~daniels/xorg/amd64-radeon_drv.o a spin, that'd be rad
[06:03] <tseng> daniels: whats different about it?
[06:03] <tseng> daniels: ill give it a try.
[06:04] <tseng> oh sorry.. missed the 64.
[06:04] <daniels> tseng: lots of fixups from benh
[06:04] <daniels> tseng: http://people.ubuntu.com/~daniels/xorg/i386-radeon_drv.o
[06:04] <daniels> basically, with a bare-bones (i.e. no special options) config file, every single configuration should be detected
[06:04] <shaya> daniels: what's in there?
[06:04] <tseng> mm, nice.
[06:05] <daniels> shaya: basically, you shouldn't ever need to specify any wacky options
[06:05] <daniels> every display you have connected should just come up and work
[06:05] <shaya> daniels: faster/slower or just options?
[06:05] <tseng> ill test on laptop w/ crt
[06:05] <daniels> shaya: just options, no optimisations iirc
[06:05] <tseng> and no layout options
[06:05] <shaya> oh well
[06:05] <daniels> http://people.ubuntu.com/~daniels/xorg/xorg_6.8.1-1ubuntu4_source.changes <- changelog
[06:06] <daniels> it's the 'break benh's radeon_drv challenge'
[06:07] <thom> brb, hopefully
[06:07] <tseng> daniels: works for me
[06:07] <tseng> w/o monitor_layout
[06:08] <daniels> tseng: :D
[06:08] <tseng> before it would mess up the top edge of the screen on the CRT
[06:09] <daniels> rooooooockin
[06:10] <tseng> unrelated X question
[06:10] <tseng> when i do something with direct rendering, like playing a dvd
[06:10] <tseng> it doesnt show up on the crt
[06:10] <tseng> can i config-fu something?
[06:10] <daniels> right, you need to set the overlay to the other crtc
[06:10] <daniels> hold on a sec
[06:11] <daniels> try Option "MergedFB"
[06:12] <tseng> i tried that once and got crap
[06:12] <daniels> is it any better now? ;)
[06:12] <tseng> funny rainbow colors and no X
[06:12] <daniels> heh
[06:13] <smurfix> daniels: I'll try the thing too, I need to reboot anyway
[06:13] <tseng> Option "MergedFB"   "true"
[06:14] <tseng> no hung X, but no video on crt either
[06:14] <daniels> so you just get a colourkey, or blank?
[06:15] <tseng> black square in totem
[06:15] <thom> daniels: close, but no cigar
[06:15] <daniels> thom: oh?
[06:16] <daniels> tseng: hm
[06:16] <thom> oh, hrm
[06:16] <fabbione> Kamion. IT WORKS ! IT WORKS!.. at least.. it builds fine...
[06:16] <thom> maybe i should specify some options for the second head
[06:16] <thom> like res and xinerama?
[06:16] <daniels> tseng: i suspect the only way you'll get it is with Xinerama + MergedFB, and moving the video on the second head
[06:17] <daniels> tseng: of course, we could write a tiny utility to just set OV0_CRTC_SEL
[06:17] <tseng> hm
[06:17] <daniels> thom: probably, if they're different resolutions
[06:17] <daniels> thom: if you select a res which both heads are capable of, it should work tho
[06:17] <daniels> thom: mergedfb may be a plus here
[06:18] <Kamion> fabbione: hooray
[06:19] <fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/linux-source-<IP_ADDRESS>_<IP_ADDRESS>-18_i386.changes
[06:19] <fabbione> i just need to add one entry in the changelog
[06:19] <fabbione> and you to test on ppc
[06:19] <Kamion> guess I can kiss goodbye to my CPU time for a time
[06:19] <Kamion> a bit
[06:19] <fabbione> i386 is easy because it has only one kernel image used for d-i
[06:19] <fabbione> Kamion: run it at night
[06:20] <Kamion> fabbione: do I get the source as well as the .changes? :)
[06:21] <elmo> kamion: you can't reconstruct the .diff.gz from the md5sum?? lamer
[06:21] <Kamion> oh yeah, I forgot I could trivially crack any md5sum-signing scheme, silly me
[06:22] <fabbione> Kamion: yeah hold on :-)) i am preparing an interdiff
[06:22] <fabbione> start getting -17
[06:25] <fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/17_to_18.diff
[06:25] <fabbione> the patch is big due to importing all the d-i stuff
[06:26] <fabbione> but the changes to the relevant files are contained
[06:31] <Kamion> fabbione: is ignoring errors from kernel-wedge check a good idea?
[06:31] <Kamion> I'd rather the build failed if that breaks
[06:32] <fabbione> Kamion: it breaks on unrelated packages like linux-headers
[06:32] <fabbione> because they are sometimes empty
[06:32] <fabbione> and kernel-wedge bitches about it
[06:32] <Kamion> heartbeat?
[06:32] <Kamion> hm, should just fix kernel-wedge for that
[06:32] <Kamion> but ok, later stage
[06:33] <fabbione> Kamion: yeah... reading the patch... driving you crazy... dieing slowly in front of your pc :P
[06:34] <Kamion> heh
[06:35] <Kamion> fabbione: I'm not sure shipping debian/control in its current condition is a good plan
[06:35] <Kamion> lots of i386-specific generated stuff in it
[06:37] <fabbione> Kamion: debian/control is regenerated everytime from control.stub
[06:37] <fabbione> if you were building it from amd64 or ppc would have been the otherway around
[06:37] <Kamion> yeah, I know that
[06:38] <Kamion> I think it might be better to save the ungenerated version
[06:38] <Kamion> and restore it in clean
[06:38] <Kamion> anyway, building
[06:38] <fabbione> i did use the same way as -di- but yes it can be done
[06:38] <fabbione> that's also why i call debian/control also in clean
[06:39] <fabbione> so it gets updated immediatly
[06:39] <fabbione> Kamion: have fun :-)
[06:40] <fabbione> i am off for today
[06:42] <smurfix> daniels: the radeonfb from ~daniels/xorg/i386-radeon_drv.o still kills my monitor
[06:43] <daniels> smurfix: hmmmmm
[06:44] <daniels> smurfix: what setup are you running?
[06:45] <smurfix> daniels: radeon 9600, one TFT display on its digital output.
[06:47] <smurfix> Putting it on analog gets me a "you exceed my timing parameters, go away" display instead of a "I'm told to shut down so I'll go away" message on the TFT.
[06:48] <smurfix> lspci -n:
[06:48] <smurfix> 0000:01:00.0 0300: 1002:4150
[06:48] <smurfix> 0000:01:00.1 0380: 1002:4170
[06:50] <daniels> smurfix: so plugging it into your VGA port breaks, but plugging it into your DVI port works?
[06:50] <smurfix> No, both break
[06:50] <smurfix> just differently.
[06:51] <daniels> does commenting out your HorizSync/VertRefresh lines, and commenting out the Option "DPMS" line, in the Monitor section, have any effect?
[06:53] <smurfix> daniels: I'll try ...
[06:54] <Mitario> hullo everyone
[06:56] <eruin> would any of you have a script to recursively print md5sums of a directory to a text file
[06:56] <daniels> eruin: touch foo && for i in $(find ./ -type f); do md5sum $i >> foo; done
[06:57] <eruin> thankyou :)
[06:59] <Keybuk> daniels: find . -type f | xargs md5sum > foo
[06:59] <daniels> Keybuk: meh
[07:02] <eruin> man I need to man find
[07:05] <eruin> daniels: can I ask you for another one? the find pattern to match all *~ files ? :P
[07:06] <tseng> -iname *~ ?
[07:06] <smurfix> daniels: nope
[07:07] <smurfix> daniels: same result. I can send you the xorg.log if that'd help.
[07:07] <eruin> tseng: cheers ;)
[07:10] <Kamion> fabbione: yeah, linux-kernel-di-* is different because it's only one architecture per source package
[07:11] <Kamion> tseng: just -name will do there
[07:11] <tseng> ya
[07:11] <tseng> i always use -iname out of habit
[07:22] <daniels> fabbione: have you got a link to the agp problems?
[07:22] <daniels> smurfix: er yeah, thanks
[07:22] <spotter> is there a good reason why pgp4pine is in multiverse, but pine isn't?
[07:22] <smurfix> daniels: daniel.stone@canonical ?
[07:27] <daniels> smurfix: yah
[07:28] <smurfix> daniels: sent.
[07:28] <daniels> ta
[07:33] <daniels> smurfix: try removing the HorizSync and VertRefresh lines
[07:33] <daniels> if that fails, remove the DPMS line
[07:33] <daniels> (all Section "Monitor")
[07:35] <smurfix> daniels: you're looking at the wrong Monitors section
[07:35] <smurfix> daniels: you want the one named "Test"
[07:35] <smurfix> daniels: iow, they already are commented off
[07:38] <daniels> smurfix: bah
[07:38] <daniels> what about if you take out all the custom modelines?
[07:40] <RubenV> is there an ubuntu specific anacron maintainer?
[07:40] <smurfix> I can do that. They did work a few months ago, so I kinda doubt that'll change anything. But I'll try.
[07:40] <bob2> RubenV: no
[07:40] <RubenV> i've just made a quick patch to add lsb functions to the init script
[07:40] <daniels> smurfix: so was it working right before you upgraded radeon_drv?
[07:40] <bob2> RubenV: send it to debian's bts
[07:41] <Kamion> bob2: no, don't
[07:41] <Kamion> RubenV: lsb functions are Ubuntu-specific, please file them in our BTS
[07:41] <RubenV> bob2: do they accept those?
[07:41] <RubenV> thought so
[07:41] <RubenV> ok, coming up
[07:41] <RubenV> it's just a quick fix though
[07:41] <bob2> oh, oops, the lsb pretty printing thing
[07:42] <smurfix> I was working up until ~three months ago, with the xfree that's no longer in Sarge either.
[07:42] <eruin> find relies on having an uptodate db
[07:43] <smurfix> daniels: s/I/It
[07:43] <eruin> ?
[07:43] <daniels> smurfix: with XFree86 4.2.1?
[07:43] <RubenV> hmmm
[07:43] <RubenV> no anacron module?
[07:43] <RubenV> i'll just put it under cron then
[07:44] <smurfix> daniels: probably. I didn't actually reboot for a long time and then was way too busy to reboot the system all the time to narrow the problem down. :-/
[07:44] <daniels> smurfix: could you please email the log from a working setup (preferably one with CRT, one with TFT) to<EMAIL_ADDRESS>complete with your config and a quick description of the problem, and mention that it's broken both with 6.8.1's radeon_drv, and the patch that he sent me last night?  cc me as well please
[07:44] <daniels> smurfix: heh
[07:44] <daniels> smurfix: well, if you could get an email off, that would be great
[07:45] <smurfix> daniels: yeah, I'll have to dig up an older xfree from Snapshots and all that, but apparently there's no fucking way around doing the work. :-/
[07:45] <smurfix> (so what else is new)
[07:46] <daniels> smurfix: yeah
[07:46] <daniels> smurfix: oh, for the email, he doesn't need a working log -- just a broken one should be sufficient
[07:46] <RubenV> https://bugzilla.ubuntu.com/show_bug.cgi?id=4118
[07:46] <RubenV> gonna be cleaning up some more init scripts
[07:46] <RubenV> just to contribute something
[07:47] <smurfix> daniels: OK, that does limit the effort somewhat ;-)
[07:52] <Kamion> RubenV: don't put it under cron please
[07:52] <Kamion> RubenV: if there's no appropriate package, use UNKNOWN
[07:52] <smurfix> galeon is broken in hoary. It's linked to nautilus.so.2 which the latest update renamed to nautilus-private. :-/
[07:52] <RubenV> Kamion: aw, sry, too late :s
[07:52] <smurfix> s/nautilus/libnautilus/g
[07:53] <Kamion> RubenV: reassigned
[07:53] <RubenV> doing the alsa script now
[07:53] <RubenV> that does have a pkg :)
[08:15] <RubenV> voila, no more ugly starting ALSA
[08:15] <RubenV> and now it's time for some studying
[08:23] <__daniel> hai
[08:34] <Mithrandir> thom: I think I found a bug in apache.  wrt multiviews.
[08:44] <azeem> in theory, I could go an sell Ubuntu-CDs via the web, right?
[08:45] <tseng> sure
[08:45] <RubenV> as long as you obey the gpl
[08:45] <RubenV> i think :)
[08:45] <zul> he isnt modifying or removing the license
[08:46] <bob2> yes, but he is distributing gpl code
[08:46] <zul> oh yeah..duh
[08:48] <tseng> ew @ openoffice 1.1.3
[08:49] <RubenV> ?
[08:49] <tseng> fails on missing kdelibs4-dev
[08:49] <_rene_> hehe
[08:49] <_rene_> we had that discussion this afternoon
[08:50] <__daniel> OOo depends on kdelibs?
[08:50] <_rene_> openoffice.org-kde does
[08:50] <_rene_> and so the source build-deps on kdelibs4-dev
[09:09] <Md> I'm trying to understand how udev-udeb is being used. I see no init script in the package and no postinst to create the rules. who knows more?
[09:10] <Md> I can't remember Colin Watson's nick
[09:10] <Kamion> Md: that's me
[09:10] <Kamion> Md: it's all still in development and wildly unsuitable for sarge, which is why I haven't sent the patches back yet
[09:10] <Kamion> Md: rootskel does all the init work
[09:11] <Md> Kamion: I started merging some parts of it, feel free to send any kind of patches or comments
[09:11] <Kamion> ok, fair enough, but I think it would be a good idea to keep it out of sarge; I'm scared what would happen if udev-udeb showed up in the debian-installer Packages file
[09:11] <Astharot> hi Md :)
[09:11] <Kamion> something might decide to install it :)
[09:12] <Md> BTW, you don't need -pudev for dh_link because it's the default and you don't need -a for dh_installdirs because all debian/*.dirs files are always processed anyway
[09:12] <Kamion> Md: rootskel pretty much has to have control of the early init process in d-i - it's too custom
[09:12] <Kamion> Md: yeah, that's true
[09:12] <Kamion> I think I thought the former was clearer despite the default
[09:12] <Md> Kamion: yes, I'm just adding some code to debian/rules but the package will not be generated by default
[09:12] <Kamion> ok, cool
[09:12] <Kamion> at some point soon I'll be mailing debian-boot and all the affected maintainers with the work I've done
[09:13] <Md> do you have an URL for the rootskel file which deals with the rest?
[09:13] <Kamion> but I don't want to distract too much from sarge with shiny things
[09:13] <amu> do we have a kernel with benh's sleep-support for a G4 ?
[09:13] <Kamion> amu: afraid not
[09:13] <Kamion> Md:    libiw27 |       27-1 |       testing | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
[09:13] <Kamion> oopd
[09:13] <Kamion> Md: http://archive.ubuntu.com/ubuntu/pool/main/r/rootskel/rootskel_1.09ubuntu3.dsc
[09:14] <Kamion> I put it next to the existing devfs code
[09:15] <amu> Kamion: stupid question, why not?
[09:15] <Kamion> amu: no kernel maintainer for hoary right now
[09:16] <Md> Kamion: /.dev is definitely not necessary for d-i
[09:16] <daniels> amu: that's an update to 2.6.9 + the patch
[09:16] <Kamion> Md: noted, will fix
[09:16] <amu> ubuntu-ppc without sleep, is like you go undressed to bed :(
[09:16] <Kamion> I wasn't sure
[09:18] <amu> daniels: no prob with it, just woundert is there something like this atm
[09:19] <Kamion> Md: is it likely to be possible to use udev without having hotplug at all? it would be nice to be able to switch Debian over one step at a time rather than all at once
[09:20] <Md> Kamion: you need at least /sbin/hotplug. what's wrong with the rest of the program, anyway?
[09:20] <lucas_> hi
[09:20] <Kamion> switching d-i to hotplug is non-trivial; it requires an overhaul of the hardware detection architecture
[09:20] <Kamion> I'm working on it but it's not the work of five minutes
[09:21] <Md> Kamion: oh, you mean coldplugging. it's not mandatory, look at the init script to see how to disable it
[09:21] <Kamion> we could certainly install some kind of dummy /sbin/hotplug in the meantime
[09:21] <Md> Kamion: /sbin/hotplug does nothing by itself, look at it
[09:21] <Kamion> I know, I've been looking at it and friends for much of today :)
[09:22] <Kamion> it can't be called /sbin/hotplug in d-i incidentally, for annoying reasons
[09:22] <Md> like?
[09:22] <Kamion> we have to activate it only after pivot_root
[09:22] <Kamion> if you call it /sbin/hotplug then udevd gets started up in the first initrd and prevents it being unmounted
[09:23] <Kamion> I ran into that straight away
[09:23] <Kamion> so I just call it /sbin/hotplug.real instead and echo that into /proc/sys/kernel/hotplug shortly after pivot_rooting
[09:23] <Md> so don't put it in the first initrd... what am I missing? or make it just exit if everything it needs is not there
[09:24] <Kamion> you have to put it in the first initrd, or you don't get it until after the first round of hardware detection
[09:24] <Kamion> d-i has no way to install additional udebs until then
[09:25] <lucas_> Kamion: how big is a full ubuntu mirror ? debmirror is broken, so I need to get everything. but I'm not sure if it will fit on my disk.
[09:25] <Md> then I think it should be patched to exit until the environment is OK, it looks simpler
[09:25] <Kamion> how should it tell?
[09:26] <Kamion> there is no significant difference in the filesystem between before pivot_root and after, apart from /dev being populated
[09:26] <Md> [ -e /some/file ]  || exit 0
[09:26] <Md> at worst you will have to create a flag file
[09:26] <Kamion> the first initrd is copied wholesale to the ramdisk
[09:26] <Kamion> I think I prefer the current approach TBH, it's easier to understand and doesn't seem fragile
[09:27] <Md> I find easier to understand *my* approach :-)
[09:27] <Kamion> if I patch /sbin/hotplug then that patch needs to be on the real system as well - I don't want the code to differ between deb and udeb
[09:28] <Kamion> so a flag file doesn't sound like an option ...
[09:28] <Md> that's OK, I maintain hotplug and can do this :-)
[09:28] <Kamion> oh, I thought that was ukai
[09:29] <Md> I'm the co-maintainer
[09:29] <Kamion> ah
[09:30] <lucas_> ***lucas@ubuntu2:/space/ubuntu-mirror/pool$ ls -l universe/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb
[09:30] <lucas_> lrwxrwxrwx    1 lucas    lucas          72 Nov 25 13:55 universe/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb -> ../../../../pool/multiverse/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb
[09:30] <Kamion> hm, speaking of, a hook in hotplug to allow feeding back module names to whatever's calling the rc scripts would be really nice ... :-)
[09:30] <Kamion> but, looking at the code, it seems very non-trivial to add such a hook
[09:30] <lucas_> there are symlinks looping to themselves on the archive :/
[09:30] <Md> Kamion: what?
[09:30] <Kamion> lucas_: I believe something on the wiki tells you
[09:30] <Kamion> Md: look at how hw-detect interacts with discover and you'll understand
[09:31] <Kamion> Md: especially the bit that allows the user to enter module parameters for each module that's going to be loaded
[09:31] <Md> the major problem with hotplug is that it should be completely rewritten to remove all compatibility code for 2.2 and 2.4 kernels...
[09:31] <Kamion> lucas_: my warty+hoary mirror for amd64+i386+powerpc is just over 10GB
[09:31] <mdz> Md: also the udev race conditions seem to need hotplug changes to be fixed
[09:31] <Md> Kamion: module parameters are managed by modprobe, not hotplug
[09:31] <Md> mdz: which race?
[09:32] <Kamion> Md: there is no way for d-i to know in advance what modules are going to be loaded so that it can ask
[09:32] <lucas_> Kamion: ok, thanks
[09:32] <mdz> Md: between the completion of the modprobe process and the creation of the device node
[09:32] <mdz> so that modprobe <module> && work with /dev/foo works as expected
[09:32] <Md> mdz: it will never be fixed, there is no easy way to do it and the maintainer says to use dev.d
[09:33] <Kamion> Md: I would like to be able to know when each module is going to be loaded so that I can ask the user if they want to supply any options to it, basically
[09:33] <Kamion> Md: we can do this with discover because it just gives back a list of module names it wants rather than loading them itself
[09:33] <Md> Kamion: I see your point, but if users know that some modules need options they probably know their names as well
[09:33] <Kamion> Md: there's nowhere for d-i to ask that though
[09:33] <Kamion> Md: people could drop to a terminal and do it, but that's hardly acceptable UI
[09:34] <Md> Kamion: I think this could be added to hotplug without too much work, BTW
[09:34] <mdz> Md: that works for some cases, but not others
[09:34] <Md> Kamion: there is no reason to use a terminal
[09:34] <mdz> pppd, for example, doesn't make sense as a dev.d script
[09:34] <Kamion> how should people add options in the context of d-i then?
[09:35] <Md> Kamion: you present users with a dialog with input fields for a module name and its options
[09:35] <Kamion> Md: in debconf? good luck
[09:35] <Md> mdz: OTOH in this case you already know the device name
[09:36] <Kamion> mdz: /lib/debian-installer-startup.d/S40framebuffer-module-linux-x86 is another example
[09:36] <Kamion> I've had several cases recently where /dev/fb/0 simply never appeared
[09:36] <Kamion> it's as if the event vanished somewhere between hotplug and udev
[09:36] <mdz> Md: true, but polling waiting for the device node to appear is such a hack
[09:36] <Kamion> but I haven't been able to reproduce it reliably enough to debug it; it seemed to go away when I started poking at it
[09:37] <Md> mdz: agreed. but I'm not going to fight this anymore, you people should subscribe to the linux-hotplug mailing list
[09:37] <mdz> Md: I wish I could follow the mailing lists for every project that I work with, but unfortunately it is too much
[09:39] <Kamion> the problem with using /etc/dev.d for the framebuffer stuff is that checking to see whether /dev/fb/0 has appeared seems to be about the only reliable way to tell whether the framebuffer module loaded properly or not
[09:40] <Kamion> particularly with vesafb and vga16fb; they can load and then not work
[09:40] <Kamion> so /etc/dev.d doesn't really work; you still have to say "we're going to wait for a while to see if this worked, otherwise give up" :-(
[09:40] <Md> BTW, you should use "sleep 0.1" instead of "sleep 1"
[09:41] <Kamion> is that implemented in busybox?
[09:41] <Md> if it works in busybox
[09:41] <Kamion> it doesn't seem to be
[09:42] <Kamion> it just uses sleep(3)
[09:42] <Kamion> I would certainly prefer finer granularity
[09:42] <Kamion> then again, it seems to take as long as five or six seconds for the device to appear on my test laptop
[09:43] <Kamion> I'd love to know what the system is doing for that time
[09:43] <Md> me too. in this case I find hard to blame fb brokeness on udev :-)
[09:43] <Kamion> oh, I'm not blaming udev exclusively, but it does make things harder to follow that's all :-/
[09:44] <Kamion> still, getting rid of devfs *was* nice
[09:45] <Md> it was a bad idea from the start to use devfs for hardware detection, but nobody listened...
[09:45] <Kamion> nothing else was available at the time
[09:45] <Kamion> for d-i, that is
[09:45] <Md> it was a bad idea to not target 2.6 kernels from the start as well :-)
[09:45] <Kamion> you do realise d-i development started four years ago right?
[09:45] <Md> yes
[09:46] <Kamion> it's not good strategy to develop for a kernel you can't run yet :)
[09:46] <Md> maybe not from the start, but one year ago
[09:46] <doko> elmo: please sync openoffice.org-debian-files, when openoffice.org 1.1.3 enters hoary
[09:46] <Kamion> could be; we've been gradually moving over
[09:47] <Kamion> my experience so far certainly tends to support my opinion that moving to udev/hotplug in a hurry would not have been a good idea from a stability/permanent-releasability point of view
[09:47] <smurfix> Md: even half a year ago I wouldn't have depended on 2.6 exclusively.
[09:47] <Kamion> I'm somewhat worried for hoary actually; I'd much prefer if we were getting the massive attention that d-i changes in Debian get, for a change this sweeping
[09:47] <Kamion> but we're committed to it
[09:48] <Kamion> mdz: oh, do you mind if I add pciutils-udeb, usbutils-udeb, and libusb-0.1-udeb? I need pci.ids and usb.ids now that discover1-data is no longer around to provide the names of network interfaces for netcfg's UI
[09:48] <Kamion> mdz: which I had totally not thought about in advance
[09:48] <azeem> Kamion: joeyh said you will open up the d-i branch for etch soon, so if you merge it early, you'll get enough testing there as well, hopefully
[09:48] <azeem> you == the d-i guys
[09:49] <Kamion> mdz: and getting lspci and lsusb will probably be a bonus for debugging purposes, too
[09:49] <Kamion> azeem: yeah, I'm very much hoping so
[09:52] <Kamion> azeem: I have a number of other changes I want to merge, but which are too untried for sarge
[09:53] <azeem> sweet
[09:59] <fabbione> Kamion: how is the build going?
[10:02] <Kamion> make[1] : Entering directory `/home/cjwatson/src/ubuntu/linux-source-<IP_ADDRESS>/linux-source-<IP_ADDRESS>-<IP_ADDRESS>/debian/build/build-power4-smp'
[10:02] <Kamion> The changelog says we are creating <IP_ADDRESS>, but I thought the version is <IP_ADDRESS>-3-power4-smp
[10:02] <Kamion> make[1] : *** [stamp-debian]  Error 1
[10:02] <Kamion> oh, damnit, I probably need Ubuntu's kernel-package
[10:03] <fabbione> argh.. yes
[10:03] <Md> ROTFL! I just noticed that the new udev makefile prints init-style green "[OK] " labels instead of the whole command line
[10:03] <fabbione> Md: green? it's white here
[10:03] <fabbione> ahh
[10:04] <fabbione> never miind
[10:09] <Kamion> fabbione: trying again, off to the pub now
[10:09] <fabbione> Kamion: have fun :-)
[10:27] <elmo> doko: nothing to sync?
[10:38] <doko> elmo: ahh, ok, from experimental, or should this be directly uploaded?
[10:43] <Mithrandir> fabbione: pong?
[10:44] <fabbione> ehehe
[10:44] <fabbione> Mithrandir: #debian-women
[10:44] <fabbione> i was trying to convice your gf to build a kernel for me :-P
[10:44] <Mithrandir> hehe :)
[10:44] <Mithrandir> what arch?
[10:44] <fabbione> amd64
[10:45] <Mithrandir> I don't think she has an account on any amd64 box
[10:45] <fabbione> we need to fix this, don't we? ;)
[10:45] <fabbione> well it's easy
[10:45] <Mithrandir> she just doesn't have any account on my home box, is that so weird? :)
[10:45] <fabbione> just grab linux-source-<IP_ADDRESS><whatever>-17.d*
[10:46] <fabbione> Mithrandir: apply this: http://people.ubuntulinux.org/~fabbione/17_to_18.diff
[10:46] <fabbione> and build
[10:46] <fabbione> it needs to be done in hoary
[10:47] <fabbione> even if you tell me in 2 days or tomorrow late evening if it works, it will be more than fine
[10:47] <Mithrandir> applied against what kernel source?
[10:49] <fabbione> Mithrandir: we have only one
[10:49] <fabbione> that applied to the entire package
[10:49] <fabbione> linux-source-<IP_ADDRESS>-<IP_ADDRESS>
[10:50] <Mithrandir> yeah, but my DSL is only at about 260KB/sec atm.
[10:50] <fabbione> yeah don't worry...
[10:51] <fabbione> even tomorrow is fine
[10:52] <fabbione> brb
[10:55] <jdub> doko: can we remove the kde depends/packages from OOo in the mean time, before haggai and _rene_ add their optional foo?
[10:58] <doko> jdub: I'll have a look, but maybe let's wait for the first problem reports before the next upload.
[10:59] <jdub> doko: if it depends on kdelibs4-dev, it won't build.
[10:59] <jdub> doko: OOo is sitting there happily not building.
[10:59] <jdub> doko: so i have a problem report and a solution for you ;-)
[11:03] <seb128> jdub: how is flumotion package going ? thomasvs was asking about it
[11:03] <jdub> seb128: haven't spent time on it since the initial packaging - have to upgrade and upload.
[11:04] <elmo> doko: synced
[11:04] <jdub> seb128: will probably do it over the weekend, can't today.
[11:04] <seb128> jdub: ok
[11:07] <_rene_> we probably could do it fairly quick... I just need a package which reliably is in ubuntu but not in debian ;-)
[11:07] <_rene_> the DEB_BUILD_OPTIONS logic is already written...
[11:10] <Matt|> hoary: anyone got totem working?
[11:10] <doko> jdub: ok, will do another one ...
[11:13] <_rene_> ok, if anyone wants to tell me that package, mail me ;-)
[11:13] <Matt|> hey guys is totem working ok in hoary? just crashes on startup here
[11:18] <thom> Mithrandir: oh?
[11:21] <jdub> doko: i was going to do a quick revision here, but 171MB... OWCH :)
[11:21] <jdub> Matt|: load it with a file
[11:21] <Matt|> jdub, ok i'll try
[11:22] <Matt|> jdub, yeah that works ok
[11:22] <jdub> known bug, hopefully there'll be a new release soon
[11:23] <Matt|> upstream bug?
[11:23] <jdub> yes
[11:23] <Matt|> ok thanks v much
[11:23] <Mithrandir> thom: go to http://err.no/personal/wishlist/
[11:23] <Matt|> it is a recent thing
[11:23] <doko> jdub: yes, that's why I didn't upload it with my 16kB upstream ...
[11:23] <Mithrandir> thom: but I'm off to bed now.  Talk to you in the morning
[11:23] <jdub> doko: i'm tempted to do it on chinstrap or something
[11:24] <jdub> doko: man, my upstream is fatter than that - if you don't want to do it, let me know
[11:26] <doko> it's on adare for now, I just didn't want to upload the binaries.
[11:27] <jdub> you only need to upload the diff
[11:27] <elmo> you only CAN upload the diff
[11:27] <doko> yes, working on it ...
[11:28] <jdub> elmo: so, the mp3 stuff in debian - what led to it being acceptable?
[11:29] <elmo> jdub: *shrug* decoding's never not been accepted - at the time, the consensus was it was as valid as the lzw decompress patent, i.e. not
[11:29] <elmo> oh, and infact, I think Thompson explicitly said free decoders were okay or something too
[11:29] <jdub> ?!
[11:30] <jdub> well, lzw stuff led to libgd-nonfree and friends
[11:30] <pitti> mdz: nice de-rootification hints, thanks for them
[11:30] <seb128> jdub: please comment on #4092 :)
[11:30] <elmo> jdub: only for encode
[11:30] <elmo> jdub: decode was always accepted
[11:31] <elmo> that's why we had web browsers in main...
[11:31] <elmo> or image viewers or...
[11:31] <elmo> and why libungif existed
[11:31] <jdub> seb128: that's the ffmpeg thing?
[11:31] <seb128> jdub: yes
[11:31] <jdub> seb128: oddly, this is related ;)
[11:31] <seb128> :)
[11:32] <jdub> elmo: so the 'debian stance' is that the patents cover encoding, not decoding, so let's get on with it?
[11:32] <elmo> okay, I may have made up the point about Thompson not going after decoders at one stage - I only vaguely recall reading that, and can't find a reference
[11:32] <elmo> jdub: err, no - the consensus at the time, as I remember it was that the mp3 decode patent wouldn't stand up
[11:32] <jdub> and i can't remember them ever saying anything positive about non-thomson Free implementations
[11:33] <jdub> elmo: whoa, okay
[11:33] <jdub> elmo: so, ffmpeg stuff.
[11:33] <elmo> remember, that's partially based on lzw precedent - unisys claimed decode on that too, and we (and gzip upstream who did a lot of research into it) thought that was bogus too
[11:34] <elmo> but Debian really isn't a good example, we do a lot of legal stuff that's dubious basically through lethargy.. e.g. it took us years to start enforcing GPL vs. SSL conflicts
[11:34] <elmo> jdub: what's that do?
[11:35] <jdub> so if debian thinks a patent is bogus, you'll ship until there's judgement or injunction
[11:35] <jdub> ?
[11:35] <jdub> ffmpeg viciously violates every mpeg related patent known to man
[11:35] <elmo> jdub: *shrug* I'm really not comfortable answering questions about "what debian does" - I can't speak for them , but historically we have yes
[11:35] <seb128> ffmpeg is staying in NEW for months :p
[11:36] <elmo> jdub: more so than the existing stuff we have?
[11:36] <elmo> e.g. xine, SDL's plaympeg etc.?
[11:36] <jdub> doesn't debian's xine disable its ffmpeg stuff?
[11:37] <jdub> ffmpeg is copy'n'pasted in lots of things
[11:37] <jdub> so it's a hard one
[11:37] <jdub> seb128: 'longtemps' in french?
[11:37] <seb128> yes
[11:38] <seb128> you start with the big "everybody speaks french" plan ? :)
[11:38] <jdub> heh, what does it mean? :)
[11:38] <seb128> oh
[11:38] <seb128> a long time
[11:38] <jdub> haha
[11:38] <seb128> I thought you were reaction to my <seb128> ffmpeg is staying in NEW for months :p
[11:38] <jdub> yeah ;)
[11:38] <jdub> but no
[11:38] <jdub> my french is not that good
[11:39] <jdub> i just saw it on vuntz's jabber status :)
[11:39] <seb128> oh ok
[11:39] <jdub> 'parti pour longtemps' -> fun :)
[11:39] <seb128> he he
[11:40] <jdub> i think xine uses a limited ffmpeg
[11:40] <seb128> jdub: about ffmpeg, dunno what sam did exactly with the package waiting in NEW, but usually he does really good work
[11:40] <elmo> sam is usually very careful with patents
[11:40] <seb128> yes
[11:40] <jdub> seb128: is that gst-ffmpeg or ffmpeg itself?
[11:40] <seb128> ffmpeg
[11:41] <jdub> oh no, it has libavcodec in it too
[11:41] <elmo> the main question is if the ffmpeg in NEW does encode - we have decoders in main (-> precedent), we don't, AFAIK, have any encoders
[11:41] <seb128> taaz is waiting on ffmpeg to upload gst-ffmpeg ... that's not needed, but since no decision is taken about ffmpeg ...
[11:41] <mirak> erf
[11:41] <jdub> so it's sitting in NEW purely because it's controversial?
[11:41] <mirak> j'ai cr un fichier   "-f2" par megarde
[11:41] <mirak> je ne parviens pas a le virer
[11:42] <mirak> avec tm
[11:42] <mirak> rm
[11:42] <mirak> bon je l'ai vir avec konqueror
[11:42] <mirak> mais j'ai pas trouv comment faire avec rm
[11:43] <mirak> il croit en effet que je lui passe une option
[11:43] <seb128> mirak: ECHAN imho
[11:43] <mirak> ?
[11:43] <_rene_> mirak: and if not ECHAN, ELANG anyway
[11:43] <seb128> mirak: that's #ubuntu-devel ...
[11:43] <_rene_> mirak: this is an english-speaking channel...
[11:43] <mirak> damn
[11:43] <mirak> sorry
[11:43] <mirak> lol
[11:44] <mirak> I am tired
[11:44] <mirak> my bad
[11:44] <smurfix> mirak: so go to sleep
[11:44] <jdub> i can't understand what you are talking about, but i would defend to the death your right to say... whatever it is.


[00:08] <ordinate> dicked around in the terminal, xfce4-panel doesn't work in the slightest
[00:10] <ordinate> rebooted, f9'd from the boot menu into ubuntu, found no boot media or something
[00:11] <ordinate> changed up the boot order to get it back, but the problem still persists
[00:11] <ordinate> also that time problem is back again
[00:14] <xubuntu73d> hello?
[00:14] <ordinate> hi
[00:14] <knome> hello
[00:15] <xubuntu73d> LOL  great some really is here!
[00:15] <ordinate> huwway
[00:17] <xubuntu73d> Got a question about setting up multiple users in Xubuntu.  I have two accounts: Admin and Desktop user.  But when I reboot the machine it always defaults to a no login boot to the Admin desktop.  Before I made the Desktop account, it always came to the standard login prompt.  How can I set it up to always boot to the User Selection/Login prompt?
[00:18] <ordinate> knome knows, i don't
[00:19] <xubuntu73d> Not sure how I broke it.
[00:21] <knome> did you set up automatic login?
[00:22] <xubuntu73d> No.  Before creating the second account, I always booted to the session/user selection gui.
[00:24] <xubuntu73d> Just FYI, I do have another distro on the drive and at boot have to select in the grub bootloader.  I can't see how that would make any diff though.
[00:26] <xubuntu73d> Any ideas?
[00:28] <xubuntu73d> Well, thanks for trying.
[15:21] <yourgg> hello, i'm trying to install korean language/keyboard on xubuntu 16.04.01 but so far with no success anyone here knows anything about that?
[15:26] <yourgg> I use fcitx , the korean keyboard appears in the indicator bar, I can switch it on from there but it has no effect
[15:29] <yourgg> in my old machine I was using Ibus without problem should I go back to it or keep trying with fcitx?
[15:42] <lshw> hi everybody. Is someone here willing to answer a question about developing an xfce4-panel-plugin?
[16:05] <yourgg> nobody experienced with fcitx and korean has time to help me ?
[16:39] <Fernando-Basso> I was going to suggest arch wiki to yourgg: https://wiki.archlinux.org/index.php/Internationalization/Korean
[16:39] <Fernando-Basso> It might help.
[18:58] <malysps> hello, I have one minor issue with Greybird in Xubuntu 16.04, can I ask here or better create new issue on github?
[19:04] <tmsbrg> malysps, you can post your issue here and see if there's anyone around who knows about it or could help you
[19:06] <tmsbrg> if it's really a bug then it's worth adding looking for it in the issue tracker and adding it if it's not there yet.
[19:06] <tmsbrg> s/adding looking/looking/
[19:09] <malysps> this issue is visible on twitch.com website, I'll show you two screenshots 1) http://prnt.sc/ceioxz 2) http://prnt.sc/ceio54
[19:10] <malysps> 1) is a Zukitre theme, and it looks clean 2) is Greybird and it shows unnecessary scrollbar on the left side (above the avatar) and overlapping scrollbars on the right side
[19:18] <tmsbrg> malysps, wouldn't that be a problem with the theme combination?
[19:18] <YankDownUnder> malysps: You've looked on github for this issue?
[19:19] <mypainter> Hi. After installing plasma (kde) I can no longer log into xfce. The mouse look changed after installing plasma, which was cool, but after a couple boots it just stopped being able to log in at all. I tried installing lxdm and the like, but when selecting xubuntu or xfce as a session it just either bounces me out (lxdm) or hangs with a desktopbackground and mouse (lightdm). Lxde and Kde both work fine.
[19:19] <mypainter> memory usage is 44% or under for all df -H listings
[19:20] <malysps> tmsbrg, what do you mean by combination? YankDownUnder, yes, I couldn't find it, but maybe I must look deeper
[19:20] <YankDownUnder> malysps: https://github.com/lassekongo83/zuki-themes => where to start...
[19:22] <tmsbrg> malysps, I'm not exactly an expert of window themes, but maybe Greybird and Zukitre aren't meant to work together
[19:23] <malysps> yes, I've got zuki-themes (branch 3.18) from github, but this issue is about Greybird (default Xubuntu 16.04 version)
[19:23] <malysps> I'm not combining them in any way
[19:24] <malysps> screenshot with Zukitre theme is only to show how this website should look like (no scrollbars)
[19:25] <mypainter> Any ideas? How can I get a detailed terminal-style output  / log to figure out why I cannot login using xfce anymore?
[19:25] <tmsbrg> mypainter, no idea but it may be work looking at the logs like checking `dmesg|less' and scrolling to the end after the login fail
[19:25] <mypainter> ok, thanks tmsbrg
[19:26] <mypainter> that is a good point. although, there isn't a xfce log somewhere though?
[19:26] <tmsbrg> I don't think so and I don't see any on my system
[19:27] <tmsbrg> though lightdm has a log that could be worth checking out in /var/log/lightdm
[19:29] <YankDownUnder> mypainter: In some instances - installing KDE/Plasma will cause "sddm" to be installed - and having the two different "display managers" can cause issues - more than just login issues. You should be ablle to use the first tty (using CTL+ALT+F1), login, do a "sudo service lightdm stop", then do "sudo dpkg-reconfigure lightdm" => make sure that lightdm is set as the primary displaymanager....once done, you can then do: sudo service
[19:29] <YankDownUnder> lightdm start => see if that resolves the issue...
[19:30] <mypainter> does sddm not play nice with xfce?
[19:31] <mypainter> also, YankDownUnder, when I try that, I will lose irc connection
[19:32] <YankDownUnder> mypainter: It *can* => but bear in mind that it's primarily a KDE/Plasma "dm" and it *can* cause issues with "other" window managers and desktops...(been there done that)
[19:34] <mypainter> would that explain why the cursor changed?
[19:34] <YankDownUnder> mypainter: Yes
[19:34] <mypainter> ok
[19:35] <mypainter> yeah it was something like the first reboot the cursor changed, then a few later the desktop icons were kind of unreadible unless selected -so i changed the theme to fix it, and then a few reboots after that it just stopped working altogether
[19:37] <mypainter> ok, thanks <YankDownUnder>, I'll be back (hopefully)
[19:37] <YankDownUnder> mypainter: Look, the reality of the situation is this: KDE/Plasma and all the rest have not played nice for years...many years...so, if you're going to mix up the desktop environments, bear this in mind and be prepared...it can get ugly (literally, it can get ugly - themes, icons, and more) :)
[19:42] <mypainter> nope
[19:42] <mypainter> using lxde from lightdm seems to be my best option
[19:43] <mypainter> plasma is too slow for this i3
[19:43] <mypainter> it works but everything is just an extra .5seconds slower
[19:44] <mypainter> dropdown boxes etc
[19:46] <YankDownUnder> mypainter: All the "eye candy" comes at a price.
[19:49] <mintlovers> https://twitter.com/Alamann7/status/772684722325508096/photo/1?ref_src=twsrc%5Etfw
[19:49] <mintlovers> heh heh
 So I checked the log locations
[20:11] <mypainter> and I can't find anything that seems like it would say why xfce keeps failing
[20:12] <YankDownUnder> mypainter: Create a new user. Try to login to XFce with the new user. If you *can*, then that tells you something is hosed in the profile.
[20:13] <mypainter> hmm that is an interesting idea
[20:21] <mypainter> unrelated question?
[20:21] <mypainter> :
[20:21] <YankDownUnder> Shoot
[20:21] <mypainter> how can I have a window in xubuntu automatically move to a part of the screen
[20:21] <mypainter> similar to super+arrow in windows
[20:21] <mypainter> ?
[20:22] <YankDownUnder> mypainter: You mean a "saved state" for a window?
[20:22] <mypainter> no. just tiled movement
[20:22] <mypainter> from keyboard, make a window take up half the screen (either horizontally or vertically)
[20:25] <YankDownUnder> mypainter: Look through the "window manager" settings and "window manager tweaks" => there used to be several different ways of doing it, but that, for me, is past time...and if I recall, there was a means by which to assign keycombos to such...but again...in the past for me...


[09:52] <smoke_> whats the default image viewer for newest distro of lubuntu?
[17:18] <cerebrate> -
[17:18] <cerebrate> had to clean my keyboard
[17:23] <SonikkuAmerica> -
[17:23] <SonikkuAmerica> had to press the dash key just to see if it worked.
[19:20] <tocsick> hey all, the recent updates to oneric have somehow changed my scrolling. When I scroll with the mousewheel, the screen will scroll down, then jump up again, then scroll more, etc. Any suggestions on how to correct this?
[20:25] <Kamilion> Hmmm. I installed some alternative browsers for the terminal just in case I needed them (links and midori) but now when i click links in my IRC client (which uses xdg-open) it opens in links instead of chromium. How do i get chromium back?
[20:30] <gomiboy> Kamilion: this should work: update-alternatives --config x-www-browser
[21:45] <llogiq> Hi folks.
[21:46]  * genii-around hands llogiq a coffee
[21:47] <llogiq> I have a problem configuring the ElanTech touchpad of my wife's notebook. I want to activate palm detection. This works with gpointer-device-settings or using synclient - until reboot. Adding a InputClass section to a 99-user-settings file on the other hand, appears to do nothing.
[21:48] <llogiq> thanks, genii-around, but I recently had a stomach infection and have to skip all coffee. I usually love coffee, so that's really bad.
[21:48] <genii-around> llogiq: Ah, sorry to hear.
[21:49] <genii-around> Hopefully someone addresses your issue, I don't know enough about that particular stuff to be useful here.
[21:50] <llogiq> genii-around, thanks anyway for being there. :-)
[21:53] <llogiq> I found an old help section on the ubuntu wiki. Trying that one out. If it works, have a great time folks. If not, brb.
[23:07] <silvia> ciao
[23:07] <SonikkuAmerica> Guten Knaben
[23:08] <SonikkuAmerica> Aww... silvia left


[06:59] <dholbach> good morning
[16:48] <jcastro> dholbach: I'm all ready for the update
[16:49] <dholbach> jcastro, awesome
[16:49] <dholbach> jcastro, hum - does ubuntuonair.com work for you?
[16:50] <dholbach> I can't see the video
[16:50] <jose> jcastro: make sure to not change the video size
[16:50] <jose> and also, use the /embed/ link, not the direct video link
[16:50] <dholbach> ah, there we go
[16:50] <dholbach> yep yep
[16:50] <dholbach> works now
[16:51] <jcastro> I didn't change the video size!
[16:51] <jcastro> everyone keeps blaming me for changing that!
[16:51] <dholbach> yeah, it's your fault
[16:51] <jose> :P
[16:52] <jose> and user <center> for the hangout title
[16:52] <jose> wait, just let me see if I can log in and do it myself
[16:56] <jose> blargh, school filter says that 'youtube.com' is a non-permitted phrase
[16:56] <dholbach> jose, youtu.be didn't work for me over here
[16:56] <dholbach> that's why I changed it
[16:56] <dholbach> the video didn't load
[16:57] <jose> dholbach: try http://youtube.com/embed/videocodehere
[16:57] <jose> let me get the link for you
[16:57] <dholbach> that's what's in there right now, right?
[16:58] <jose> yeah, I needed a hard reload to see that
[16:58] <jose> should be working now - is it?
[16:58] <dholbach> yep, looks good now
[16:58] <jose> school filter will auto-block youtube
[16:58] <jose> great :)
[16:58] <jose> let me know if anything pops up
[16:58] <dholbach> looks good now, thanks
[16:58] <dholbach> I'll confirm once we go live
[17:02] <jose> dholbach: sorry about airbot not working, will fix it once I get home
[17:03] <jose> dholbach: sorry about airbot not working, will fix it once I get home
[17:03] <dholbach> thanks jose
[17:10] <jose> dholbach, mhall119: don't forget to mention to follow us on twitter (twitter.com/ubuntuonair) and subscribe to us on youtube (youtube.com/ubuntuonair)
[17:11] <dholbach> I hope I won't forget until the end :)
[17:14] <jose> dholbach, mhall119: AirBot is now working, !q in PM to AirBot to get the next question.
[17:14] <dholbach> thanks jose
[22:29] <pleia2> jono: shall I x-post olli's mailing list post to fridge or did you have something else in mind?
[22:37] <jono> pleia2, if you could, that would be wonderful
[22:37] <jono> thanks
[22:37] <pleia2> sure


[00:03] <ChmEarl> out of Xen, Qemu, and Grub... who was prepared for lz4 compressed kernels? maybe none
[00:04] <ChmEarl> Xen is mostly working now... grub certainly not
[00:04] <ChmEarl> there is no code in /grub-core/io to handle lz4
[00:10] <FurretUber> The image on the USB isn't Focal, it's Bionic. The problem seem to arise when adding grub from Focal only
[00:10] <FurretUber> The system on the USB is in a squashfs file