[00:02] <owen1_> can u say that ubuntu development is agile? if yes, do u have any links for more info?
[00:02] <owen1_> (it's for a university assignment)
[00:10] <persia> owen1_: Maybe, and not really, but http://wiki.ubuntu.com/UbuntuDevelopment may help
[00:12] <owen1_> persia: great. thanks
[01:02] <BenC> pitti: around?
[01:52] <ion_> benc: I didn’t manage to test the grub patch yet, but i’ll see if i get around to that tonight.
[01:52] <BenC> ion_: thanks...CC cking@ubuntu.com with any results, please
[01:53] <ion_> Will do
[02:01] <kane> hi
[02:01] <kane> Anyone here
[02:01] <ion_> Nope
[02:01] <kane> ok kool
[02:01] <kane> At least someone
[02:02] <kane> Its like no one active in IRC
[02:02] <kane> I need help installing a broadcom 4311 on ubuntu
[02:02] <ion_> Please read the topic.
[02:03] <kane> ook
[02:03] <kane> thanks
[03:28] <kees> Keybuk: say, any idea why pcre3 is showing up on MoM as unmerged with a 2-day-old ubuntu version?
[06:47] <emgent> giskard: heya
[07:08] <pitti> Good morning
[07:09] <emgent> moin pitti
[07:10] <pitti> hey emgent
[07:10] <pitti> BenC: hi
[07:10]  * StevenK waves to pitti 
[07:11]  * pitti throws a cookie towards Australia
[07:11] <StevenK> And it landed where, across the street? :-)
[07:12] <Hobbsee> hey pitti!
[07:17] <BenC> pitti: hey
[07:18] <BenC> pitti: is there any progress on package-groups?
[07:19] <pitti> BenC: not that I can see :-( Last thing I know is that mvo proposed it to Debian, but I didn't see feedback to that yet
[07:26] <BenC> pitti: should we even consider it an option for intrepid at this point?
[07:26] <pitti> BenC: I don't think it'll make it, I'm afraid :/
[07:48] <BenC> pitti: that's too bad...I did all the kernel side stuff to make it work
[07:48] <BenC> guess that will be 9.04
[07:48] <pitti> uh, sorry for that
[07:49] <pitti> BenC: what did you change, out of interest? add the P-G headers already?
[07:49] <BenC> pitti: no, just the last-good-boot stuff so that we could reasonably get rid of the versions in the pkg name
[07:49] <BenC> and move things to Version: and P-G headers
[07:50] <BenC> so it's not a waste
[07:50] <BenC> and I haven't done anything that needs to be reverted :)
[07:50] <pitti> BenC: oh, l-g-b is a separate feature anyway, right?
[07:50] <pitti> ok, *phew* :)
[07:50] <pitti> BenC: I'll ask mvo again about the status, I'm curious myself
[07:52] <pitti> BenC: BTW, last time I looked at it (or, rather, the error messages), it seemed to hardlink the current kernel/initrd
[07:53] <pitti> BenC: will that DTRT if there is a non-abi-updating new kernel package, too?
[07:53] <pitti> i. e. like the current -5.13 -> -5.14
[07:53] <BenC> pitti: it saves everything on every boot...so yes
[07:54] <BenC> pitti: when a kernel update happens, the hardlinks are broken (dpkg doesn't overwrite the existing file, it always unlinks/renames)
[07:54] <BenC> pitti: same with update-initramfs
[07:54] <pitti> great
[07:55] <pitti> so that means cheap operation on boot (just ln, not cp), and correct behaviour on update
[07:56] <pitti> asac: any news on nspr/nss in hardy-proposed?
[07:58] <kirkland> pitti: hey, jockey/intrepid question for you...
[07:58] <pitti> hey kirkland
[07:58] <kirkland> pitti: i just moved my primary laptop over to intrepid, and jockey doesn't appear to see my atheros wireless, or nvidia video
[07:58] <kirkland> pitti: are these known issues?
[07:59] <pitti> kirkland: it currently doesn't have any particular support for atheros ATM (nobody wrote a handler for it, or told me what to do for it)
[07:59] <pitti> kirkland: nvidia should work, though; do you have a minute to debug it?
[07:59] <kirkland> pitti: sure
[08:00] <pitti> kirkland: first, do you have nvidia-common installed?
[08:00] <kirkland> pitti: no, i don't
[08:00] <kirkland> pitti: but nvidia is listed by lsmod
[08:00] <pitti> kirkland: n-c is not needed by itself, but it needs its dependencies, nvidia-VERSION-modaliases
[08:00] <pitti> kirkland: that would be it then; without the -modalias files, it cannot map vendor/product IDs to nvidia driver versions
[08:01] <pitti> kirkland: apt-get dist-upgraded without recommends?
[08:01] <kirkland> pitti: not on purpose....
[08:01] <pitti> oh, a hardy->intrepid dist-upgrade wouldn't actually pull in Recommends:, true
[08:01] <pitti> since we only enabled it in intrepid
[08:01] <kirkland> pitti: ah, right
[08:02] <kirkland> pitti: okay, nvdia-common (and friends) is installed now
[08:02] <pitti> might be an interesting thing to discuss with mvo, but I guess the answer is "use update-manager" :)
[08:02] <pitti> kirkland: sudo killall jockey-backend, then try again
[08:02] <kirkland> pitti: I did do my upgrade via update-manager
[08:03] <pitti> oh? definitively mvo's bug then; can you please file a bug?
[08:03] <pitti> I guess it forgot to pull in recommends
[08:03] <kirkland> pitti: sure, i'll talk to mvo in real time first
[08:03] <kirkland> pitti: just to make sure i didn't do anything bone headed
[08:04] <kirkland> pitti: shiny, now I have two different nvidia drivers to choose from
[08:04] <dholbach> good morning
[08:04] <emgent> dholbach: welcome back! :)
[08:04] <dholbach> thanks emgent
[08:05] <tseliot> ﻿pitti: can't we use dependencies instead of recommends for nvidia-common?
[08:06]  * kirkland restarts X
[08:15] <pitti> tseliot: sure we could, but semantically Recommends: is the right thing
[08:20] <tseliot> pitti: right but reliability > Semantics :-P
[08:22] <kirkland> pitti: okay, jockey bits appear to be workign
[08:22] <kirkland> pitti: nvidia x driver, that's another story ;-)
[08:22] <kirkland> i'll ping bryce about that tomorrow
[08:22] <pitti> kirkland: nice, thanks
[08:22] <pitti> kirkland: or ask tseliot
[08:23] <kirkland> tseliot: any known issues with nvidia in intrepid?
[08:23] <pitti> tseliot: true; I'll wait for the discussion about u-m, and raise to depends if nothing else helps
[08:23] <kirkland> tseliot: i can't get gdm to start
[08:23] <tseliot> ﻿kirkland: can I see your xorg.conf?
[08:23] <kirkland> tseliot: sure...
[08:24] <tseliot> ﻿pitti: ok, thanks
[08:24] <kirkland> tseliot: this is the broken one: http://pastebin.ubuntu.com/33925/
[08:24] <kirkland> tseliot: I'm running on vesa now
[08:25] <tseliot> ﻿kirkland: it looks good. Can I see your /var/log/Xorg.0.log.old?
[08:26] <tseliot> so that I can see where X failed
[08:26] <gnomefreak> tseliot: upgrading from hardy to intrepid nvidia doesnt work with old xorg.conf atleast most people had to run nvidia config (cant remember command off hand atm
[08:26] <kirkland> tseliot: http://pastebin.ubuntu.com/33926/
[08:26] <tseliot> ﻿gnomefreak: because of the RgbPath line?
[08:27] <kirkland> gnomefreak: i tried nvidia-xconfig too... no avail
[08:27] <gnomefreak> tseliot: IIRC yes
[08:27] <gnomefreak> kirkland: you can rebuild xorg.conf by hand but its easier with command. kirkland you installed the right drivers?
[08:27] <tseliot> gnomefreak: I would like to deal with this problem during the dist-upgrade.
[08:29] <gnomefreak> tseliot: after fixing xorg.conf after upgrade in april/may it doesnt look any different than the old one
[08:30] <tseliot> kirkland: you're using a Quadro card. The log shows only the VESA driver but I suspect that the unified back buffer is conflicting with Composite. Can you try creating an "Extensions" section in your xorg.conf and adding Option "Composite" "Disable" ?
[08:30] <kirkland> tseliot: sure
[08:30] <kirkland> gnomefreak: what are you calling the "right" drivers
[08:30] <gnomefreak> kirkland: nvidia-glx-#
[08:31] <gnomefreak> after removing the old drivers
[08:31] <tjaalton> hmm, something wrong with a.u.c? can't update my laptop, some packages give 404's
[08:31] <mvo> kirkland: did you upgraded using update-manager? if so, could you make /var/log/dist-upgrade/main.log availabe for me please (mail or so)?
[08:31] <kirkland> gnomefreak: i had 177, now i'm trying 173
[08:31] <tseliot> ﻿gnomefreak: the ﻿RgbPath line was usually added by nvidia-xconfig
[08:32] <gnomefreak> i dont see it
[08:32] <kirkland> mvo: I used update-manager -d -c
[08:33] <tseliot> ﻿kirkland: if you try the other driver, please send me your ﻿/var/log/Xorg.0.log and ﻿/var/log/Xorg.0.log.old
[08:33] <tseliot> ﻿gnomefreak: then you had a different problem which of course I can't see without a log
[08:33] <gnomefreak> tseliot: http://pastebin.mozilla.org/506105 is my xorg.conf
[08:34] <tseliot> ﻿gnomefreak: the xorg.conf is correct
[08:34] <gnomefreak> maybe ill upgrade one of my other systems to see if i can reproduce it. sometime today or tomorrow
[08:34] <tseliot> ﻿gnomefreak: ok
[08:34] <gnomefreak> tseliot: thats from nvidia-xconfig
[08:35] <kirkland> mvo: on its way (see the 2nd email from me)
[08:35] <gnomefreak> tseliot: i have old one too
[08:35] <mvo> kirkland: thanks
[08:36] <kirkland> tseliot: which driver are you interested in?
[08:36] <tseliot> ﻿gnomefreak: ok, I would be glad if you could file a bug about this and attach the 2 files
[08:36] <lifeless> mvo: hi
[08:37] <lifeless> mvo: any archive changes recently ?
[08:37] <tseliot> ﻿kirkland: whatever you want as long as I get a log which reports that X tried to load the NVIDIA driver ;)
[08:37] <gnomefreak> tseliot: i would like to reproduce it first ;) but ill file one if it still happens
[08:37] <tseliot> ok
[08:37]  * kirkland restarts X
[08:37] <mvo> lifeless: hi, I just added a tiny debugging patch to the conflictsfinder to hopefully get a better idea what is the issue
[08:38] <lifeless> mvo: :) you could tell where I was leading :)
[08:39] <tjaalton> ok the archive works properly now
[08:40] <mvo> lifeless: indeed :) dozens of mails from the conflictsfinder are not easily ignored (unless I add a sieve rule :P)
[08:40] <mvo> kirkland: thanks, got it
[08:41] <kirkland> tseliot: http://pastebin.ubuntu.com/33931/  <- with nvidia driver
[08:42] <gnomefreak> kirkland: that looks like what i got after dist-upgrade well atleast same EE
[08:42] <tseliot> kirkland: did you disable composite?
[08:46] <kirkland> tseliot: I did
[08:46] <kirkland> tseliot: it failed much quicker, at least
[08:47] <tjaalton> pitti: so you are the HAL maintainer? do you have an opinion about where to put the script which generates the X input-hotplug fdi-file (sources the values from /e/d/console-setup)? either hal or xserver-xorg is probably where it should be, but jcristau thought it could be useful not just for X, which would mean hal should generate the file
[08:48] <mvo> kirkland: hm, that seems to be a issue with the package itself, update-manager logs look ok, it selected a driver that it thinks was appropriate. does it not work with  neither-177 or -173?
[08:49] <tseliot> kirkland: something's hiding the real error (I hope). Try adding Disable "dri2" to the Module section of your xorg.conf and then start x with this command: startx -- -logverbose 5
[08:49] <tseliot> then send me the log again
[08:49] <kirkland> mvo: i have not yet gotten nvidia to work with intrepid since I upgraded earlier tonight
[08:50] <pitti> tjaalton: I don't particularly mind to put it into hal; the fdi is generated at package build time and then just shipped?
[08:50] <pitti> tjaalton: what sort of information does it contain? It might or might not fit better into hal-inf
[08:50] <pitti> o
[08:50] <tjaalton> pitti: no, the script is run on postinst
[08:51] <pitti> postinst? why's that?
[08:51] <tjaalton> pitti: see http://people.ubuntu.com/~bryce/InputHotplug/console2fdi.sh
[08:51] <tjaalton> well it needs the values from console-setup
[08:51] <pitti> tjaalton: but what if the default file changes?
[08:52] <tjaalton> pitti: hmm then it might be console-setup that should host it
[08:52] <pitti> or the hal init script
[08:54] <tjaalton> that's possible as well
[08:54] <pitti> tjaalton: and we need to ship hal's 10-x11-input.fdi, too, I presume?
[08:54] <tjaalton> pitti: yep
[08:56] <dholbach> does the new intrepid kernel work for anybody in kvm?
[08:58] <kirkland> tseliot: wanna have a look at my xorg.conf before I give it another go?
[08:58] <kirkland> tseliot: http://pastebin.ubuntu.com/33934/
[08:59] <tseliot> kirkland: it's "dri2" and not "dir2"
[09:00] <tseliot> other than this, the file is ok
[09:00] <kirkland> tseliot: doh!
[09:00] <pitti> tjaalton: so, I'm ok with doing that in the hal init script for now; feels like a hack, but I don't have a better idea ATM..
[09:01] <kirkland> tseliot: it *is* 3am in the morning ;-)
[09:02] <tseliot> ﻿kirkland: ah, you live in the US
[09:03] <Q-FUNK> howdy! has the packages.u.c host gone offline?
[09:04] <mdz> seb128: good morning
[09:04] <kirkland> tseliot: yeah, silly me, i though, "I'll just upgrade to intrepid before going to bed, so I can start work next week all shiny and using the new stuff"  :-)
[09:04] <seb128> hello mdz
[09:04]  * kirkland goes restart X
[09:04] <mdz> seb128: Keybuk told me that the plan was to go ahead and package the new gdm (as a separate package) in Ubuntu, is there anywhere I can get it?
[09:06] <tjaalton> pitti: ok, cool. I'll discuss this again with bryce to see if there's a better "final" solution for it that also fits in debian (not sure if they even use console-setup yet)
[09:07] <persia> About upgrade-manager pulling recommends on upgrade: can we detect cases where users have deliberately uninstalled packages?  Be frustrating for some people to find things they previously uninstalled coming back.
[09:07] <seb128> mdz: https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu, ./autogen.sh && debuild on the code should work but be warned it doesn't log users on first boot on my box (need to be restarted and then log-in works, dunno why), settings are not applied, gnome-power-manager doesn't work correctly, etc
[09:07] <mdz> seb128: thank you
[09:07] <seb128> mdz: it builds a gdm-snapshot which conflicts on gdm and fast-user-switch-applet (the applet is in gdm now)
[09:08] <mdz> seb128: the thread at http://mail.gnome.org/archives/gdm-list/2008-July/msg00024.html said there hadn't been a 2.23 release yet; is that still true?
[09:08] <seb128> mdz: you can probably bzr merge on the current gdm trunk to try the current version
[09:08] <seb128> mdz: no, they rolled a 2.23.
[09:08] <seb128> mdz: no, they rolled a 2.23.2 tarball some days ago because somebody asked for that
[09:08] <seb128> but they didn't put a lot of work on gdm since 2.22, the redhat guys who work on it have other focus this cycle apparently
[09:09] <mdz> seb128: do you know of a page anywhere which lists the known regressions?
[09:09] <kirkland> tseliot: following a reboot, I'm in gnome using nvidia
[09:10] <kirkland> tseliot: this is the 173 driver, with the xorg.conf you saw earlier
[09:10] <seb128> mdz: http://live.gnome.org/GDM/ToDo
[09:10] <kirkland> tseliot: I am now going to press my luck and try the 177 driver ;-)
[09:10] <mdz> seb128: thank you
[09:10] <seb128> you're welcome
[09:11] <tseliot> ﻿kirkland: ah, then rmmod nvidia and modprobe nvidia would have done the trick. A reboot did it.
[09:11] <tjaalton> kirkland: so you had the old kernel and nvidia module loaded?
[09:11] <tjaalton> echo :)
[09:11] <Q-FUNK> tjaalton: console-setup is not the default in debian, afaik
[09:11] <kirkland> must have been....
[09:12] <tjaalton> Q-FUNK: ok, thought so
[09:15] <asac> pitti: tested and uploaded nspr_4.7.1+1.9-0ubuntu0.8.04.5_source.changes nss_3.12.0.3-0ubuntu0.8.04.4_source.changes with follow up fix for #245122 to hardy-proposed. let me know when its in, so i can individually verify each bug.
[09:15] <pitti> asac: oh, so it did need a followup fix? o
[09:15] <pitti> k
[09:16] <asac> pitti: for update-manager yes. only dist-upgrade worked
[09:16] <asac> pitti: the last upload drops the conflicts only
[09:16] <asac> on libnss3 and libnspr4 (the old feisty packages built from firefox back then)
[09:16] <asac> pitti: i kept the conflicts in intrepid branch so hopefully those packages get removed when users dist-upgrade to it
[09:18] <kirkland> tseliot: okay, fyi, the 177 nvidia driver works too
[09:18] <kirkland> all that's remaining is that splash appears to be broken
[09:18] <tseliot> kirkland: great. Thanks for testing it
[09:19] <kirkland> tseliot: no prob, thanks for helping me fix it
[09:21] <seb128> pitti: are we supposed to use hunspell or myspell dictionnaries in intrepid?
[09:21] <pitti> seb128: hunspell if available, but myspell dicts should work with libhunspell
[09:22] <seb128> pitti: installing hunspell-fr removes thunderbird, is that expected?
[09:22] <pitti> erm, no?
[09:22] <pitti> Conflicts: thunderbird
[09:22] <pitti> WTH?
[09:22] <asac> urgh
[09:22] <asac> whats that?
[09:22] <pitti> hunspell-fr
[09:23] <asac> yeah. but why conflicts?
[09:23] <seb128> dunno
[09:23] <asac> maybe that was added to force use of myspell?
[09:23] <pitti> it has versioned conflicts to firefox, etc., but the tbird one is unversioned
[09:23] <seb128> that's what I'm asking
[09:23] <asac> (while back)
[09:23] <gnomefreak> thats new
[09:23] <asac> did we sync it?
[09:23] <seb128> asac: openoffice.org-dictionaries (1:2.4.0~m240-2ubuntu1) intrepid; urgency=low
[09:23] <seb128>  -- Chris Cheney <ccheney@ubuntu.com>  Tue, 01 Jul 2008 20:54:35 -0500
[09:23] <pitti> asac: no, it's 2ubuntu1
[09:24] <seb128> well, it has been merged not to long ago
[09:24] <asac> hmm ... most likely the conflict comes from debian
[09:24] <asac> from back when we renamed thunderbird to icedove
[09:25] <pitti> right
[09:25] <asac> let me check
[09:25] <seb128> otherwise installing myspell-fr didn't work in evolution, it didn't list french
[09:25] <seb128> hunspell-fr works correctly though
[09:25] <asac> seb128: yes. the icedove conflict is versioned?
[09:25] <asac> then we should just use the same version imo
[09:25] <asac> for tbird
[09:26] <seb128> asac: yes, icedove (<< 2.0.0.0-4)
[09:26] <asac> yes. debian has unversioned conflict on tbird
[09:26] <asac> seb128: the same versoin should be fine for us then
[09:27] <asac> though i didnt do that package back then here
[09:27] <asac> but it should
[09:27] <asac> and since we are far ahead, that shouldnt matter anyway
[09:27] <seb128> alright
[09:28] <asac> seb128: can you test?
[09:28] <seb128> test what?
[09:28] <seb128> hunspell spell checking in thunderbird?
[09:28] <asac> if hunspell-fr works fine :)
[09:28] <asac> thought you already installed it.  if not i can do that
[09:28] <seb128> I'm reinstalling thunderbird
[09:29] <seb128> I did install hunspell-fr to get evolution spell checking working
[09:29] <seb128> which removed thunderbird
[09:29] <seb128> a minute, it's downloading
[09:29] <asac> right. please force it. i am not 100% sure if we added a patch to icedove 2 for that or if that was in 1.5
[09:29] <seb128> I'll force the install to test
[09:31] <davmor2> asac: I don't know whether you caught this one or not https://bugs.edge.launchpad.net/ubuntu/+source/ubufox/+bug/253762 ? I thought I'd let you know asap though so it could get fixed :)
[09:35] <seb128> asac: yes, spellchecking works fine in thunderbird when hunspell-fr is installed
[09:40] <asac> seb128: good.
[09:40] <asac> thanks
[09:45] <ion_> benc: You’ve got mail. Btw, Cc: cking@ubuntu.com bounced.
[09:48] <lifeless> mvo: syntax error:P
[09:51] <mvo> lifeless: *cough* that comes from editing source code before the first cup of tea
[10:35] <pitti> thekorn: good morning
[10:36] <thekorn> hi pitti
[10:36] <pitti> thekorn: was the API break in bug 254556 deliberate (cleanup) or just a glitch?
[10:38] <thekorn> pitti, honestly, it was not a glitch
[10:39] <thekorn> but I understand that this is unfortunate,
[10:39] <thekorn> so, I think the best way is to recreate Bug.Error
[10:40] <pitti> depends on how ugly it is to reinstate it, I guess
[10:41] <thekorn> pitti, there are a few more changes: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/changes_0.3
[10:41] <thekorn> pitti, i will think about it later today, and comment on this bug
[10:42] <pitti> thekorn: ah, thanks for that
[10:43] <pitti> thekorn: alternatively I need to switch to a more stable branch in the retracers, and cherrypick the html screenscraping fixes myself
[10:43] <thekorn> pitti, I'm working on integrating launchpadlib into py-lp-bugs
[10:43] <thekorn> so no need for screenscraping anymore
[10:44] <pitti> thekorn: oh, already? great!
[10:45] <ion_> What kind of API does launchpad offer?
[10:45] <pitti> ah, https://code.edge.launchpad.net/launchpadlib is new to me
[10:45] <ion_> REST?
[10:47] <pitti> ion_: yep
[10:47] <ion_> Neat
[10:59] <pitti> kees: hm, your recent "fix bold fonts in the terminal" made things much worse for me; did you hear other reports about regressions?
[10:59] <pitti> kees: (before it looked just fine)
[11:00] <Ng> pitti: erk, worse how?
[11:01] <pitti> some characters, like 'm' now look very untidy
[11:02] <ion_> Yeah, m became noticeably uglier recently.
[11:07] <pitti> kees, Ng: http://people.ubuntu.com/~pitti/tmp/boldfonts.png
[11:08] <Ng> huh. is the patch being carried in Intrepid?
[11:09] <pitti> I just remember that kees recently uploaded something to intrepid, but I forgot the package name; easy enough to find out again, I guess
[11:09] <norsetto> asac: guess what I'm going to ask you?
[11:10] <bigon> hi, is there any reason that ffmpeg in intrepid doesn't contains anymore the h263 encoder by default
[11:10] <bigon> https://bugs.launchpad.net/ekiga/+bug/254201
[11:11] <Spads> pitti: .. ical gekommen?
[11:11] <pitti> Spads: that's a small part of my IRC window, I just moved it there to avoid copying my entire screen
[11:12] <pitti> kees: can't find it right now, which package was that?
[11:13] <Ng> his font patch ought to be in libvte
[11:13] <pitti> ah, indeed
[11:37] <asac> norsetto: update?
[11:38] <asac> norsetto: i have a huge backlog ... saw that i had a mail or two from you
[11:38] <asac> norsetto: if its important tell me ;=
[11:38] <norsetto> asac: I was just going to ask if you received an email from me ;-)
[11:39] <asac> even two iirc
[11:39] <norsetto> asac: its gnome-mplayer 0.6.3-2 which closes the ftbfs if built twice in a row bug
[11:39] <asac> my mail server was down for a week ;)
[11:39] <asac> norsetto: ah cool. you have it uploaded?
[11:40] <norsetto> asac: yes, its in mentors, link in my email
[11:40] <norsetto> asac: Justin Case: http://mentors.debian.net/debian/pool/main/g/gnome-mplayer/gnome-mplayer_0.6.3-2.dsc
[11:43] <asac> norsetto: i dont have my debian system here. might take a few days till i can access that again :(
[11:43] <norsetto> asac: well, what other choice do I have?
[11:44] <asac> norsetto: stand still ... i might be able to do it on Wed if all works out well
[11:44] <asac> if it takes longer we need to find some other sponsor
[11:44] <norsetto> asac: I won't move ;-) Danke!
[11:44] <asac> np
[12:23] <tjaalton> hmm, shouldn't attached media be automatically umounted if the user yanks the device out without ejecting it?
[12:27] <ogra> yep
[12:27] <ogra> and you should get a "unsafe device removal" msg
[12:27] <persia> What if the file cache is dirty?  How about if the user reinserts it later?  What about cases where there's no physical removal event reported by the HW?
[12:28] <tjaalton> I've seen the same media being listed by df/mount on two different machines, and another user reported that the media was shown on the desktop (but inaccessible of course)
[12:28] <ogra> persia, i doubt you can do anything for the latter case
[12:29] <persia> ogra: Well, the Luddite in me likes to say we should train users to unmount before ejecting as a workaround, but you're probably right :)
[12:33] <ogra> the ltsp developer in me says we should have a way to overcome unmounting ;)
[12:34] <hwilde> embedded me says we should make the device manufacturers guarantee reads and writes and not corrupt even if stupid users eject
[12:34] <persia> ogra: Well, we could stop supporting removable media...
[12:34] <ogra> well, we could switch the whole system to ltspfs :P
[12:35] <ogra> (which doesnt support unmounting)
[12:35] <persia> And is nicely atomic.  Still means one needs to shut down to remove the USB key.
[12:37] <ogra> ??
[12:37] <ogra> no
[12:37] <persia> Maybe a udev hook on device removal into ltspfs to kill the FUSE?
[12:38] <ogra> you just yank it out if the progressbar of your filemanager is gone
[12:38] <ogra> ltspfs devices are always unmounted ... only while write operations are in progress they are mounted
[12:39] <Mithrandir> ogra: so they're not POSIX, then
[12:39] <Mithrandir> as in, it's not a POSIX file system.
[12:39]  * persia reads LtspFSAutomount, having obviously missed something
[12:39] <ogra> Mithrandir, they are whatever FS is on the device ... ltspfs sits on top, its a network FS
[12:39] <ogra> persia, the documentation is a bit sparse ...
[12:40] <Mithrandir> ogra: that's irrelevant.  Or do you wait until all files are closed before you umount?
[12:40] <ogra> yes, indeed
[12:40] <persia> ogra: Very much so.  I'll take your word about the umounting, as I can't see any documentation that indicates it's safe to pull a device and reinsert later, while preserving user semantics.
[12:40] <ogra> actually they are forcefully closed until they change
[12:40] <Mithrandir> that's even worse, then.
[12:40] <persia> The only issue is the 2 second sleep cycle while background mounting devices on each new read.
[12:41] <Mithrandir> since you can't open file, unlink file, continue reading and writing and then the file goes away when you close it.
[12:41] <ogra> Mithrandir, not in the ltsp case where we have the guarantee that only the one user on the terminal acesses them ...
[12:41] <ogra> other users cant acess the devcie
[12:42] <persia> ogra: What takes down the FUSE filesystem on device removal?  Is there another udev rule not listed under "udev intereaction"?
[12:42] <ogra> so even if you pull out the device while openoffice is still open you will have a saved copy of the changes of the last two seconds
[12:43] <ogra> persia, right, there are two udev rules
[12:43] <ogra> one for mounting, one for unmounting
[12:44] <persia> ogra: In practice, how noticeable is the 2 second delay?
[12:44] <ogra> not at all
[12:44] <persia> Hmm...  Not going to happen in the next 24 days, but tempting to add to the agenda for the next UDS.
[12:44] <ogra> and i havent had any reports of dataloss or anything within the three years we use ltspfs in ltsp
[12:45] <persia> Well, I can construct a scenario that generates data loss or data corruption, but it would do that with the current model as well.
[12:45] <ogra> in fact its an assembly of autofs, fuse and some glue
[12:45] <ogra> you could do similar things locally with autofs afaik
[12:46] <persia> Yes, but you still want the FUSE layer to provide the atomicity
[12:46] <ogra> right
[12:46] <persia> (Otherwise Mithrandir's comments suddenly become relevant)
[12:46] <ogra> and the caching of the device contents
[12:47] <persia> Well, for local, I'm not sure full caching is so important: imagine inserting a 700MB CD on a 384MB RAM system.
[12:47] <persia> Caching of open files is critical for atomicity, but that's only one file at a time.  Might choke on some DVDs though.
[12:48] <persia> (Depending on the cell progression definition, etc.)
[12:48] <ogra> it wouldnt cache 700M :)
[12:49] <Mirv> mvo: ubuntu ddtp stuff would seem to work. the omissions wrt Debian are probably because of different versions or Ubuntu-specific changes to package descriptions
[12:49] <ogra> just the directory structure ... so it appears transparently to the user while not being mounted
[12:49] <mvo> Mirv: aha, nice. happy to hear that
[12:50] <ogra> the ltspfs client side pretends that the device is mounted all the time ... for that you need to cache the structure, but not the actual content
[12:51] <Mirv> mvo: what about the gnome-app-install's title (shown in list and detailed view) and description (shown only in the list) strings, are they coming from .desktop file's Name and Comment or where? what about commonly seen stuff like gstreamer codecs, are they untranslatable at the moment (eg. "Gstreamer ffmpeg video plugin" and "Codecs to play mpeg, divx, mpeg4, ac3, wmv and asf files" strings)?
[12:54] <Mirv> (since those don't have .desktop files)
[12:56] <mvo> Mirv: the name and comment come from the desktop files in app-install-data
[12:56] <mvo> Mirv: good point about the codec stuff, I think I need to add some magic to make that app-install-data package iimportable into launchpad
[12:56] <mvo> Mirv: feel free to file a bug about that
[12:57] <Mirv> mvo: ok, I'll do that
[12:57] <mvo> Mirv: thanks!
[13:03] <persia> ogra: Ah.  That makes more sense.
[13:05] <Mirv> (bug 254628)
[13:15] <Keybuk> not for the first time, I wonder what wyciwyg:// means
[13:34] <persia> Keybuk: What you cee is what you get
[13:34] <ogra> when you cry i whack you gently ?
[13:35] <Keybuk> persia: all I see whenever I see those URLs is a white page and a spinner
[13:36] <persia> Keybuk: Which browser?  epiphany loads them for me.
[13:36] <Keybuk> epiphany
[13:36] <persia> Hrm.  Maybe because I'm still running hardy?
[13:36] <Keybuk> as am I
[13:36] <Keybuk> http://stephenfry.com/blog/
[13:37] <Keybuk> click "Read full column »" for the second article ("Well worth the wait")
[13:37] <Keybuk> same in Firefox
[13:37] <persia> Hmm.  For that one I'm getting a spinner.
[13:38] <persia> I had a couple from liferea earlier that worked (although I forget which, but noticed as I had a browser crash at the same time, and needed to recover the session)
[13:39] <persia> Ahhh....  "What you cache is what you get"
[13:45] <persia> Keybuk: Looking a bit deeper, it seems that it's an AJAX call that fails on the cache load.
[13:45] <persia> Link from the column title (above) works if you just want to read.
[13:46] <Keybuk> yeah, I can read it
[13:46] <Keybuk> I just loaded it in Safari instead
[13:50] <persia> Safari has a GNOME client?
[13:51] <Keybuk> well, epiphany-webkit is close
[13:52] <Keybuk> but I just used safari itself
[13:52] <Keybuk> not on GNOME :p
[13:52] <persia> Oh, I see.
[13:52] <ion_> Ew. MacOSX has even worse font rendering than what Ubuntu has nowadays. :-)
[14:00] <pitti> tkamppeter: can I somehow tell the openprinting.org DB to just give me packages with PPDs, not those which update ghostscript etc.?
[14:01] <pitti> tkamppeter: I think it'll lead to nothing but trouble to replace system packages with the alienized rpms, we should rather provide them in -backports and make jockey look for those; but packages with PPDs would be perfect
[14:01] <pitti> tkamppeter: I know that I can query for the PPD *files*, and for packages, but I don't know how to query for PPD-only packages
[14:32] <hwilde> where is the default runlevel specified now that inittab is gone
[14:33] <ion_> hwilde: inittab ;-)
[14:33] <pitti> hwilde: /etc/event.d/rc-default if inittab isn't there any more
[14:34] <ion_> hwilde: See /etc/event.d/rc-default
[14:34] <hwilde> there we go
[14:34] <hwilde> gracias amigos
[14:52] <tkamppeter> pitti, do you mean driver packages?
[14:53] <tkamppeter> pitti, there are no PPD-only packages (yet).
[14:54] <superm1> pitti, since that bug in lrm/lbm was resolved re wl, could you provide me with your handler to test out with it?
[14:54] <tkamppeter> Packages like CUPS, Ghostscript, ... will never come as answer to a driver query.
[14:55] <superm1> i didn't see it in any (apparent) locations in your bzr branches
[14:56] <tkamppeter> pitti, package manager info coming with query answers is always only for a repository containing that particular driver, so no danger of unwished replacement of CUPS, Ghostscript, ...
[14:56] <pitti> superm1: it's on http://people.ubuntu.com/~pitti/tmp/jockey-wl/
[14:56] <superm1> pitti, ah okay thanks
[14:56] <pitti> tkamppeter: right, but I saw e. g. a new gutenprint package there
[14:57] <tkamppeter> pitti, should the drivers perhaps all get renamed, with the package name and all files linked into places outside /opt preceeded by "lsb-"?
[14:58] <pitti> tkamppeter: that'd still install two gutenprint versions in the system, no?
[15:00] <tkamppeter> pitti, yes this would only avoid conflicts. And in printer lists in s-c-p they would be recognizable by different NickNames, with version number, "LSB", ...
[15:01] <tkamppeter> s-c-p would have to point to the downloaded LSB version after a download so that the user gets his downloaded driver.
[15:01] <pitti> tkamppeter: hm, that might be preferable in the future, but I think it'd require a discussion on a ML first
[15:01] <pitti> tkamppeter: do you plan to eventually provide packages of PPD files? (as we discussed in London with Tim)
[15:01] <tkamppeter> pitti, on which ML?
[15:02] <pitti> tkamppeter: some openprinting.org, and driver-backports maybe?
[15:04] <tkamppeter> I can make a script which does such PPD-only packages, and the query API has already the possibility to filter by architecture, So a requester could give "noarch" as architecture and not the architecture which the system actually is. This would lead to only packages without binary executables being listed.
[15:14] <superm1> pitti, i'll give feedback over email
[15:25] <RainCT> pitti: Hi. Perhaps I'm missing something but I've just noticed that manpages-de's copyright file (, beside being generate at build time by joining debian/copyright.in and upstreams COPYRIGHT, what I'm not sure if it's allowed,) doesn't contain any copyright information, just a "look at the files" notice (http://paste.ubuntu.com/34055/plain/) and that some of the files are released under the GPL but that there isn't any copy of it included in the
[15:25] <jpds> RainCT: You got cut off at the end.
[15:26] <RainCT> jpds: what's the last word that arrived?
[15:26] <jpds> included in th...
[15:26] <RainCT> ... included in the source. Perhaps  you could you have a look at it?
[15:26] <pitti> RainCT: indeed, thanks for spotting; could you please report that as a Debian bug?
[15:27] <pitti> RainCT: I guess the list of copyright holders is the translators list, but that should be clarified
[15:27] <RainCT> pitti: sure. with severity critical?
[15:27] <pitti> RainCT: I'd use 'serious'
[15:28] <RainCT> OK
[15:28] <pitti> RainCT: danke
[15:31] <RainCT> pitti: is the "generated at build-time" part allowed?
[15:31] <pitti> RainCT: it's not common, but there are several packages which do that
[15:31] <pitti> RainCT: it should be done on clean, not on build, though
[15:31] <pitti> so that the one in debian/copyright is always up to date when building/uploading the source
[15:32] <RainCT> it's in binary-indep
[15:42] <ogra> asac, did warren contact you ? he wanted to set up a nspluginwrapper ML snce upstream doesnt seem to run one
[15:52] <asac> ogra: nope ... well. still havent finished reading all mail though
[15:52] <ogra> heh
[15:53] <ogra> yeah, i still munch on over 2000 mails in ubuntu-users that piled up while i was travelling ...
[15:53]  * ogra knows how that feels
[15:54] <hwilde> you are like bruce almighty
[15:54] <hwilde> select all, grant prayer
[15:54] <ogra> haha
[15:55] <ogra> i sometimes do that, especially with that list ... but there were some conflicts before i left that i'd like to follow so i have to read them this time
[15:56] <ogra> but to much work atm to even care
[16:10] <warren> ogra: I'm giving upstream a chance to respond before I do this.
[16:22] <ogra> warren, ah
[16:28] <asac> bryce: there?
[16:30] <upstream> just do it
[16:30] <hwilde> ;)
[16:33] <hwilde> is there any way to benchmark or speedtest the usb subsystem?
[16:34] <hwilde> i think my 1.0 and 2.0 controllers are freaking out man
[16:34]  * hwilde misses good ol serial ports
[16:41] <hwilde> anybody know what usbmon is for?   /lib/modules/2.6.24-16-generic/kernel/drivers/usb/mon/usbmon.ko
[16:42] <hwilde> or how to make it go
[16:43] <StevenK> hwilde: It's used to snoop or monitor USB buses, the documentation for it is in linux-doc
[16:44] <hwilde> StevenK, I can't seem to make it say anything anywhere.    I have mounted debugfs as instructed
[16:45] <StevenK> hwilde: You don't see anything in /sys/kernel/debug/usbmon
[16:45] <StevenK> ?
[16:45] <hwilde> StevenK, it made some files but what are they
[16:45] <hwilde> they are all zero filesize
[16:46] <hwilde> ? is right
[16:46] <pitti> could someone please do "ck-list-sessions | grep display" and /msg me the result?
[16:46] <StevenK> hwilde: They're sockets. The kernel will dump stuff into them.
[16:46] <StevenK> pitti: On Hardy or Intrepid?
[16:46] <pitti> doesn't matter
[16:47] <hwilde> StevenK, oh...
[16:47] <pitti> StevenK: merci
[16:47] <StevenK> pitti: No trouble :-)
[16:47] <StevenK> hwilde: The documentation suggests using 'cat' :-)
[16:47] <hwilde> yeah I'm just not seeing anything there
[16:48] <StevenK> hwilde: Are you doing something with the bus?
[16:54] <kees> pitti: still around?  Package is "vte".
[16:54] <pitti> kees: good morning! yup, I figured it out by now
[16:55] <kees> from your boldfonts.png, I'm not clear on what I'm looking at.
[16:55] <Spads> kees: ical gekommen!
[16:55] <pitti> kees: look at the 'm's, they look really bad
[16:56] <kees> pitti: that's the actual bold face for that font.
[16:56] <Spads> pitti: it's an improvement over this: http://zork.net/~nick/screenshots/pretty-colors.sized.png
[16:56] <pitti> kees: weird, I never noticed that before your change
[16:56] <kees> pitti: correct, before, it wasn't actually using bold faces.
[16:57] <kees> pitti: and Spads's example is the problem I fixed -- double-strike is not bolding.  ;)
[16:57] <tkamppeter> seb128, hi
[16:57] <pitti> kees: ok; well, I just thought you had an idea about it
[16:57] <Spads> the 'm' turned into a block, and the compression on "Ed" was way too tight
[16:58] <kees> I have a very long analysis here: http://www.outflux.net/blog/archives/2008/06/22/bold-fonts-in-libvte-gnome-terminal-terminator/
[16:58] <kees> (well, the analysis is in the linked blog post from a year ago)
[16:58] <kees> pitti: this is basically a 7 year old bug in vte
[16:58] <kees> (that I believe I have fixed now)
[17:00] <kees> pitti: as another example of the wrongness of double-strike: http://www.outflux.net/fixed-font-comparison.jpg see the "CAP" faces
[17:00] <mathiaz> Koon: I've looked at my suggestion wrt to handling webapps ?
[17:01] <Koon> mathiaz: yes. I pushed all webapps in /usr/share/<package-name>/<webapp-name>
[17:01] <hwilde> StevenK, I think I am doing something with the bus....  do you know what the numbers mean 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u  ?  I am seeing stuff out of the sockets now but which is which
[17:02] <mathiaz> Koon: excellent
[17:04] <StevenK> hwilde: The numbers are the bus numbers, and the characters are the format of the data. All of this is explained in the documentation.
[17:04] <hwilde> StevenK, where is this magical documentation world where all my questions are already answered
[17:11] <StevenK> hwilde: In the linux-doc-2.6.24 package, usbmon.txt
[17:11] <hwilde> StevenK, tnx im on server version no extra frills like that
[17:12] <StevenK> hwilde: Or http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt
[17:15] <hwilde> man I feel like heisenberg now
[17:15] <hwilde> as soon as I modprobe usbmon, the errors are not happening anymore
[17:22] <lunartear> has ubuntu not updated bind9 to 9.3.5-P1  on Ubuntu 6.06.1 LTS Dapper to patch the "DNS Insufficient Socket Entropy Vulnerability."?
[17:22] <kees> lunartear: it has been updated, yes.  we backport fixes rather than doing full-version updates usually.
[17:23] <lunartear> kees, odd i thought i had backports enabled
[17:23] <lunartear> hmm doublechecks
[17:23] <kees> lunartear: "backports" is not an official repo with security support.  You just want -security: http://www.ubuntu.com/usn/usn-622-1
[17:25] <lunartear> can i enable a repo for security?
[17:26] <kees> lunartear: -security is a repo.  :)  there's release, -updates, and -security.  (and -backports, but it does not have security support)
[17:26] <lunartear> deb http://security.ubuntu.com/ubuntu dapper-security main restricted   is enabled
[17:26] <kees> lunartear: then you're in good shape.
[17:27] <lunartear> hrm.. perhaps im checking the version improperly then..  apt-cache showpkg bind9?
[17:27] <lunartear> is that whats installed or whats available
[17:27] <jdstrand> lunartear: apt-cache policy bind9
[17:28] <jdstrand> (it will show what's available and what's installed)
[17:28] <lunartear> yeah im not seeing 9.3.5 listed
[17:28] <kees> lunartear: as I mentioned, we patch release versions with upstream fixes rather than doing full version bumps.  You're safe if your bind's version matches the version here: http://www.ubuntu.com/usn/usn-622-1
[17:29] <lunartear> oh alright... that confused me
[17:29] <lunartear> I should be patched then
[17:30] <lunartear> that patches the dns cache poisoning vulnerability right?
[17:30] <kees> lunartear: cool, yeah -- it can be a bit confusing.  if you're interested, the security updates are announced here: http://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce
[17:30] <kees> lunartear: correct.  that vulnerability is also known as CVE-2008-1447
[17:31] <lunartear> great thanks for clarifying
[17:32] <lunartear> kees, is that list low traffic?
[17:32] <lunartear> nvm it says low traffic on the page.. i just didnt see it
[17:32] <kees> lunartear: yeah, it's got maybe a dozen or more posts a month: https://lists.ubuntu.com/archives/ubuntu-security-announce/2008-July/date.html
[17:33] <pitti> slangasek: so, I sorted out the pam_ck_connector/gdm interference, so that I can now use common-session
[17:34] <pitti> slangasek: what's the recommended way of adding that in the postinst/removing in prerm now? sed? a-c-c profile and call from postinst? block on pam-config-framework implementation?
[17:34] <pitti> slangasek: or using sed/a-c-c for now until p-c-f is implemented?
[17:35] <pitti> jdstrand: ^ would like to hear your opinion as well
[17:36] <jdstrand> pitti: yea for common-session
[17:36] <hwilde> StevenK, do you know about this usbmon stuff or are you just good with the linux docs
[17:37] <pitti> jdstrand: ? you mean I should use a-c-c now?
[17:37] <jdstrand> pitti: well, sed wouldn't be policy compliant, and a-c-c could be, if we develop a policy. that said, slangasek's spec will obviate this use-case of a-c-c
[17:38] <pitti> jdstrand: why wouldn't sed be policy compliant, out of interest?
[17:38] <StevenK> hwilde: The latter
[17:38] <jdstrand> pitti: we should develop a policy compliant way to call a-c-c if slangasek isn't done in in time
[17:40] <bryce> morningh
[17:40] <jdstrand> pitti: oh right, I lost my head for a second-- I was thinking common-session was a conffile
[17:40] <pitti> jdstrand: I see that sed would be brittle and not really elegant, but in terms of Policy compliance a-c-c and sed shouldn't make a difference?
[17:40] <jdstrand> pitti: it was login that was the conffile
[17:40] <pitti> jdstrand: ah, ok
[17:40] <bryce> asac, what's up?
[17:40] <pitti> jdstrand: right, otherwise I'd have used login straight away
[17:41]  * jdstrand nods
[17:41] <pitti> but now I patched pam_ck_connector hard enough to cope
[17:42] <mdz> this is the third time I've found that acpid has mysteriously died on my desktop
[17:42] <mdz> has anyone else noticed this?
[17:42] <mdz> it's easy to tell when it happens because of this:
[17:42] <mdz> 7.9M /var/log/Xorg.0.log
[17:42] <pitti> mdz: does it trigger apport for you? I don't have any recorded crash here
[17:42] <jdstrand> pitti: my opinion is to wait for slangasek-- if it doesn't work out, then I'd be more than happy to help with a safe way to use a-c-c in maintainer scripts for the general case
[17:43] <mdz> pitti: no, it doesn't
[17:43] <pitti> jdstrand: ok, thanks
[17:43] <mdz> pitti: and I wasn't able to catch it with gdb when I left it attached overnight
[17:43] <mdz> pitti: gdb showed it had received SIGTERM but I couldn't tell from where or when
[17:52] <pitti> slangasek: ok, please let me know what you prefer (using sed now, and finish my spec, or blocking on p-c-f and doing the auto-enabling after feature freeze)
[17:53] <mdz> pitti,mvo: I just had a package update fail in update-manager (file overwrite error) but it didn't generate a crash report
[17:54] <kirkland> Keybuk: hiya, what time does the update run on merges.ubuntu.com to look for updated packages in debian-unstable?
[17:55] <mdz> mvo: I'd like to report the bug but can't find a log anywhere
[17:58] <mdz> is linux-restricted-modules-envy-2.6.24 useful in addition to the dkms-ified packages?
[17:59] <Keybuk> kirkland: hourly
[18:00] <kirkland> Keybuk: interesting... okay, so ecryptfs-utils-53-1  hit debian-unstable 2 days ago, but it's not showing up on merges.ubuntu.com
[18:00] <Keybuk> it's out of disk space I think
[18:01] <kirkland> Keybuk: it was recently promoted (last week) from universe to main, if that might cause a hiccup
[18:03] <mdz> doko: I just saw a file conflict in the latest dovecot update, but unfortunately lost the error message (see above)
[18:04] <kirkland> Keybuk: the disk space issue, is that something you can solve, or do I need to ask elmo or someone?
[18:05] <Keybuk> kirkland: it's been on IS's plate for a couple of years now
[18:06] <mdz> Keybuk: about 1.3 years
[18:07] <mdz> Keybuk: and it was marked resolved until today
[18:09] <Keybuk> it was, errantly
[18:09] <Keybuk> I unresolved it when I realised that the ticket had in fact been closed
[18:09] <Keybuk> as I'm sure you remember, the attempt to add more disk hit hardware failure, and was never, in fact, completed
[18:15] <Chipzz> lunartear: also, for future reference, this is not a support channel. please ask these questions in #ubuntu in the future
[18:16] <lamont> heh.  requestsync should handle the case where the current-ubuntu version of the package does not exist in changelog by doing something more intelligent than copying all of debian/changelog
[18:31] <tkamppeter> seb128, ping
[18:31] <seb128> tkamppeter: if you want a reply better to give some context in your pings
[18:31] <asac> bryce: i have a system with a logitech bluetooth mouse - which doesnt work out of box with livecd and not after install. any hints how i can set that up?
[18:32] <tkamppeter> seb128, sorry, I wanted to see at first whether you are really here.
[18:32] <tkamppeter> seb128, it is about printing output of GTK/GNOME-based apps.
[18:33] <tkamppeter> seb128, did you already do the changes on the GTK library so that all these apps produce PDF when sending a print job?
[18:33] <elmo> Keybuk: that's not strictly accurate, it was in fact upgraded, just not to .5Tb
[18:33] <seb128> no
[18:33] <seb128> am I supposed to do that?
[18:34] <tkamppeter> seb128, yes, as then we get a much more stable and reliable printing (did you not remember from London?).
[18:35] <seb128> I remember you saying that need to be changed
[18:35] <Keybuk> elmo: right, but I thought that was only a temporary measure?
[18:35] <seb128> but there is no open bug or spec assigned to me for that as far as I know
[18:35] <tkamppeter> With PDF as printing output the printing system can always separate, re-order, scale, select and otherwise manipulate pages. With PostScript this is not always possible.
[18:35] <bryce> asac, which driver are you using for it?
[18:36] <Keybuk> elmo: I'm not blaming you for any inactivity btw; since the ticket wasn't open
[18:36] <tkamppeter> There is a spec on the PDF printing workflow. Should I add a bug with link to the spec.
[18:36] <bryce> asac, fwiw, we're right in the middle of switching input-hotplug on; possibly if you wait a day or two for the dust to settle, it may just work
[18:37] <elmo> Keybuk: I'm not sure - I thought you were happy with the space as is, but I may well be wrong and clearly failed to update the ticket to even document the problems we had with the .5Tb drive configuration
[18:37] <ogra> bryce, do you know how far input-hotplug will support touchscreens ?
[18:37] <tkamppeter> seb128, https://blueprints.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format
[18:38] <bryce> ogra: no I don't - it's woefully underdocumented.  (I similarly don't have a clear idea on if it supports bluetooth).  However I understand that it *should* support both, so any problems would be handled as regular bugs.
[18:38] <ogra> bryce, i noticed now that i have seen more than two touchscreen devices that they all tend to use /dev/input/eventX and was wondering if we couldnt unify that to have a /dev/input/touchscreen link put in place by an initscript
[18:38] <seb128> tkamppeter: right, this spec is not assigned to me so technically I'm not the one supposed to do those changes
[18:39] <ogra> that would ease configuration a lot i bet, but i dont know how much it would clash with hal-input or related functionallity
[18:39] <tkamppeter> seb128, All apps outputting PDF would even eliminate all PostScript page management problems even if there are no special PDF filters (see today's mails where I CCed you).
[18:40] <Keybuk> ogra: why do you need a symlink?
[18:40] <tkamppeter> seb128, so I should assign you to the spec? In reality there are many people where each one has to do a certain part.
[18:40] <Keybuk> elmo: I think I said I'd be happy for a year ;)
[18:40] <ogra> Keybuk, because the eventX can differe from system to system ...
[18:40] <Keybuk> elmo: though MERGE MONSTAH WANTS MOAR DISK PLZ
[18:40] <Keybuk> ogra: but why do you want the symlink?
[18:41] <tkamppeter> seb128, or should I post bugs then, one per person who is supposed to do something and link them all to the spec.
[18:41] <bryce> ogra: what needs to know that?
[18:41] <seb128> tkamppeter: talk to whoever is supposed to approve the spec to get it assignee to somebody
[18:41] <ogra> Keybuk, having something that unifies all touchscreens to /dev/input/touchscreen by something like that: http://paste.ubuntu.com/34122/ will make it easier to have a common configuration
[18:41] <seb128> tkamppeter: I can try to have a look this cycle but my schedule is already pretty much booked
[18:41] <bryce> ogra: afaik they're trying to get away from permanently named devices since you get conflicts with multiple of the same device hooked up
[18:42] <Keybuk> ogra: but what configuration?
[18:42] <ogra> bryce, curretly i see a lot of evtouch devices that have very unique configs and all tend to differ in the devce name in xorg.conf
[18:42] <ogra> if hal-input fixes that, then fine
[18:42] <Keybuk> doesn't input-hotplug solve this by taking away the need for configuration entirely? :)
[18:42] <ogra> if not i'D like to have a unified device name all touchscreens can use
[18:42] <Keybuk> how can all touchscreens use it at the same time?
[18:43] <ogra> Keybuk, well, i dont see *any* attempt to include touchscreens in hal-input yet
[18:43] <ogra> *sigh*
[18:43] <tkamppeter> seb128, is it very complicated to switch GTK printing output from PostScript to PDF?
[18:43] <ogra> tochscreens on different systems indeed
[18:43] <seb128> tkamppeter: no idea I don't know this code
[18:43] <ogra> i.e. my laptops touchscreen uses event10
[18:43] <pitti> mdz: l-r-m-envy> no, it's not, that upload was for hardy
[18:43] <ogra> my Q1 uses event2
[18:43] <ogra> etc etc
[18:43] <Keybuk> ogra: I can tell you exactly how long before a device comes out with two touchscreens
[18:43] <Keybuk> about one week after we ship code that assumes only one :p
[18:44] <mneptok> input-hotplug is not a suitable topic for a development channel. please abide by the CoC, and stop arousing support geeks.
[18:44] <ogra> well, then you can have touchscreen1 and 2
[18:44] <tkamppeter> seb128, the Qt/KDE apps already output PDF, Riddell has only changed some config setting.
[18:44] <Keybuk> and then *those* will swap
[18:44] <ogra> still better than having to have a specific configuration for each and every combo
[18:44] <mdz> pitti: ah, of course, thanks
[18:44] <Keybuk> ogra: attach the configuration to the particulars of the device
[18:44] <Keybuk> not to some assumed name
[18:44] <Keybuk> ie. "the touchscreen that is 640x480 is configured as ..."
[18:45] <seb128> tkamppeter: how is that revelant there?
[18:45] <ogra> Keybuk, yes, thats what  would expect from hal-input
[18:45] <Keybuk> that's what I would expect too
[18:45] <ogra> but i dont see anything going on there ... whih means we'll have to stick to xorg.conf for such devices until its solved
[18:45] <ogra> at least thats what i expect for intrepid
[18:46] <Keybuk> have you tested it?
[18:46] <Keybuk> things may just work out of the box without need for special configuration
[18:46] <ogra> heh
[18:46] <Keybuk> I doubt touchscreens are sufficiently different from other devices to need their own?
[18:46] <ogra> i doubt thats true for touchscreens
[18:46] <ogra> they need calibration
[18:46] <Keybuk> so do joysticks and tablets
[18:46] <ogra> at least the first time you use them
[18:46] <ogra> and also for tap events
[18:47] <Keybuk> so do touchpads
[18:47] <ogra> all touchpads i had yet worked fine as mice ... touchscreens wont
[18:47] <ogra> they need special treatment and i dont see that happening yet
[18:48] <Keybuk> you can always contribute the special treatment patch, remember
[18:48] <Keybuk> hal-input is not large
[18:48] <ogra> sure
[18:48] <emgent> heya
[18:48] <mneptok> Keybuk: ping MagicFab. his touchscreen cannot function until a calibration method is found. he has filed LP bug reports, IIRC.
[18:49] <mneptok> ogra: ^^
[18:49] <Keybuk> mneptok: xorg.conf provides this calibration method?
[18:49] <mneptok> Keybuk: it does not
[18:49] <asac> bryce: err, its hardy still :)
[18:49] <asac> bryce: how do i find out which driver is used? i just tried to use what happens by default
[18:50] <ogra> Keybuk, if he can use the evtouch driver it is possible but massively painful to do it in xorg.conf
[18:50] <Keybuk> mneptok: then I don't see how that contributes to the discussion
[18:50] <asac> which is not much. the bluetooth symbol appeared on desktop ... but input is enabled and it doesnt find the mouse
[18:50] <mneptok> Keybuk: mouse accel and other X settings do not affect the screen, IIRC
[18:51] <ogra> mneptok, do you know if his touchscreen functions but is only miscalibrated ?
[18:51] <mneptok> ogra: exactly that
[18:51] <ogra> then chances are good that he cn solve it with a bit of effort
[18:52] <Keybuk> the only reason to have a /dev/your/mom is for easy access
[18:53] <Keybuk> and as a key for a configuration database of some kind
[18:53] <Keybuk> if you're doing configuration, you should use a better key than a name, since names change
[18:54] <Keybuk> most devices have uniquely identifying information, such as a serial number
[18:54] <Keybuk> and if not, at least semantically identifying
[18:54] <ogra> right thats the problem and thats why i wanted a unified name :)
[18:54] <ogra> device names change
[18:54] <ogra> so if i work on mobile and have ten different devices i need to suport i need ten different hardcoded configs atm
[18:55] <Keybuk> no, you have ten different dynamic configs
[18:55] <ogra> currently not
[18:55] <Keybuk> this is #ubuntu-devel
[18:55] <Keybuk> currently is uninteresting ;)
[18:55] <ogra> i need to know as which event device the touchscreen registers in which hw config
[18:56] <ogra> thats one difference among all devices that could be solved by devce name unification
[18:56] <Keybuk> so just iterate input devices for touchscreens
[18:56] <ogra> well, not all touchscreens give you the right info ...
[18:57] <Keybuk> they give you enough information to map to your configuration db
[18:57] <ogra> my laptop sees my touchscreen actually as touchpad, thats what the device identifies as
[18:57] <Keybuk> imagine a scenario
[18:57] <Keybuk> where /dev goes away entirely
[18:57] <ogra> if i wouldnt know the manufacturer and that it actually is a touchscreen it couldnt tell which one is touchpad and which one is screen
[18:58] <Keybuk> and instead you just have a "magic path" to a device that open() understands
[18:58] <Keybuk> if you start relying on device names being uniquely identifying, you will be broken by that change
[18:58] <ogra> right
[18:58] <Keybuk> if you bully up now and deal with the fact that there are many input devices on a system, which are many different types
[18:58] <Keybuk> and each one may need its own configuration
[18:58] <ogra> but if the device per se doesnt give any useful info about itself how is hal supposed to handle it correctly ?
[18:58] <Keybuk> then you will not be broken by that, or any other, change
[18:59] <Keybuk> if the device has no useful information, how is _anything_ supposed to handle it correctly?! :)
[18:59] <Keybuk> "Generic Input Device on USB Hub #1 Port #2"
[18:59] <bigon> infinity, are you around plz?
[19:00] <Keybuk> assuming it's internal, that's sufficient for a configuration db as a fallback when you have no serial number, etc.
[19:00] <ogra> wll, i can hande it manually through xorg.conf by finding out thet IDEACO is a touchscreen manufacturer, calibrating it manually and after computing the values against my screensize i can then add 20 lines to my xorg.conf ...
[19:00] <Keybuk> you can do that in HAL
[19:00] <Keybuk> HAL can have an FDI file that tells it that IDEACO is a touchscreen
[19:01] <ogra> right
[19:01] <Keybuk> and then the settings daemon can use that to look up the configuration for the device and apply the calibration
[19:02] <Keybuk> the great thing being that this then works if you have two touchscreens ;)
[19:02] <Keybuk> and you can change the calibration on the fly
[19:02] <Keybuk> and all sorts of "omg, it's the end of the dark ages" goodness
[19:02] <ogra> indeed, i know how is *supposed* to be :)
[19:02] <ogra> *its
[19:02] <Keybuk> then what's the argument? :)
[19:02] <ogra> i dont see it happening yet
[19:03] <Keybuk> *make* it happen ;)
[19:03] <Keybuk> you know how to code, and use patch, and stuff
[19:03] <Keybuk> :p
[19:03] <ogra> heh, do you have some spare hours you can send me ?
[19:03] <Keybuk> I'm in sore need of them myself
[19:05]  * ogra lols on a sidenote, reading the hal ML and OLPC people complaining that battery polling breaks their sound 
[19:07] <Keybuk> (and we all know that if a short-term hack of a symlink name was added, nobody would *ever* do the work to stop using that because there would be always other things to do, and then you'd complain and bitch when it stopped working later down the line because such things become impossible)
[19:08] <ogra> well, proper would be to do it in a wider scope like having some code that handles i and then colect lshal output from users to get fdi files together but i simply miss the time for such a project
[19:08] <ogra> *handles it
[19:10] <Keybuk> isn't that the hardware database? :p
[19:10] <ogra> ask the maintainer :P
[19:11] <ogra> i havent touched the hardware db since i work for canonical ... (apart from minor ui fixes)
[19:12] <Connecting> HEY PEOPLE
[19:13] <ogra> and luckily it was removed from the archive in intrepid
[19:13] <Connecting> OK OK I GET IT
[19:13] <Connecting> shut the
[19:13] <Connecting> f up
[19:13] <Connecting> :P:
[19:13] <tomaw_> Connecting: enough, thanks :)
[19:14] <Connecting> :P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P
[19:16] <Connecting> ok...
[19:18]  * Connecting wonders to himself ''where did everyone go?''
[19:18] <bryce> asac, anyway I don't have bluetooth devices myself, but it sounds like using either hidd to set it up dynamically, or configure it manually in xorg.conf (using evdev) might work.  An example of a static config with settings specified is here:  http://ge.ubuntuforums.com/showthread.php?p=5365458
[19:19] <mvo> mdz: could you please check if /var/log/apt/term.log contains the error?
[19:19]  * Connecting asks himself where did all these nerds come from?
[19:19] <mdz> mvo: it does, thanks
[19:19]  * Connecting does not get an answer
[19:20] <mdz> mvo: oddly, the mtime on that directory didn't change when I ran the update, I guess only when the logfile is rotated
[19:20] <ogra> thanks
[19:20] <mvo> mdz: oh, interessting
[19:21] <mdz> mvo: any idea why there's no crash report?
[19:21] <stgraber> then change Drupal's ACL to only let people with that same role access everything else
[19:21] <stgraber> > _______________________________________________
[19:21] <mvo> mdz: not sure, I will check
[19:21] <stgraber> sorry, buggy touchpad+irssi ...
[19:22] <mdz> doko: bug 254721
[19:22] <mvo> mdz: it didn't generate anything at all in /var/crash? or was it just not picked up by update-notifier
[19:22] <mdz> mvo: nothing in /var/crash
[19:22] <mdz> mvo: it did pop up the error dialog to show me the error
[19:22] <mdz> mvo: then I closed it, thinking I would get a crash report to submit
[19:23] <lukehasnoname> who do I bug about getting new nvidia drivers into Hardy?
[19:23] <mvo> mdz: and that is for #254721 ? I will try to reproduce it
[19:24] <mdz> mvo: yes
[19:24] <lukehasnoname> tseliot? I know I talked to someone before and they said "It would be too much change for an LTS" but, isn't hardware support one of the few things we update on LTS?
[19:24] <mdz> mvo: do you want dpkg.log or anything else?
[19:25] <mdz> lukehasnoname: we do updates for hardware compatibility in LTS, but in a fairly strict way (only for things which we are explicitly trying to support) rather than updating any driver which has a new release
[19:25] <mvo> mdz: it should be fine, I like the term.log best because it contains the shell output of failed postinst too (not relevant in this case of course)
[19:25] <mdz> lukehasnoname: ubuntu-devel-discuss@ is probably the place to discuss it
[19:25]  * mvo walks out for a bit again and has a look when he is back
[19:25] <mdz> mvo: emailed
[19:26] <tkamppeter> seb128, the idea is to replace PostScript by PDF as print job format.
[19:28] <tkamppeter> seb128: Up to now there is implemented: foomatic-rip takes also PDF as input, CUPS filters for PDF processing (upstream, package will come soon), KDE/Qt apps output PDF.
[19:30] <tkamppeter> seb128, missing parts are: foomatic-db-engine should produce PPDs for both PS and PDF (my student works on it, will come soon), GTK/GNOME apps and OOo need to output PDF
[19:47] <seb128> tkamppeter: I understand the issue, we just need somebody to do the change and I've lot of things, and I've lot to do already so I'm not sure I'll do that this cycle
[20:11] <geser> @archive admins: is it an oversight that libmtp8 ended in universe as the source and libmtp-dev is in main?
[20:13] <seb128> geser: things land by default in universe if nobody override those
[20:14] <seb128> geser: if there is a main package which requires it, it'll be listed on the component mismatch summary
[20:15] <seb128> geser: you can also tell us if it requires promotion now
[20:15] <geser> seb128: it is: Reverse-Depends: libmtp-dev
[20:15] <seb128> geser: ok, I'll fix it, thanks for pointing the issue
[20:16] <geser> thanks
[20:20] <slangasek> pitti: block on pam-config-framework, please; I made good progress over the weekend, I think I'll have a usable prototype by end of next week (can't promise it this week, and next week is intermittent due to DebConf)
[20:23] <warren> Is Intrepid still using util-linux + tons of patches
[20:23] <warren> or util-linux-ng?
[20:23] <Spads> Ng: I didn't know you wrote a util-linux!
[20:27] <tseliot> ﻿lukehasnoname: the drivers in Hardy are updated through envyng and the -envy flavour of the restricted modules.
[20:33] <mvo> mdz: I can repriduce the dovecot failure, but for me a apport file is written, I will try a bit more to reproduce why it was not written for you (what happens if you run /usr/share/apport/package_hook --package dovecot-imapd < /dev/null?)
[20:39] <ogra> warren, we use -ng
[20:40] <ogra> or better debian moved and we followed afaik
[20:43] <ogra> warren, switched over on  Tue, 10 Jul 2007 by lamont apparently
[20:43] <lamont> ogra: util-linux-ng _is_ upstream
[20:43] <ogra> lamont, right
[20:44] <ogra> i just wasnt sure because we call the binary until-linux
[20:44] <lamont> as of, oh, gutsy
[20:44] <lamont> I refuse to upload a package with '-ng' in the name
[20:44] <ogra> yeah, thats what the changelog says :)
[20:45] <lamont> Ng already has a big enough head. :-p
[20:45] <ogra> lol
[20:45] <lamont> besides, if we did that, we'd need to s/ipv6/ipng/ everywhere...
[20:45] <lamont> since "ng" really just means "oh, btw, we overhaulled it, kthx"
[20:46] <warren> lamont: oh hey
[20:47] <lamont> hey warren
[20:47] <warren> lamont: i'm trying to figure out how debian LTSP without union mounts can mount stuff without the /etc/mtab~number error messages
[20:47] <warren> just sent you an e-mail
[20:47] <lamont> ah, mk
[20:47] <warren> lamont: vagrantc said debian has code to handle that more smoothly?
[20:48] <lamont> interesting, since the only diff between ubuntu and debian is volume detection stuff
[20:48] <lamont> which will shift to common-ground superseding both in 2.15 ish, I expect - it's a topic branch upstream atm
[20:49] <warren> lamont: I work on Fedora
[20:49]  * lamont still has about 45 min of work day left, then gets to play catchup on devel stuff, and run out the door for a week of family vacation, all without his wife killing hm
[20:50] <slangasek> asac: am I right in recalling that the reason for the divergent nss/nspr sonames is that upstream doesn't actually track backwards-incompatible changes on these libs, rather than that we've made ABI-divergent changes to them?
[20:50] <lamont> warren: git clone  git://git.debian.org/~lamont/util-linux.git
[20:50] <lamont> warren: that's based off of the util-linux-ng tree
[20:51] <warren> lamont: do you know where in the code might have stuff to handle this problem?
[20:51] <lamont> not sure - ISTR a 'patches' branch which was a cleanup of all the patches debian has
[21:04] <Riddell> pitti: how come apport is enabled=0 by default?
[21:11] <slangasek> Riddell: it should be off by default in released versions, and on by default in devel versions; I think it was also disabled for a while recently in intrepid because the retracer was broken?
[21:12] <Riddell> seems to still be disabled, according to my new chroot
[21:12] <slangasek> then I guess it still needs uploaded for that
[21:24] <lukehasnoname> tseliot: Sorry for being an asshat, I remember you telling me that
[21:24] <tseliot> ﻿lukehasnoname: no problem ;)
[21:24] <slangasek> what's the name of that package in universe that people use to mangle their grub setups unrecognizably? :)
[21:26] <lukehasnoname> What does the official Ubuntu install DVD have on it? Does it have desktop AND server? Live AND text-based install? What makes it different?
[21:27] <Nafallo> all of main
[21:27] <Nafallo> alternative and server I think
[21:29] <slangasek> it doesn't provide a server installation
[21:29] <lukehasnoname> aw :(
[21:29] <slangasek> it's a "liveCD", i.e. installs are done by copying the running environment to the install target rather than by debootstrapping packages
[21:30] <slangasek> (it's also fully localized, which makes the livefs image HUGE)
[21:30] <ogra> doent it provide the d-i install anymore ?
[21:30] <ogra> it used to
[21:31] <lukehasnoname> 'cause I was going to use it if it gave me server + alternate, since I don't use live install, and a one-disc solution for all my computers (server and laptop) would be nice
[21:32] <slangasek> ogra: it might have a copy of the d-i initramfs on it; it doesn't have enough packages on the image to support a full install by that method, without recourse to network
[21:32] <ogra> ah, th elast DVD  tested had both install variants (gutsy iirc)
[21:32] <Nafallo> ogra: same here :-)
[21:33] <Nafallo> but feisty I thnk
[21:33] <lukehasnoname> there is probably a reasonably easy way to wrap a server and an alternate install on one dvd
[21:33] <lukehasnoname> though it would be inefficient in space
[21:33] <ogra> well, you could remaster a CD and just pull on it what you like
[21:34] <ogra> up to you if you fil it or not
[21:34] <ogra> *fill
[21:34] <slangasek> ogra, lukehasnoname: er, oh; my mistake, checking a current DVD, it looks like all the base packages are there to do a d-i install
[21:35] <slangasek> I'm not sure whether server is included in that
[21:35] <lukehasnoname> d-i?
[21:35] <slangasek> "alternate installer"
[21:35] <ogra> alternate install
[21:35] <ogra> snap :)
[21:38] <ogra> slangasek, btw, did you look for startupmanager ?
[21:38] <slangasek> ah, that's the one, thanks
[21:46] <mdke> I'd like to politely bump an sru - does commenting on the relevant bug help at all, or is it just a matter of the sru team working through their subscription list so that commenting won't make a difference?
[21:48] <slangasek> what do you mean by "bump"?
[21:48] <slangasek> bump it up, or bump it out? :)
[21:49] <mdke> slangasek: bring it politely to someone's attention
[21:49] <mdke> maybe, get it into someone's bug email (if that's relevant to the sru team's workflow) or something else
[21:50] <slangasek> mdke: right, if there's not a reason that the SRU is somehow critical, then it's already on the radar; at least when I'm doing SRU work, I iterate through the web views, the email is too scattered to be useful to me for that
[21:50] <slangasek> ("if there's not a reason that the SRU is somehow critical" --> "unless there's a specific reason it needs to be jumped ahead in the queue")
[21:51] <mdke> slangasek: ok, that's what I figured. It's not critical, but it's quite old so it's enough for me to know that it's still on the radar :) thanks
[21:51] <slangasek> what's the bug number?  just to make sure it's labelled properly
[21:51] <mdke> it's bug 243823, although it's not labelled at all, I just subscribed the sru team
[21:56] <mdke> bbiab, just nipping out to the shop
[22:01] <doko> slangasek: please could you accept openjdk-6 into hardy-proposed (in NEW, comes with a new -dbg package)
[22:06] <slangasek> mdke: ok - if ubuntu-sru is subscribed, that's the important thing then, thanks
[22:06] <slangasek> doko: ack, will look at it in a bit
[22:06] <doko> thanks
[22:07] <joaopinto> hello
[22:08] <joaopinto> Can someone review and advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
[22:09] <emgent> hello
[22:14] <asac> slangasek: yes. i talked about this with nss developers at summit
[22:15] <asac> slangasek: if we have good reasons they would be willing to reconsider their approach
[22:15] <joaopinto> ops, i was on the wrong channel :P
[22:15] <asac> which of course doesnt mean much
[22:25] <asac> slangasek: to clarify: upstream only adds new symbols. they dont break compatibility - by policy. so in the end this whole thing prevents downgrade issues - which probably can be questioned.
[22:34] <mdke> slangasek: thanks
[22:58] <NCommander> seb128, ping
[22:58] <seb128> NCommander: hi
[22:58] <NCommander> seb128, get the message on updated system-monitor?
[22:59] <seb128> NCommander: no
[22:59] <NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/254776 - and all your updates are belong to us ;-)
[22:59] <seb128> cool :-)
[22:59] <NCommander> seb128, next on the list ;-)?
[22:59] <seb128> want an another one to do now? ;-)
[23:00] <NCommander> seb128, I'd like to see a day zero turn around time for GNOME
[23:00] <NCommander> ^'s release
[23:01] <seb128> NCommander: want to do gnome-applets or still not having the bandwith to download the build-depends?
[23:01] <NCommander> seb128, let me see
[23:02] <seb128> NCommander: otherwise http://download.gnome.org/sources/sound-juicer/2.23/sound-juicer-2.23.1.tar.gz
[23:02] <NCommander> seb128, its at the two hour mark, I can wait that long
[23:02] <NCommander> I'll attack soundjuicer in the meantime
[23:02] <seb128> cool
[23:03]  * NCommander is the patch-nator ;-)
[23:03] <NCommander> seb128, how many packages are left to update? (is there some sorta master list?)
[23:04] <seb128> NCommander: no real master list, I'm subscribed to the GNOME ftp list which lists tarballs uploads
[23:04] <seb128> there is not too many of those
[23:04] <NCommander> handy
[23:05] <NCommander> My bandwidth issues are still bad; I can't even work on REVU since uploading to my PPA is officially crawling -_-;
[23:06] <m0u5e> is ext4 going to be implemented in future versions of ubuntu (any time soon?) :)
[23:06] <NCommander> seb128, too many of what?
[23:06] <NCommander> seb128, easy ones?
[23:06] <Nafallo> m0u5e: dep-waits kernel I'd say.
[23:06] <NCommander> m0u5e, I thought it was already in the kernel, aka, in the current version of the text-mode installer
[23:07] <seb128> NCommander: no, tarballs to packages, I spent my day on those so did a good part of the updates while they were coming
[23:07] <Nafallo> NCommander: marked stable now?
[23:07] <m0u5e> ah
[23:07] <NCommander> Nafallo, I thought it was just in the kernel mainline
[23:07] <Nafallo> # CONFIG_EXT4DEV_FS is not set <-- dev suggests it's not
[23:08] <Nafallo> 2.6.24-20-generic, no idea about intrepid
[23:08] <NCommander> Nafallo, which means if it is, you can install Ubuntu on it (if you don't mind using the command line to manually format and mount the parition at /), although GRUB might need an update to boot off ext3
[23:08] <NCommander> *ext4
[23:08] <Nafallo> NCommander: it's not in hardy's kernel.
[23:09] <NCommander> Nafallo, I guess its a matter of compiling your own kernel then
[23:09] <NCommander> Which isn't that difficult, then you need to rebuild d-i, and more fun
[23:10] <NCommander> Nafallo, Well. Insert foot in mouth. Turn 90 degrees anticlockwise
[23:16] <m0u5e> whats the next ubuntu version after intrepid?
[23:17] <jcristau> it's intrepid+1
[23:17] <ogra> intrepid+1
[23:17] <m0u5e> if there is no name, i volunteer Jamming Jackdaw, with a focus on fixing linux sound :)
[23:17] <ogra> 9.04 as well :)
[23:19] <m0u5e> hmm animals that begin with J are hard...
[23:20] <m0u5e> any comments on Jamming Jackdaw, the the proposed feature goal? :)
[23:21] <NCommander> Jumping Jackrabbits :-)
[23:21] <NCommander> or Jumpy Jackrabbits
[23:21] <m0u5e> Jealous Jaguar
[23:21] <m0u5e> lol
[23:22] <NCommander> possible brb
[23:22] <m0u5e> what would the feature goal be for jumping jackrabbits?
[23:22] <m0u5e> ultra portability? lol
[23:22] <slangasek> Javalí
[23:23] <ScottK> Jiggly Jello - Given the traditional source of gelatin, it ought to count.
[23:23] <m0u5e> it needs to be adj+animal
[23:23] <m0u5e> jello is not alive (at least not where I live)
[23:24] <m0u5e> and what would the feature goal be for Jiggly?
[23:24] <m0u5e> to make wobbly windows even more "wobbly?"
[23:25] <ScottK> If you cleaned out your refigerator as often as I do mine, it would be (alive).
[23:25] <m0u5e> lol
[23:26] <ogra> and wear a hair tie :)
[23:26] <m0u5e> i'd laugh if our ideas actually got published for the next version
[23:53] <seb128> NCommander: still around?
[23:53] <ogra> seb128, gcc 2.x ?? woah
[23:53] <seb128> ogra: ?
[23:54] <ogra> your last upload mentions it in the changelog
[23:54] <ogra>  - Fix build with gcc 2.x
[23:54] <ogra> i wouldnt belive anyone still uses that :)
[23:54] <seb128> ogra: ah right, there is a guy upstream who likes to fix those bugs, not sure why
[23:55] <ogra> heh
[23:55] <seb128> usually he fixed c99 syntaxs
[23:56] <ogra> oh my ... if he can do that he should really go after serious bugs ...
[23:56] <seb128> those are usually easy bugs
[23:58] <NCommander> seb128, ?