[00:08] <bluefoxicy> [0x40f239] malloc(10)                            = 0x1959fe0
[00:08] <bluefoxicy> [0x40661c] free(NULL)                            = <void>
[00:08] <bluefoxicy> [0x40f239] malloc(2016)                          = 0x1958550
[00:08] <bluefoxicy> is there any way to turn this into a source code line number?
[00:08] <bluefoxicy> (first hex number is the instruction pointer at time of the call)
[00:12] <RAOF> bluefoxicy: If you install the dbgsym packages for ls and such the backtrace at any point should include linenumbers, IIRC.
[00:13] <bluefoxicy> RAOF:  that didn't  come from gdb
[00:13] <bluefoxicy> I'm not sure how to script gdb...
[00:22] <RAOF> Oh.  That'll be a strace, right?
[00:23] <bluefoxicy> yeah
[00:23] <bluefoxicy> ltrace but
[00:23] <bluefoxicy> I want to extract every call to malloc(), free(), and realloc() from an application, timestamped
[00:44] <PovAddict> hey
[00:44] <PovAddict> did anyone see what I said about translations?
[00:45] <PovAddict> that everything started showing in English since I upgraded the language packs and nobody seems to *care*?
[00:51] <TheMuso> PovAddict: Where did you point this issue out, and have you filed a bug or checked if there have been any bugs filed about the issue?
[00:51] <PovAddict> I pointed it out here and mentioned the ID of the bug I issued
[00:51] <PovAddict> #316174
[00:51] <PovAddict> er, filed
[00:51] <PovAddict> whatever
[00:52] <TheMuso> Ok as long as a bug is filed, it will be attended to.
[01:54] <PovAddict> so annoying... does *everybody* here just use the desktop in English?
[01:55] <Hobbsee> unlikely
[01:57]  * Hobbsee blinks
[01:58] <Hobbsee> PovAddict: it's less likely that people here still run hardy, fwiw.
[01:59] <PovAddict> upgrading means learning a whole new desktop environment
[01:59] <PovAddict> KDE3 -> KDE4
[02:00] <Hobbsee> this is true
[02:00] <Hobbsee> hm, interesting.
[02:01] <Hobbsee> as a workaround, i'd suggest you install version 1:8.04+20081124
[02:02] <PovAddict> strange thing with the -base packages
[02:03] <PovAddict> a 20090105 version is listed but not shown as an upgrade
[02:04] <PovAddict> what's the logic to decide if a package is upgradeable? :/
[02:04] <Hobbsee> use a dist-upgrade on it
[02:04] <Hobbsee> that one contains files, it appears
[02:05] <PovAddict> aptitude dist-upgrade says there is nothing to do
[02:06] <Hobbsee> strange.
[02:07] <Hobbsee> PovAddict: oh, and it's in proposed, btw, so may not show on packages.ubuntu.com
[02:07] <Hobbsee> (it hasn't been pushed to everyone, fortunately)
[02:07] <PovAddict> hmm why did I get it? I have -proposed in my sources.list but it's set in... some way so that it's not used by default
[02:07] <Hobbsee> set in... some way so that it's not used by default?
[02:08] <PovAddict> they supposedly don't show unless I do aptitude -t hardy-proposed
[02:08]  * Hobbsee shrugs, being relatively unfamiliar with teh internals of aptitude.  I usually lock things at dpkg level, so it works everywhere, if i want to do that
[02:09] <PovAddict> it was done by editing /etc/apt/preferences
[02:09] <PovAddict> I don't understand how it works though :)
[02:09] <PovAddict> Package: *
[02:09] <PovAddict> Pin: release a=hardy-proposed
[02:09] <PovAddict> Pin-Priority: 400
[02:10] <PovAddict> anyway, I just downgraded the four packages i had upgraded before
[02:10]  * Hobbsee wonders if aptitude even follows apt's preferences file
[02:10] <LaserJock> should
[02:11] <PovAddict> well it has worked before :)
[02:11] <PovAddict> I also have hardy-backports there, and I'm sure they don't show unless I "-t" ask for it
[02:11] <PovAddict> aptitude -t hardy-backports shows two dozen upgradeable packages right now (that don't show otherwise)
[02:12] <PovAddict> oops, I meant -proposed in that last message
[02:12] <PovAddict> backports shows even more :)
[02:25] <ghostcube> hi i have a question and i didnt get an answer it seems on 64 bit intrepid the /usr/lib/libGl.so link to the libGl.so.180.11 isnt set
[02:26] <ghostcube> its set in the lib32
[02:26] <ghostcube> should i add it manually
[02:26] <TheMuso> ghostcube: didn't get an answer where?
[02:26] <ghostcube> #ubuntu #kubuntu
[02:27] <TheMuso> ghostcube: Considered checking whether a bug has been filed about this? If there isn't one, I suggest you file one.
[02:27] <ghostcube> i looked and i didnt find anything useful
[02:27] <TheMuso> ghostcube: Is this problem causing applications to malfunction/not function at all?
[02:28] <ghostcube> i cant compile compiz it claims missing libGl
[02:28] <ghostcube> so i think this could cause problems
[02:28] <TheMuso> ghostcube: You need to install the development files for the nvidia libraries.
[02:28] <TheMuso> sorry why did I get nvidia mixed up in all of this? :S
[02:28] <ghostcube> hmm then it removes the libgl1-mesa-dev and the libgl1-common-dev
[02:29] <TheMuso> ghostcube: is there any reason why you need to compile compiz?
[02:29] <ghostcube> iam just supporting in channel so i need the newset versionmostly from git
[02:29] <TheMuso> don't mind me and what I said rei nvidia.
[02:29] <TheMuso> Ok, I suggest you run "sudo apt-get build-dep compiz" which will install everything you need.
[02:29] <ghostcube> yeah but this wont fix the prob its just an missing symlink
[02:30] <ghostcube> as it seems
[02:30] <TheMuso> ghostcube: How do you know it won't fix it? Have you tried it?
[02:31] <ghostcube> try what ? it worked fine i just tried to compile from git
[02:31] <ghostcube> and i get the missing liGl error
[02:32] <ghostcube> i need the git version of compiz the master not the apt-get source builds
[02:34] <PovAddict> do you know what build-dep does?
[02:34] <ghostcube> it cathces all dependencies for the build
[02:37] <ghostcube> i dont want to stress i am just wondering if the symlink is  missing
[02:37] <ghostcube> thats all :)
[02:40] <TheMuso> ghostcube: No, its in a -dev package somewhere. I am not sure which one because I'd  need to check what package the file belongs to.
[02:40] <ghostcube> i checked it with apt-file
[02:40] <ghostcube> it belongs to libgl1-mesa-dev
[02:40] <TheMuso> Its Debian/Ubuntu policy to keep those symbolic links in the development packages only, as they are not needed for normal use.
[02:40] <ghostcube> and this is installed
[02:40] <TheMuso> Ok.
[02:41] <ghostcube> and if i want to install the nvidia-glx-180-dev  which contains the same file it will remove the libgl1-mesa-dev
[02:41] <ghostcube> is this the problem maybe ?
[02:42] <TheMuso> I don't know enough about those packages to comment.
[02:42] <ghostcube> me too :|
[02:42] <ghostcube> and it seems no one else in channels around iam asking since 4 hours now
[02:43] <ghostcube> noo one has any idea
[02:43] <ghostcube> nah 7 hours
[02:43] <ghostcube> boah late
[07:04] <dholbach> good morning
[07:04] <ion_> That
[08:20] <soren> Keybuk:
[08:20] <soren> Whoops
[08:33] <soren> 14:57 < Keybuk> soren: I'm reverse-thinking here
[08:33] <soren> 14:57 < Keybuk> we should probably just copy of all of /etc/udev/rules.d into the initramfs
[08:34] <soren> 14:58 < Keybuk> though that might break things since we don't copy hardly any of /lib/udev/rules.d
[08:34] <soren> 14:59 < Keybuk> or
[08:34] <soren> Keybuk: I don't understand that last line.
[08:34] <soren> 14:59 < Keybuk> copy anything not in /lib/udev/rules.d
[08:34] <soren> 14:59 < Keybuk> and copy anything in /lib/udev/rules.d *if* it has been copied into the initramfs
[08:36]  * soren wonders if Keybuk is actually here at this hour
[09:22] <dholbach> can we move imlib2 to universe?
[09:22] <dholbach> to me it looks like all rdepends live in Universe
[09:23] <slangasek> have you checked component-mismatches and/or germinate?
[09:23] <dholbach> slangasek: erm, no
[09:24] <slangasek> imlib2 doesn't show up on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt, which means there's something else in main that (build-)depends on it
[09:25] <dholbach> hm
[09:25] <slangasek> http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.jaunty/all shows that w3m build-depends on it
[09:25] <dholbach> ah, good to know
[09:28] <dholbach> thanks slangasek
[09:37] <Hobbsee> anyone know where pitti is?
[09:39] <directhex> Hobbsee, germany?
[09:39] <slangasek> "elsewhere" this week :)
[09:39] <Hobbsee> directhex: I knew that, but thanks :)
[09:39] <directhex> Hobbsee, :p
[09:40] <Hobbsee> slangasek: ah.  So, who does one get poked about for a broken hardy-proposed langpack update?
[09:40] <slangasek> me
[09:40] <seb128> Hobbsee: he's on holidays for the week
[09:40] <Hobbsee> slangasek: consider yourself poked on https://bugs.launchpad.net/bugs/316174 then :)
[09:40] <slangasek> also ArneGoetje, who's the one that will have to fix it...
[09:40] <Hobbsee> seb128: thank you
[09:41] <cjwatson> PovAddict: with regard to language packs, the shrinkage in size is entirely expected; the way language packs are structured is that there's an -LL-base which contains most translations, and an -LL which contains some more translations as updates to that; this lets us push out frequent langpack updates with less mirror churn
[09:41] <slangasek> Hobbsee: hrm, surely that's because they've been merged into language-pack-es-base, since that was the purpose of the langpack update?
[09:42] <cjwatson> PovAddict: so what happened in -proposed was that the -LL-base packages were respun to save us CD space, which of course resulted in the -LL packages shrinking down to almost nothing
[09:42] <Hobbsee> slangasek: ahhh, is that the point.  Right
[09:42] <cjwatson> PovAddict: did you upgrade the -base packages as well?
[09:42] <cjwatson> slangasek: from the bug, looks like an insufficiently-tight dependency, though
[09:43]  * slangasek nods
[09:44] <cjwatson> hmm
[09:44] <cjwatson>  Package: language-pack-es
[09:44] <cjwatson>  Depends: language-pack-es-base
[09:44] <cjwatson> and
[09:44] <cjwatson>  Package: language-pack-es-base
[09:44] <slangasek> ArneGoetje: ^^ can you fix that so language-pack-$foo has a versioned dep on language-pack-$foo-base?
[09:44] <cjwatson>  Depends: language-pack-es (>= 1:8.04+20090105), locales (>= 2.3.6)
[09:44] <cjwatson>  Conflicts: language-pack-es (<< 1:8.04+20090105)
[09:44] <cjwatson> but there's a long-standing dpkg bug/lack-of-feature to the effect that Conflicts B->A are not checked on upgrade of A
[09:44] <slangasek> well, surely it's not even that
[09:45] <cjwatson> and of course the old language-pack-es-base is still installed
[09:45] <slangasek> right
[09:47] <cjwatson> -base still seems to be around the expected kind of size
[09:47] <cjwatson> so I don't think we've actually had major translations lossage
[09:48] <Hobbsee> cjwatson: I think he said he couldn't update -base for some reason, so that would work
[09:49] <cjwatson> Hobbsee: he said that it wasn't listed as an available upgrade, and it seemed that aptitude was doing something confusing with pinning
[09:49] <Hobbsee> that was it, yes
[09:51] <slangasek> cjwatson: actually, the -base packages have each grown by 300k or more
[09:52] <slangasek> er, 200k for -en, 400k or more for pt/es
[09:52] <slangasek> which makes sense in terms of post-release translations
[09:52] <slangasek> but poses interesting problems for LTS point releases
[09:53] <cjwatson> they have?
[09:53] <cjwatson> -rw-r--r-- 1 lp_publish lp_publish 3094350 Jun 17  2008 ubuntu/pool/main/l/language-pack-es-base/language-pack-es-base_8.04+20080527.2_all.deb
[09:53] <cjwatson> -rw-r--r-- 1 lp_publish lp_publish 3106094 Jan 10 12:04 ubuntu/pool/main/l/language-pack-es-base/language-pack-es-base_8.04+20090105_all.deb
[09:53] <cjwatson> -gnome-es-base has grown about 40K AFAICS
[09:54] <slangasek> cjwatson: well, I was comparing against 8.04.0
[09:56] <slangasek> because there are packages from 8.04.1 that aren't in the main archive anymore, making it hard to do a full comparison, grmbl
[09:56] <slangasek> (mutter, need to get something set up to record the .deb sizes at image build time)
[09:58] <cjwatson> that's why there's a hardlink tree archive of .1 on cocoplum
[09:59] <slangasek> yeah, but I have the .list files on antimony :)
[09:59] <slangasek> I guess copying those to cocoplum would be the easier route, wouldn't it
[10:21] <cjwatson> calc: ooo3 binaries accepted, enjoy :)
[10:24] <directhex> cjwatson, OOo3 landed in main?
[10:25] <lool> cjwatson: Just FYI I managed to bootstrap rpm with its autogen last Friday, thanks
[10:25] <lool> (had to fix a couple of issues but at least it got the work done)
[10:33] <cjwatson> directhex: yes
[10:33] <cjwatson> lool: ok, cool
[10:37] <lool> Grrr
[10:39] <lool> blkid just fixed itself automagically I hate that
[10:42] <lool> Aha /etc/blkid.tab and /etc/blkid.tab.old
[10:42] <lool> Too bad I already destroyed evidence...
[10:50] <soren> Umm... Where does compiz store its config these days? I change stuff in gconf, but it doesn't seem to take effect.
[10:51] <soren> mvo: ^ ?
[10:53] <lool> soren: I had the same issue; there's also an "ini" backend
[10:53] <mvo> soren: it should be gconf, but sometimes it gets confused and starts using the ini interface. please use ccs and look at the backed settings there
[10:53] <mvo> soren: lower left corner
[10:53] <lool> soren: You can access settings in a backend independent way with the python bindings, but I found addressing individual settings extremely painful
[10:53] <mvo> soren: I thought I had fixed this particular bug during intrepid development though :/
[10:53] <lool> (just borke when I upgraded to jaunty for instance)
[10:54] <soren> I forget... Button2 is the right or middle button?
[10:55] <lool> mvo: I used to set my shortcuts with a script like this one http://people.ubuntu.com/~lool/set-shortcut-config but the way I address the compiz settings broke completely; it there a better way to address settings?
[10:55] <lool> s/it/is
[10:55] <soren> I'm having the most annoying issue with compiz or ccsm or something.
[10:56] <soren> I don't have a middle button, and from Xfce I'm used to alt-rightmousebutton resizes windows. I want to make compiz do the same, but I get bitten by a whole stack of weirdness.
[10:57] <soren> Alt-RightMouseButton brings up the window menu. I never need that, so I just disable it under General in ccsm.
[10:57]  * lool finds it weird that blkid maintains his cache of block device's properties when we have udev and sysfs
[10:58] <soren> When I disable the window menu, compiz seems to pretend that I'm holding down <Alt>.
[10:58] <soren> !
[10:58] <mvo> soren: uhh, let me try to reproduce
[10:58] <soren> To click on things, I need to hold down alt. To drag a window, I need to *not* hold down alt.
[10:58] <soren> mvo: Hang on, I'll reset all my compiz settings.
[10:58] <mvo> lool: does the ccsm "export my settings" help you for your use-case?
[10:59] <soren> I'll nuke ~/.config/compiz (which seems pretty empty anyway)
[10:59] <soren> and to a gconftool-2 --recursive-unset (after grabbing a backup)
[11:00] <mvo> soren: there is a "reset" button in ccsm as well
[11:00] <mvo> (just fyi, your method will/should work too)
[11:00] <soren> Let's just say that I don't trust ccsm very much at this point :)
[11:00] <mvo> soren: you may want to stop compiz before the recursive unset, sometimes the config system tries to be clever :)
[11:01] <soren> mvo: Right, I did it while running metacity.
[11:01] <soren> Ok. Here goes.
[11:02] <soren> I go to the "General" place in ccsm and disable the window menu.
[11:02] <soren> In the "General" tab, third option from the top.
[11:02] <soren> As soon as I do that, it's like my <Alt> key is inverted.
[11:02] <soren> When I try to click on things, it thinks I want to move the window.
[11:03] <soren> When I hold Alt down, I can click on things normally.
[11:03] <soren> If I go to the "Move" plugin.
[11:03] <soren> ...
[11:03] <soren> It clearly says that the initiate button is Button1. No modifier.
[11:03] <soren> That rates at least 5.6 on my weird-stuff-o-meter.
[11:04] <soren> Anyhow, I add <Alt> there..
[11:04] <soren> and my <Alt> button's sanity is restored.
[11:04] <soren> I go to the resize plugin..
[11:05] <soren> And tell it that I want the initiate button to be <Alt>Button3.
[11:05] <soren> It then tells me that the window menu action already uses this combo (even though I disabled it).
[11:05] <soren> I click "Disable Window Menu"
[11:06] <soren> And my <Alt> button is b0rked again.
[11:06] <soren> s/button/key/
[11:07] <soren> I'll try setting the window menu thing to <Shift><Ctrl><Alt><Super>Button9 instead (I'm hoping that won't conflict with anything).
[11:07] <lool> mvo: I guess I could use export/import settings; never tried it; will see what that gives, thanks
[11:07] <soren> What the...
[11:08] <soren> That changed all the modifiers for "Resize window" as well?!?
[11:08] <soren> Madness
[11:08] <soren> I give up.
[11:08] <mvo> soren: let me try that here
[11:09] <soren> I might be doing this all wrong. I just want Alt-RightMouseButton to resize windows.
[11:11] <mvo> soren: I can reproduce that here, I have a look (and/or forward to upstream)
[11:13] <lool> Does someone know what upstream bug tracker e2fsprogs uses?  It seems to be Debian's e2fsprogs source, but I'd like to confirm
[11:14] <cjwatson> I don't know for sure, but I know that Ted follows both Debian's and Ubuntu's bug tracker to some degree; probably pays more attention to Debian's
[11:15] <slangasek> my impression is that he tracks e2fsprogs bugs in LP rather closely
[11:16] <slangasek> hmm.  the edubuntu pod now includes an edubuntu-desktop-kde seed that references an edubuntu-desktop-kde metapackage.
[11:16] <cjwatson> http://ext4.wiki.kernel.org/index.php/Bugs but I'm not sure whether that's only for the kernel side
[11:17] <cjwatson> lool: http://sourceforge.net/tracker/?atid=102406&group_id=2406&func=browse seems to exist too
[11:17] <mvo> soren: as a workaround, please try "preferences" and select the "enable integreation into the desktop environement"
[11:18] <cjwatson> (via e2fsprogs.sourceforge.net)
[11:21] <mvo> soren: please let me know if that works for you (it seems to do the trick for me)
[11:23] <lool> cjwatson: Yeah, I checked bugzilla.kernel.org and came to the main conclusion, and the main e2fsprogs site, and was completely confused
[11:24] <lool> Ok; I'll just Also affect e2fsprogs and ping tso
[11:25] <lool> slangasek: Thanks for the hint
[11:29] <james_w> lool: hey, I see your name in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510673
[11:30] <james_w> lool: there's a sponsorship request open to pull in the removal of the .la from Debian. Do you know why "bio2jack" is the only package that will break from that?
[11:41] <slangasek> james_w: because bio2jack is the only reverse-dep which is also a shared lib shipping a .la?
[11:44] <Laney> iain@intrepid:~/packaging/bio2jack/usr/lib$ grep dependency libbio2jack.la
[11:44] <Laney> dependency_libs=' /usr/lib/libjack.la -lrt -lpthread -ldl /usr/lib/libsamplerate.la -lm'
[11:45] <james_w> yeah, I came out with a huge list of packages when I tried, but I think I used the tools wrong
[11:52] <james_w> I get "libbio2jack0-dev: /usr/lib/libbio2jack.la portaudio19-dev: /usr/lib/libportaudio.la portaudio19-dev: /usr/lib/libportaudiocpp.la libfluidsynth-dev: /usr/lib/libfluidsynth.la libecasound2.2-dev: /usr/lib/libecasound.la"
[11:56] <slangasek> james_w: inspection of libportaudio.la seems to indicate that this lib doesn't depend on libsamplerate
[11:56] <soren> mvo: That's already selected?
[11:56] <soren> mvo: Sorry about the slow reply. compiz sent me to lunch.
[11:59] <tseliot> seb128: I have just fixed a rather annoying bug in nautilus with a simple 3-lines patch. Can you have a look at it, please? http://bugzilla.gnome.org/show_bug.cgi?id=567479
[12:01] <seb128> tseliot: that's a duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=542396
[12:01] <seb128> tseliot: could you add your patch to this one?
[12:02] <tseliot> seb128: sure
[12:02] <seb128> tseliot: I'll try to get upstream to review it
[12:02] <seb128> thanks
[12:03] <tseliot> seb128: ok, done
[12:03] <seb128> tseliot: thanks
[12:03] <tseliot> thank you
[12:21] <james_w> and libiaxclient-dev with /usr/lib/libiaxclient.la
[12:24] <asac> Riddell: any news on the knetworkmanager front? will we get a kde4 version?
[12:50] <Riddell> asac: I'm hopeful but I believe it's not there yet
[12:50] <asac> Riddell: damn. so how bad would another knetworkmanager breakage in alpha 3 be?
[12:51] <asac> Riddell: i have the final 0.7 bits waiting for upload ... knetworkmanager probably will have issues though
[12:53] <Riddell> asac: I guess we'll live with it, are they in the PPA to test?
[12:53] <asac> Riddell: yes
[12:54] <asac> ~network-manager
[12:54] <asac> Riddell: let me know how bad it is .... my guess is a crash ;)
[12:54] <lool> james_w: yes because its *.la files reference the dropped ones
[12:55] <lool> Pff xine-lib is maintained in hg
[12:56] <lool> james_w: It wasn't my recommendation to drop the *.la files; instead I recommended stripping the dependency_libs= line to be empty
[12:57] <lool> james_w: It might affect a different set of packages in Ubuntu than in Debian though; it depends whether our packages shipping *.la files were built against other packages when these used to ship or stopped shipping *.la files
[12:58] <asac> fta: pastebinit is broken in jaunty?
[12:58] <james_w> lool: ah, ok
[12:58] <asac> fta: seems to not honour my .pastebinit.xml anymore
[12:58] <lool> james_w: It might affect more than libjack-*-dev's rdeps, but if it does then these packages were lacking a dep on libjack*-dev
[12:59] <lool> So it should be enough to check whether libjack*-dev rdeps ship *.la files and whether these reference libjack*-dev's *.la files; in theory, this should be done on all arches
[13:01] <james_w> lool: I have a list for i386, checking that rebuilds of them will be sufficient now.
[13:06] <mvo> soren: (sorry for my late reply, I was at lunch :) - please unselect the DE environment integratio
[13:17] <crusader05> ?
[13:19] <soren> mvo: Ooh... Looks promising!
[13:22]  * soren hugs mvo 
[13:22] <soren> mvo: Awesome! It works.
[13:22] <mvo> soren: thanks, I'm created a upstream bugreport and will add a (targeted for beta) ubuntu one too
[13:22] <mvo> soren: thanks for brining this up :)
[13:24] <soren> You bet.
[13:44] <cjwatson> asac: I've just had a two-day saga of getting my 3G modem to work ... none of which was NetworkManager's fault. :-) As soon as I managed to teach the kernel and hal to detect it, NM Just Worked. Nice!
[13:45] <ScottK> slangasek: I just updated  Bug #316262 - It should be removed.  I'd appreciate it if you'd have another look.
[13:45] <cjwatson> somewhat infuriatingly it's twice as fast as my ADSL connection
[13:46] <asac> cjwatson: yeah congrats ;). is that a new modem or did you need to adjust an existing hal entry?
[13:46] <cjwatson> asac: newish modem, it's one of the hso family and needs nasty hacking
[13:46] <asac> urgh
[13:46] <asac> what was needed on kernel side?
[13:46] <asac> cjwatson: ?
[13:47] <cjwatson> asac: deactivating the stupid ZeroCD thing it comes with
[13:47] <asac> heh
[13:47] <asac> yeah
[13:47] <cjwatson> sounds like you're familiar with it already :)
[13:47] <asac> I think the plan is to fix the driver
[13:47] <cjwatson> yes, Dan Williams already sent a patch to do most of that
[13:47] <asac> there is one modem class that already has the fix in the driver
[13:47] <asac> ah ok cool
[13:47] <cjwatson> but it needed a bit further tweaking
[13:47] <cjwatson> I'll send something upstream shortly
[13:48] <cjwatson> shall I CC you?
[13:48] <asac> sure, why not.
[13:48] <siretart> asac: may I ping you about the sunbird/iceowl 0.9 uploads? ;)
[13:49] <asac> siretart: yes ;)
[13:49] <asac> feel free
[13:50] <asac> siretart: i think https://code.edge.launchpad.net/~mozillateam/sunbird/ubuntu-0.x and the iceowl one are really ready for action
[13:51] <asac> i think its now a matter of upload bandwidth here ;)
[13:52] <siretart> ah, I see :-)
[13:52] <asac> siretart: ok building sunbird sources and then will just push i guess
[13:53] <asac> in case something is broken we probably can still fix it before release ;)
[13:53] <asac> siretart: uploading
[13:53] <siretart> cool! thanks!
[13:55] <sabdfl> https://edge.launchpad.net/~ubuntu-dev/+polls
[13:56] <james_w> can't we have both? :-)
[14:08] <cjwatson> Keybuk: so you were talking about how git reset is missing from bzr ... the other way round, do you know how to do 'bzr revert <file>' in git? 'git reset --hard <file>' is what I'd expect but it refuses
[14:09] <cjwatson> (i.e. forget about all changes in index and working tree, but only to certain file(s))
[14:09] <Keybuk> git checkout -- <file>
[14:09] <cjwatson> ah, of course
[14:09] <cjwatson> thanks!
[14:09] <Keybuk> you may need -f there
[14:09] <cjwatson> yeah
[14:10] <cjwatson> fatal: git checkout: updating paths is incompatible with switching branches/forcing
[14:10] <cjwatson> maybe --
[14:11] <cjwatson> ah, just without -f works
[14:11] <cjwatson> obvious UIs 'r' us
[14:12] <Keybuk> heh
[14:12] <Keybuk> ooh, right, -f is when you've already git add'd it
[14:12] <cjwatson> no, I actually need 'git checkout HEAD <file>', and it doesn't DTRT with new files
[14:12] <Keybuk> it's obvious when you see things from git's pov
[14:12] <cjwatson> I *had* already git add'd it
[14:12] <Keybuk> bah
[14:13] <Keybuk> git sucks ;)
[14:13] <cjwatson> no argument from me
[14:17] <Riddell> asac: knetworkmanager appears to work with NM 0.7 from the PPA
[14:18] <asac> Riddell: thx
[14:18] <Riddell> asac: KDE 4 applet still doesn't though alas
[14:19] <cjwatson> Keybuk: is there a neater way, in hal, to say "match on the contents of this sysfs attribute" than writing a preprobe shell script to fish out the attribute and save it with hal-set-property?
[14:19] <cjwatson> Keybuk: the IHV-written code I have here does the latter, but I notice that nothing in hal or hal-info seems to do anything much complicated with preprobe, which leads me to suspect that I might be on an inelegant track
[14:22] <Keybuk> only in code
[14:23] <Keybuk> you'd have to modify HAL's code to add new sysfs attributes
[14:23] <cjwatson> is that preferred over adding a preprobe script, for something that's insanely device-specific?
[14:23] <Keybuk> I guess
[14:24] <cjwatson> maybe I'll just send a patch to hal-info with the preprobe script and see what David says
[14:24] <cjwatson> less effort if it's a bit ambiguous :-)
[14:24] <Keybuk> hal_util_set_string_from_file (d, "my.little.property", sysfs_path, "wibble")
[14:48] <ArneGoetje> slangasek: about the versioned dependencies on the language-packs: I can try. Since the langpacks are generated by script, the script would need to be ammended to accept the dependent version number as argument...
[14:57] <cjwatson> ArneGoetje: this surely is not a problem since language-pack-LL already has versioned Replaces on various other packages with the correct version numbers
[14:57] <cjwatson> and therefore must have this information already
[14:57] <directhex> cjwatson, you busy?
[14:58] <cjwatson> directhex: sort of, why?
[14:58] <cjwatson> more stack-full than busy if you see what I mean
[14:58] <directhex> debian bug 480020. can you think of any major reason not to insist to novell that they apply the included patch immediately?
[14:59] <ArneGoetje> cjwatson: but not for the -base packages, right?
[14:59] <directhex> i'm having... problems... with servers at work and oom killer
[14:59] <Keybuk> directhex: err
[14:59] <Keybuk> it's correct that the OOM killer adjustment is inherited from parent to child
[15:00] <Keybuk> (most such things are in UNIX)
[15:00] <Keybuk> I guess for ssh, you don't want bash inheriting it?
[15:00] <directhex> Keybuk, quite
[15:01] <cjwatson> ArneGoetje: not as far as I can see but surely isn't a big problem since it's done for the delta packages; you can just follow the same approach
[15:01] <cjwatson> directhex: IIRC there was some later problem as wewll
[15:01] <cjwatson> well
[15:01] <directhex> sodding linux
[15:02] <directhex> where's my hurd tarball gone
[15:02] <cjwatson> directhex: and I didn't even know that Novell had taken the *prior* patch I did to support tweaking the OOM killer in sshd at all
[15:02] <cjwatson> Keybuk: in this context I agree with directhex that it's definitely wrong
[15:02] <Keybuk> cjwatson: yeah, I've had the same problems with ssh with supervision
[15:02] <Keybuk> "sshd is still running because someone once ran screen"
[15:03] <cjwatson> directhex: does Novell set up sshd to run with OOM-killer disabled, then?
[15:03] <cjwatson> directhex: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500121 claims to still have the problem, not debugged yet
[15:03] <directhex> cjwatson, no, they don't
[15:03] <cjwatson> might be user error but as I say I don't know
[15:03] <directhex> cjwatson, if a user uses lots of ram, then bye bye server
[15:03] <cjwatson> oh, right, you're running into the *original* problem
[15:03] <directhex> aye
[15:04] <cjwatson> point them at the upstream bug I guess though I wouldn't blame anyone for not wanting to patch extra features into openssh
[15:05] <directhex> sigh. i just want users who try and use too much ram to have their job killed, and the node ready for the next job. is that so much to ask for? :/
[15:11] <directhex> i'll poke sgi. if novell aren't interested, sgi can always stick a modified rpm on their repo
[15:12] <ArneGoetje> cjwatson: the current Replaces: line has (<< ${Source-Version}) in a skel template. I don't see how this can be applied to the Depends field, since the deltas get higer version numbers than the base package. The script would need to check, which version of the base packages is currently in the archive.
[15:14] <ArneGoetje> cjwatson: or, when rebuilding the base packages, it would set it to ${Source-Version} too.
[15:17] <cjwatson> ArneGoetje: oh, right, I see what you mean
[15:23] <Keybuk> hmm
[15:23] <Keybuk> every LP page for me is popping up that annoying "Some parts are insecure" dialog
[15:23] <Keybuk> is it doing it for anyone else?
[15:26] <tedg> Keybuk: No dialog, but I get a "broken lock" icon.
[15:27] <cjwatson> ArneGoetje: seems to me that the most recent base package version could be saved in bzr somewhere
[15:29] <cjwatson> and then substituted in with the LangpackMacros stuff
[15:29] <ArneGoetje> cjwatson: I think I need to discuss this with pitti, what the most reasonable approach is.
[15:31] <cjwatson> pitti is on holiday, I think
[15:32] <cjwatson> yes, all week. We can't afford to wait a week to resolve a regression in a stable update
[15:32] <cjwatson> (or at least a perceived one)
[15:32] <cjwatson> and waiting a week will cause us to slip 8.04.2
[15:33] <ArneGoetje> cjwatson: this calls for a quick and dirty hack I think...
[15:33] <cjwatson> yeah, I was just having a look to see what would be easier
[15:33] <cjwatson> easiest
[15:40] <cjwatson> ArneGoetje: I'm thinking of something like http://paste.ubuntu.com/103950/ (untested)
[15:41] <cjwatson> i.e. ram the dependency in with a spoon :-)
[15:42] <ArneGoetje> cjwatson: ouch :)
[15:43] <ArneGoetje> cjwatson: that's indeed quick and dirty
[15:43] <cjwatson> obviously with the intention of something better being put in place when pitti gets back
[15:43] <ArneGoetje> cjwatson: of course
[15:43] <cjwatson> e.g. a maps/ file listing the current base versions for each release
[15:43] <seb128> Keybuk: edge does but non-edge doesn't
[15:43] <cjwatson> which would then have to be kept up to date
[15:45] <cjwatson> asac: there's a claim in the ozerocdoff source as follows:
[15:45] <cjwatson>   This changes the network interface of a Option WWAN-modem from the default
[15:45] <cjwatson>   wired network category 802.03 into the new wwan categrory and changes the
[15:45] <cjwatson>   serial control and application port from default category serial into
[15:45] <cjwatson>   the new wwan, debug or gps category need for Network-Manager version 0.7.0
[15:45] <ArneGoetje> cjwatson: that's one possibility, yes. Im thinking, as we have this information available in launchpad, if we could maybe pull it from there...
[15:45] <cjwatson> asac: and it then goes and changes net.80203 to net.wwan across the board
[15:46] <cjwatson> asac: however, by some kind of fluke these FDI rules don't fire for me at the moment, and the device works anyway. On further investigation I find no mention of net.wwan anywhere in NM
[15:46] <cjwatson> asac: is ozerocdoff just on crack?
[15:46] <asac> cjwatson: i think so
[15:46] <asac> cjwatson: NM doesnt look at net.wwan
[15:46] <cjwatson> ArneGoetje: that could be possible longer#-term as well, yes
[15:46] <cjwatson> s/#//
[15:46] <asac> it looks at "modem" capability ;) with V.250 command sets
[15:47] <Joe_CoT> Question: How would I request that Asterisk be moved to main?
[15:47] <asac> and for wired its net.80203 ... wifi net.80211?
[15:47] <cjwatson> asac: this sets GSM-07.07 and GSM-07.05 in modem.command_sets and seems to work as a result
[15:47] <cjwatson> Joe_CoT: https://wiki.ubuntu.com/MainInclusionProcess
[15:48] <asac> cjwatson: yes. that helps NM to know whether its GSM or CDMA
[15:48] <cjwatson> Joe_CoT: it will need developers willing and able to support it
[15:48] <asac> and should be enough
[15:48] <asac> hopefully with modemmanger NM will do auto detection of command-sets so we dont have to do that each and every modem
[15:48] <Joe_CoT> cjwatson, ok, thanks. Is it too late to try to get this done for gutsy?
[15:49] <Joe_CoT> Sorry, Jaunty
[15:51] <cjwatson> Joe_CoT: not necessarily
[15:51] <cjwatson> Joe_CoT: although don't bet the house on it :-)
[15:51] <cjwatson> Joe_CoT: starting a discussion on ubuntu-devel would be a reasonable way to begin
[15:55] <Joe_CoT> cjwatson, yeah, I saw that, but I can't post to ubuntu-devel
[15:55] <cjwatson> sure you can, it just waits for moderation
[15:55] <ArneGoetje> cjwatson: I applied your patch and will try to rebuild the langpacks now.
[15:56] <cjwatson> ArneGoetje: thanks
[15:56] <Joe_CoT> cjwatson, ok, I'll give that a go later. thanks
[16:02] <Keybuk> seb128: yeah, lp people are looking into it now
[16:02] <wasabi> random sort of offtopic and odd question that i'm curious about:   anybody have an ubuntu armel chroot running on a G1?
[16:02] <Keybuk> it's the javascript library apparently
[16:06] <asac> geser: libjdic-java still uses xul 1.8? any reason?
[16:12] <geser> asac: I don't know
[16:16] <apw> if you are modifying a packaged based on an upstream package, one which has a debian/patches/ modifier, should that also be used for handling complete new files
[16:17] <persia> apw, Depends on the file, but often, yes.
[16:18] <apw> this is a new file for a hooks collection
[16:18] <persia> Exceptions would be when the file ought live in debian/ and get installed at install time (not used at build-time).
[16:19] <Keybuk> slangasek: so, I hear you escaped your civic duty?
[16:19] <apw> persia, this could be seen as that an additional file overlayed on the result
[16:20] <persia> apw, Is this file used at build-time or install-time?
[16:21] <persia> (also, #ubuntu-motu is frequently a more on-topic place for packaging questions)
[16:21] <apw> its not needed for the build, an additional file only
[16:22] <persia> Personally, I'd put that in debian/${file} rather than as a patch in debian/patches, and install it with dh_install.
[16:22] <apw> yeah, and actually now you've said that i can see one here just the same, thanks for the pointers
[16:34] <cjwatson> james_w,NCommander: I've had bug 289741 open in my browser for a while, and was thinking of just applying it regardless of powerpc testing. Would that be OK with you guys?
[16:34] <cjwatson> (actually I'd apply the update.cfg bit and regenerate)
[16:34] <james_w> cjwatson: I have no opinion on the matter
[16:36] <persia> txwikinger is the regular maintainer of ichthux-meta, if that impacts any decision
[16:36] <cjwatson> doesn't hurt
[16:36] <cjwatson> I'll tweak his change slightly to match other *-meta packages
[16:37] <ebroder> Does anyone know if there's some way to hook the update-manager for some site-specifc upgrade stuff?
[16:38] <Keybuk> cjwatson: when you were playing with your modem, did you encounter modem-modeswitch?
[16:38] <cjwatson> YM usb_modeswitch?
[16:38] <mvo> ebroder: not easily currently, but if you let us know what your use-case is we can provide hooks
[16:38] <Keybuk> cjwatson: no
[16:39] <cjwatson> OK, I didn't see modem-modeswitch
[16:39] <mvo> ebroder: you can already exchange the whole thing in a config option (if you want to provide your own)
[16:39] <cjwatson> I found three other roughly equivalent hacky piles of rubbish
[16:39] <ebroder> mvo: We have a site apt repository that's getting disabled during dist upgrades. It'd be nice if the updater could do s/hardy/intrepid/ or whatever instead of commenting out the repos
[16:39] <ebroder> mvo: Or if there was a hook where we could do that
[16:39] <cjwatson> some of which claimed to need random sleeps inserted in order to work; none of which I could get to actually work for me before I got bored
[16:44] <mvo> ebroder: ok, how about a config entry in /etc/update-manager/release-upgrades - something like "DisableThirdPartyRepos=True" that you could then change on your clients?
[16:45] <persia> mvo, How about a regex, so allow selective disablement?
[16:45] <ebroder> mvo: And if that was set to False, then the third-party repo would have the same substitution applied as the primary repos? That would be awesome, actually
[16:45] <mvo> ebroder: yes
[16:46] <mvo> persia: KISS (but yeah, could be a regexp too)
[16:46] <mvo> ebroder: ok, I can do that for jaunty I think
[16:46] <ebroder> That'd be amazing. Thanks
[16:46] <persia> mvo, good point.  Just thinking of use cases.
[16:47] <mvo> ebroder: could you please file a bug about it and paste me the bugnumber here? so that I can target it for jaunty?
[16:47] <ebroder> Will do
[16:48] <Keybuk> cjwatson: see the package I just dropped into NEW
[16:48] <cjwatson> Keybuk: do I really want to use this rather than the out-of-the-box thing I have now? :-)
[16:48] <cjwatson> (BTW "modem-modeswitch" is an irrelevant googlewhack, so I don't think I could have encountered it)
[16:50] <Keybuk> cjwatson: well, it would be nice if you can test it ;)
[16:50] <Keybuk> since this is going to be the out-of-the-box thing eventually
[16:51] <cjwatson> isn't it better to do it in the kernel?
[16:52] <Keybuk> I think so, but others disagree
[16:52] <cjwatson> Linus and the usb-storage maintainers apparently agree
[16:52] <Keybuk> if you haven't the time, dont' worry ;)
[16:52] <ebroder> mvo: it looks like there's already LP #147080. I'll update the description to match your idea
[16:55] <NCommander> cjwatson, no issue on my end, my PPC is quite dead ATM, so I haven't had an opportunity to test it.
[17:14] <highvoltage> "UDS: done," is probably not required in the topic anymore?
[17:17] <apw> cjwatson, is pm-utils one of yours ?  :)
[17:21] <fargiolas> hi, recently I've been playing a bit on a friend's computer with another linux distribution. We were quite impressed by the difference in font rendering and hinting between ubuntu and the other one. I looked around and saw that ubuntu enables some patent encumbered code in libfreetype for subpixel rendering. Are freetype patches enought to get the same ubuntu fonts look? do I need other patches? libcairo? xft?
[17:22] <fargiolas> e.g. I see libcairo has got a 04-lcd-filter-or-something patch, is that related to font hinting?
[17:23] <cjwatson> apw: nope
[17:24] <cjwatson> apw: you can check the changelog to see who tends to upload things; /usr/share/doc/pm-utils/changelog.Debian.gz
[17:27] <apw> looks like it pitti but i believe he is away
[17:27] <cjwatson> yeah
[17:27] <apw> i'll have to get all the bits together here, tested etc, then find someone to hastle about looking them over.  thanks
[17:29] <mvo> ebroder: I milestoned it - I also accidently declined it for jaunty but when I try to approve it again LP oopses. so best to just ignore the "declined for jaunty" line for now
[17:29] <james_w> apw: the author is often around, and I believe he follows lp bugs for the package, so you could contact him
[17:30] <ebroder> mvo: Haha. Ok, thanks a lot
[17:31] <apw> is that Michael ?
[17:33] <persia> apw, Generally, debian/copyright should help you identify upstream for any package (/usr/share/doc/${package}/copyright for installed packages)
[17:33] <apw> the change here is likely ubuntu specific, so not sure whether upstream is our target
[18:02] <cody-somerville> Hai, The new version of gnome-keyring breaks the shit out of Xubuntu and Mythbuntu. kthxbi.
[18:02] <seb128> slangasek: new evolution and evolution-data-server versions have been uploaded as intrepid sru today, would be nice if you could have a look and accept those and copy pocket the source to jaunty too since pitti is not there this week and they fix several annoying issues (evolution crashing when editing and account for example)
[18:02] <seb128> cody-somerville: there is already a bug open about that
[18:03] <cody-somerville> seb128, I know... but in the effort to improve communication, I decided to share that here.
[18:04] <seb128> not sure with who you want to communicate that but why not
[18:04]  * cody-somerville hugs seb128.
[18:07] <apw> is there a fools guide on how to make bzr branches in launchpad for something hosted in launchpad/bzr thing
[18:11] <cjwatson> bzr get lp:~OWNER/PROJECT/BRANCH [this just mirrors the remote branch locally for later speed]; bzr get BRANCH NAME-OF-YOUR-MODIFICATIONS; cd NAME-OF-YOUR-MODIFICATIONS; hack hack hack; bzr commit; bzr push lp:~YOURLPNAME/PROJECT/NAME-OF-YOUR-MODIFICATIONS
[18:11] <cjwatson> there's very likely something more coherent on help.launchpad.net
[18:12] <apw> b
[18:13] <apw> cjwatson, thanks ... thats helpful i am sure i can muddle though from there.  having git knowledge is a problem
[18:14] <cjwatson> if you keep forgetting to 'bzr push', handy tip is to run 'bzr bind <remote branch URL>' at which point your commits will be committed automatically to the remote branch as well
[18:15] <apw> is there any way to 'remember' the binding without it doing it all the time
[18:15] <apw> so that bzr push works, but i don't need the lp: crapola on the end?
[18:15] <james_w> "bzr push" will default to that location from now on
[18:15] <apw> bzr: ERROR: Target directory lp:~apw/apport/suspend-resume already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
[18:15] <james_w> "bzr push --remember wherever" to override the default later if desired
[18:15] <apw> and do i expect that the first time?
[18:16] <james_w> no, that's not expected
[18:16] <apw> bah, everything always breaks when i do it
[18:16] <james_w> did you have an interrupted push before?
[18:16] <apw> nope
[18:16] <apw> i went into launchpad and made the branch in the web interface
[18:16] <apw> and then tried to push into it, and it said that first time
[18:17] <james_w> ah
[18:17] <james_w> in that case it is expected
[18:17] <james_w> add --use-existing-dir as suggested
[18:19] <cjwatson> apw: alternatively, 'bzr bind' will be remembered
[18:19] <cjwatson> though you'll still need to push the first time
[18:20] <cjwatson> apw: for the record, you don't need to create the branch in the web interface
[18:20] <cjwatson> you can just push to lp:~apw/foo/bar at will
[18:20] <apw> oh ok, the web kinda implies you do with all its register buttons
[18:20] <cjwatson> assuming that the project 'foo' exists (launchpad.net/foo)
[18:20]  * apw pushes
[18:26] <calc> slangasek: is there enough time left for me to respin OOo again before the alpha freeze?
[18:26] <calc> slangasek: its a simple fix but will take building just ooo itself no langpacks to do it
[18:29] <Keybuk> AAARGH!
[18:29] <Keybuk> Vcs-Bzr: bzr+ssh://bazaar.launchpad.net/~ubuntu-mythtv/mythtv/mythtv-fixes
[18:29] <Keybuk> What is the point of having a package in bzr if only a private team can commit to it ?!?!?!?!
[18:31] <LaserJock> Keybuk: so you can make merge requests?
[18:31]  * apw slaps bzr ... let me do a bzr diff in the middle of a commit dammit
[18:32] <Keybuk> LaserJock: I can upload the package into the archive ;)
[18:32] <LaserJock> Keybuk: well sure, but I think many people use Vcs-Bzr for people who can't upload
[18:33] <Keybuk> then ubuntu-dev should be a member of that team
[18:33] <Keybuk> or they should have two branches
[18:33] <LaserJock> perhaps, but then ubuntu-dev gets spammed
[18:33] <Keybuk> one ~ubuntu-dev representing what's in the archive
[18:33] <superm1> Keybuk, we went through this before, then ubuntu-dev gets a lot of requests that spammed
[18:33] <Keybuk> and another private one that anyone can commit to
[18:34] <ogra> Keybuk, udev doesnt have rules for mtd devices ?
[18:34] <Keybuk> ogra: should it?
[18:35] <superm1> Keybuk, at least in that case -  a merge request is much more preferable than someone outside ~ubuntu-mythtv doing the upload.  we like to be very careful what patches get applied etc
[18:35] <Keybuk> superm1: we don't have maintainership in Ubuntu
[18:35] <ogra> well, i dont have any /dev/mtdblah but the kernel has builtin support for them and there should be one in the HW on my arm system
[18:36] <ogra> though, no trace in dmesg
[18:36] <Keybuk> ogra: that implies the kernel hasn't created one
[18:36] <ogra> yeah
[18:36] <Keybuk> you only need udev rules if you don't like the default kernel name
[18:36] <ogra> i thought udev creates the devicenode in any case
[18:37] <Keybuk> exactly
[18:37] <superm1> Keybuk, yes,  but still people who regularly work on packages tend to prefer to be poked anyhow to know what's happening with (possibly) invasive patches though, no?
[18:37] <Keybuk> superm1: yes
[18:37] <ogra> but takes what the kernel offers if it has no rule ? ah
[18:37] <Keybuk> but that's entirely different to "you can't commit/upload if you're not in our gang"
[18:38] <superm1> Keybuk, i think it would be fine to poke someone on the team saying how's this look, they say good, you upload it and post a merge url for them to pull it into bzr
[18:39] <superm1> but i gather that's still not the model you're striving for
[18:39] <ogra> isnt that what we have the "propose branch for merging" feature in LP for ?
[18:40] <Keybuk> ogra: no
[18:40] <Keybuk> propose branch for merging is for the exact opposite
[18:40] <Keybuk> in the model we're aiming for, it's so people who can't commit can propose their branch for merging by someone who can
[18:41] <Keybuk> superm1: ok, let's use my change as an example then
[18:41] <Keybuk> superm1: I've proposed it for review
[18:41] <Keybuk> now take a look at it and decide whether it's good or not
[18:41] <Keybuk> you're almost certainly going to have absolutely no idea, because the person who knows that it's a good change is *me*
[18:43] <superm1> Keybuk, haha "it's already uploaded, so your call"
[18:44] <superm1> so my question would be what are the implications of this on earlier releases?  We regularly backport using the same packaging.
[18:44] <superm1> and given there is a "Breaks: udev (<< 136-1)", that would mean these backports will break with that change
[18:45] <Keybuk> correct
[18:46] <superm1> so already right there I would have not been happy with it, and preferred the change be done in a way that maintains backportability rather than immediately uploaded
[18:46] <superm1> since this same branch is used for the weekly automated fixes builds
[18:46] <Keybuk> you can't ship a rule that works with the udev in intrepid and the udev in jaunty
[18:46] <Keybuk> the udev versions aren't compatible
[18:47] <superm1> well you can ship two rules then, and query what environment you're running on during the build process
[18:47] <Keybuk> you're welcome to try that ;)
[18:48] <superm1> er well two rules in the source package, and put the right one in the binary package - that's what i meant
[18:49] <Keybuk> you'd have to put the right preinst too, etc.
[18:49] <Keybuk> that's up to you to figure out ;)
[18:49] <Keybuk> my concern is making sure that it works in jaunty
[18:49] <Keybuk> which it does now
[18:49] <Keybuk> if you're backporting to earlier releases, that's your problem ;)
[18:50] <superm1> right it's functional for jaunty, but exactly why it's better for the team to have control over their main bzr branch, so there is shielding from problems like this coming up that the person who uploaded may have not forseen
[18:51] <Keybuk> I disagree entirely
[18:51] <Keybuk> having packages gated by the team is the very thing in Debian we designed the Ubuntu archive to *avoid*
[18:52] <Keybuk> superm1: btw
[18:52] <Keybuk> I'd like to talk to you about that rule anyway
[18:53] <Keybuk> since it gives root access to mythtv
[18:53] <Keybuk> I suspect kees would like to talk to you about it too ;)
[18:53] <superm1> Keybuk, yeah once the new firewire stack is put in place, it can go away thankfully
[18:53] <Keybuk> it's invalid *now*
[18:53]  * kees reads backlog
[18:54] <superm1> Keybuk, if new pieces are in place already, then just a matter of someone verifying functionality hasn't change without the rule there
[18:55] <Keybuk> no, I mean arguably right now, installing mythtv is a massive security risk
[18:55] <Keybuk> in intrepid, assumedly, as well
[18:55] <kees> f'ing firewire.
[18:56] <superm1> i can see the argument there.  it's either functionality or security in this case until the new stack is complete.
[19:03] <Keybuk> superm1: yes
[19:03] <Keybuk> but users aren't warned about it ;)
[19:12] <slangasek> Keybuk: my civic duty is fulfilled for the moment, yes
[19:12] <Keybuk> slangasek: if they call you up, but then don't actually select you, can they call you up again later?
[19:13] <slangasek> Keybuk: in this case, yes; if you actually serve on a jury then you're ineligible to serve again for the next 12 months, but otherwise you can be called up again any time at random
[19:14] <slangasek> calc: yeah, we could squeeze in an OOo respin if there's need
[19:18] <calc> slangasek: i found out that its broken on KDE with the openoffice.org-kde package installed and I know how to fix it
[19:18] <calc> slangasek: I'll get a new upload done right after meeting with Rick
[19:18] <calc> slangasek: should be done ~ 2hr from now
[19:18] <calc> er considering it takes 1hr to upload from my house :-\
 fta: seems to not honour my .pastebinit.xml anymore <= works for me (tm). which version are you using? mine?
[19:20] <fta> asac, oh, 0.11 is in universe, maybe a bug i fixed for stgraber that is missing.
[19:21] <fta> stgraber, ^^
[19:23] <slangasek> calc: right, sounds good
[19:25] <fta> asac, stgraber: i remember now, i fixed that after 0.11 was closed, but before it entered debian, so my fixes are not in. we need 0.12 or 0.11.1
[19:46] <LaserJock> if I want to drop several binary packages from a source package should I upload a new source that doesn't build them first and then file a bug for removal or the other way around?
[19:47] <Keybuk> the former
[19:47] <Keybuk> no need to file a bug for removal either
[19:47] <Keybuk> the archive admins will notice
[19:48] <slangasek> siretart: hmm, was your upload of emacs-snapshot 1:20081013-1 a fake-sync?  AFAICS, the package was removed from Debian at version 1:20070302-1 and never restored
[19:49] <apw> slangasek, i have a couple of changes targeted against packages which pitti seems to own and he is away, we were hoping to get those changes into jaunty alpha-3 and i am wondering what the right way forward is as he is away
[19:51] <slangasek> apw: I'm not aware of any packages that pitti owns exclusively - what are you looking at?
[19:51] <slangasek> (i.e., what packages)
[19:53] <apw> apport and pm-utils
[19:53] <calc> cjwatson: ping
[19:53] <calc> anyone happen to know why launchpad-integration (at least the command line version) broke recently?
[19:54] <calc> if you run launchpad-integration -b -P openoffice.org for example it comes up with page not found error
[19:54] <james_w> calc: launchpad bug
[19:54] <james_w> calc: reload after a few seconds, they are working on the fix
[19:54] <calc> ok
[19:57] <calc> rickspencer3: ^ apparently its a timing issue with launchpad itself
[19:58] <rickspencer3> hmmm
[19:59] <rickspencer3> yah
[19:59] <rickspencer3> I just reloaded the page, and there it is
[19:59] <calc> it takes ~ 5-10s to work
[20:03] <slangasek> apw: ah; apport at least should be in bzr, I don't know whether pm-utils is currently
[20:04] <apw> yep, i made a branch off apport and pushed up the changes there, pm-utils didn't claim to be so i did a traditional debdiff for that one
[20:06] <slangasek> apw: right - at that point you can use the standard sponsorship process to get them in (https://wiki.ubuntu.com/SponsorshipProcess), and I'm happy to have you escalate to me directly once the bugs are in place that I can reference
[20:08] <apw> slangasek, ok thanks ... process is always the hardest piece to get right without wasting loads of peoples time; those at the top of the tree whos time is valuable
[20:19] <calc> slangasek: uploading now
[20:23] <Keybuk> TheMuso: err, so I was looking at speechd-up briefly
[20:23] <Keybuk> I think your udev rule is wrong ;)
[20:23] <cody-somerville> lmao
[20:26] <kirkland> emgent: hey there ... your ubuntu top uploaders page isn't active any more?
[20:28] <Keybuk> bug #316511
[20:29] <emgent> kirkland: i'm thinking to put it in ubuntustat
[20:30] <emgent> anyway yeah is up
[20:30] <emgent> but i should fix some issue first to re-put up it
[20:34] <kirkland> emgent: URL?
[20:34] <kirkland> emgent: the old url's from your blog are broken
[20:36] <cjwatson> calc: yep?
[20:37] <emgent> kirkland: http://thc.emgent.org/utu/
[20:41] <calc> cjwatson: oh i was going to ask you about the launchpad-integration issue but james_w told me it was due to launchpad bug
[20:41] <kirkland> emgent: thanks
[20:44] <emgent> kirkland: np, cron working now to update
[20:56] <slangasek> LaserJock: ping
[20:56] <LaserJock> slangasek: uh oh, what'd I do now?
[20:56] <slangasek> LaserJock: the edubuntu seeds seem to be in a funny state; the edubuntu-desktop-kde seed, for instance, references "edubuntu-desktop-kde"?
[20:56] <slangasek> I was going to try to update edubuntu-meta for alpha-3, but it failed miserably
[20:57] <cjwatson> calc: *nod* ok
[20:57] <LaserJock> slangasek: what did you need to update? I'm working on an upload now
[20:57] <cjwatson> slangasek: what's wrong with that?
[20:57] <slangasek> LaserJock: I was just going to refresh the package for seed changes
[20:57] <cjwatson> it's normal for metapackage seeds to contain the metapackage
[20:57] <slangasek> cjwatson: to have a metapackage include itself?
[20:57] <slangasek> oh, is it?
[20:57] <cjwatson> look at ubuntu.jaunty/desktop
[20:57] <cjwatson> germinate-update-metapackage knows to exclude it
[20:58] <slangasek> ok
[20:58] <LaserJock> well, I had an issue with it
[20:58] <slangasek> then I just didn't follow through far enough :)
[20:58] <LaserJock> for edubuntu-desktop it's fine
[20:58] <cjwatson> I suspect you're running into stuff that's intentionally in universe
[20:58] <LaserJock> but when I ran germinate on edubuntu-desktop-kde it wanted to include it
[20:59] <LaserJock> I was checking that before I uploaded to make sure I didn't screw something up
[20:59] <LaserJock> I've really reworked the seeds so it's possible I missed something
[21:00] <cjwatson> what's the actual error message?
[21:00] <LaserJock> it wasn't an error
[21:01] <LaserJock> it just added edubuntu-desktop-kde to the lists
[21:01] <LaserJock> at least I didn't think there was a message, I can run it again to check
[21:02] <LaserJock> cjwatson: how does it know to exclude them?
[21:04] <cjwatson> see metapackage_name in germinate-update-metapackage
[21:05] <apw> slangasek, i pasted the patches and pointers into the bug (bug #316419) and subscribed the bug to ubuntu-main-sponsors.  will see whoall responds.  thanks for you help
[21:05] <slangasek> apw: great, thanks!
[21:06] <cjwatson> LaserJock: why did you rename the seeds?
[21:06] <cjwatson> that was sort of unhelpful :P
[21:06] <LaserJock> cjwatson: I know I know
[21:06] <LaserJock> I'm just trying to make it clear to contributors
[21:07] <cjwatson> well, that's what broke it :)
[21:07] <LaserJock> as I'm adding in 4 new seeds and trying to get edubuntu-desktop-kde going
[21:07] <cjwatson> if you want to keep it that way, you can override the metapackage name handling by putting "Task-Metapackage: edubuntu-desktop-kde" in edubuntu.jaunty/edubuntu-desktop-kde
[21:07] <cjwatson> and similar
[21:08] <ScriptRipper> who can help me here with some .deb packaging for a multitarget pkg (debian and ubuntu)?
[21:08] <LaserJock> oh, I think I see
[21:09] <cjwatson> ScriptRipper: #ubuntu-motu is for mentoring
[21:09] <LaserJock> cjwatson: so it looks for <distro>-<seed> for the metapackage name
[21:09] <LaserJock> I was wondering why changing it to the exact name of the metapackage would cause problems
[21:10] <LaserJock> but it's taking it as edubuntu-edubuntu-desktop-kde
[21:10] <cjwatson> because now it wants edubuntu-edubuntu-desktop-kde :-)
[21:10] <cjwatson> I'm always happy to offer advice in advance of complex seed changes ;-)
[21:10] <LaserJock> well, the reason I did that was because we can't have a "desktop" seed
[21:10] <cjwatson> yeah, that's why I had desktop-addon with Task-Metapackage: edubuntu-desktop
[21:10] <LaserJock> right
[21:11] <LaserJock> but for various reasons "addon" doesn't have much context anymore
[21:11] <cjwatson> sure
[21:12] <LaserJock> ok, so i think perhaps "Task-Metapackage: edubuntu-desktop-kde" might be the way to go
[21:12] <LaserJock> as I really would like to keep things clear if I can
[21:12] <cjwatson> yeah, probably best
[21:22] <LaserJock> slangasek: ok, edubuntu-meta uploaded and sorry for the mess
[21:23] <slangasek> n/p :)
[21:44] <Keybuk> my god
[21:44] <Keybuk> what is yada?!
[21:45] <Keybuk> this thing should be *illegal*
[21:45] <seb128> slangasek: there? did you read what I said before about evolution?
[21:46] <slangasek> seb128: hi, yes - will get it a bit later this afternoon
[21:46] <slangasek> Keybuk: haha
[21:47] <seb128> slangasek: ok thanks, I was just making sure you were around this week to know if I should do a jaunty upload or wait for it to be accepted and pocket copied
[21:47] <slangasek> seb128: yep - I'm here all week :)
[21:47] <LaserJock> Keybuk: autogenerated debian/rules doesn't sound fun?
[21:47] <Keybuk> auto-generated debian/anything is just wrong
[21:48] <LaserJock> slangasek: I've just uploaded edubuntu-addon-meta as well, which drops 4 binaries (edubuntu-addon-* metapackages). Once those binaries are removed from the archive kpercentage will drop from NBS
[21:48] <slangasek> ok
[21:48] <LaserJock> Keybuk: you don't like seeing changelog.in and control.in files laying around?
[21:48] <LaserJock> :-)
[21:49] <cjwatson> Keybuk: yeah, most of Debian figured that out in about 2000 but there are still a few weirdos :)
[21:49] <LaserJock> slangasek: just sort of a FYI
[21:49] <slangasek> Keybuk: c'mon, you know you've always wanted to build your debian packages from a spec file
[21:49] <cjwatson> LaserJock: yada is the one that has debian/packages
[21:49] <lifeless> slangasek: its like autoconf.in.in
[21:49] <cjwatson> and generates everything from that
[21:49] <LaserJock> cjwatson: *everything*?
[21:49] <slangasek> LaserJock: spec file
[21:50] <cjwatson> pretty much
[21:50]  * pochu apt-get sources it
[21:50] <slangasek> why use a filesystem to structure your data when you can use an arbitrary text file format?
[21:50] <Keybuk> slangasek: if you want to build your packages from a spec file, just build your packages from a spec file!
[21:50] <cjwatson> certainly including control rules changelog
[21:50] <Keybuk> nothing says you have to use dpkg-buildpackage
[21:50] <slangasek> Keybuk: the archive admins says
[21:50] <Keybuk> it's perfectly valid to build a deb using just dpkg-source -b after laying it out
[21:50] <Keybuk> slangasek: debian/rules:
[21:50] <Keybuk> build:
[21:50] <Keybuk>   rpm...
[21:50] <Keybuk> binary:
[21:50] <LaserJock> cjwatson: oh dear Lord, that's awful
[21:50] <Keybuk>   rpm...
[21:50]  * slangasek grins
[21:51] <slangasek> wow, somehow I thought it was more common knowledge just how evil yada was
[21:51] <Keybuk> yada feels like package rape
[21:51] <cjwatson> Keybuk: that's certainly valid, though I'd be petitioning $WORLD for a new maintainer if anyone tried it :)
[21:51] <Keybuk> heh
[21:51] <LaserJock> slangasek: I've heard people grumble about it but never actually looked up what it did
[21:51] <Keybuk> update-maintainer doesn't work with yada ;)
[21:51]  * Keybuk considers a bug
[21:52] <slangasek> a bug to remove yada
[21:52] <slangasek> ?
[21:52] <Keybuk> yes
[21:52] <Keybuk> how many things use it?
[21:52] <Keybuk> and of those, do we CARE about any of them? :p
[21:53] <slangasek> only the things that dexter maintains
[21:53] <slangasek> and none of those in main, the ones he maintained that were in main got repackaged sanely by StevenK
[21:53] <Mithrandir> libnss-db, but I think that's repackaged now.
[21:53] <slangasek> yes, StevenK repackaged that one
[21:54] <Keybuk> there really is a random smattering of things, isn't there
[21:57] <calc> fsck someone broke librdf0-dev
[21:58] <calc> which caused my simple couple line fix to FTBFS since librdf0-dev is no longer installable :(
[21:58]  * calc goes to beat on librdf0-dev
[22:07] <Keybuk> does anything create the plugdev group anymore?
[22:08] <slangasek> is it still in user-setup?
[22:08] <Keybuk> ./debian/user-setup-udeb.templates:Default: adm cdrom dialout lpadmin plugdev sambashare
[22:09] <Keybuk>   * Add back plugdev.  It's needed to make mounting easier for shell users.
[22:09] <Keybuk> evan_: ?
[22:10] <evan_> I believe that was at the request of pitti, though I don't recall his exact reasoning
[22:13] <Keybuk> unless I'm mistaken, there's nothing on the system owned by plugdev now
[22:13] <evand> I have no objections to that change being reverted.
[22:14] <Keybuk> 'plugdev' has to stay for static mountpoints created by the installer.
[22:14] <Keybuk> is the only other comment I can find
[22:15] <Keybuk> hmm
[22:15] <Keybuk> can't see anything in IRC logs?
[22:15] <Keybuk> there's only 5 hours between the upload removing it and the upload putting it back
[22:16] <Keybuk> *shrug*
[22:16] <Keybuk> remove it again ;)
[22:16] <Keybuk> see who complains
[22:16] <Keybuk> it was probably true at the time that udev still used it for things
[22:17] <calc> apparently someone completely broke libmysqlclient*-dev installation
[22:17] <calc> looks like missing conflicts maybe, but not certain
[22:17]  * calc is making a clean chroot to see what happens
[22:18] <calc> libmysqlclient-dev tries to overwrite files in libmysqlclient15-dev at minimum
[22:29] <cjwatson> gar
[22:29] <cjwatson> no
[22:30] <cjwatson> keep plugdev
[22:31] <Joe_CoT> cjwatson, still waiting on that moderator to approve my Asterisk in Main post :(
[22:31] <cjwatson> partman-basicfilesystems sets up FAT and NTFS filesystems in /etc/fstab with gid=46 which is plugdev
[22:31] <cjwatson> Joe_CoT: typical moderation delay may exceed a day. I'm not going to try to do it now since it's 10:30pm local
[22:32] <cjwatson> Keybuk: ^-
[22:34] <directhex> cjwatson, where are you, geographically?
[22:34] <TheMuso> directhex: The UK.
[22:35] <directhex> TheMuso, well, yes, i knew THAT bit, not many countries are on UTC+0
[22:35] <asac> fta: thanks for clarifying ;)
[22:36] <Laney> directhex: can we expect you to come bug jamming?
[22:36] <directhex> Laney, hm?
[22:37] <Laney> http://fridge.ubuntu.com/node/1775
[22:38] <cjwatson> directhex: Cambridge
[22:38] <directhex> eek, tabland
[22:38] <calc> asac: ping
[22:38] <asac> calc: ?
[22:39] <calc> asac: mysql-dfsg-5.1 was uploaded a few days ago and appears to have taken over the libmysqlclient-dev package from mysql-dfsg-5.0 can that be promoted to main?
[22:39] <directhex> cjwatson, if these OOM_DISABLE sshd patches actually work, i suspect it won't just be our dept looking to apply beer liberally. i've got tomorrow to investigate it
[22:41] <calc> asac: it appears someone forgot what doing that would cause... :-\
[22:46] <calc> asac: not only that but libmysqlclient15-dev is now a dummy package (in main no less) that depends on libmysqlcient-dev which is in universe
[22:50] <mathiaz> calc: right - there are some issues with mysql 5.1 uploaded to universe. For now the plan is to keep 5.0 in main and leave 5.1 in universe.
[22:50] <Keybuk> cjwatson: why don't you just use "users" ?
[22:50] <Keybuk> otherwise we have a very bizarrely named group
[22:50] <Keybuk> "plugdev" = "access NTFS/FAT filesystems set up by the installer"
[22:50] <asac> zul: whats the idea about mysql -dev packages?
[22:50] <asac> zul: see a few lines above
[22:50] <calc> mathiaz: er do you plan on fixing 5.0 RSN? It is blocking OpenOffice.org builds
[22:50] <mathiaz> calc: a new version of mysql 5.1 should be uploaded to universe to fix the issue.
[22:51] <calc> mathiaz: it looks like a new 5.0 release has to be made too since the libmysqlclient15-dev package is now a dummy package?
[22:51] <fta> asac, you can use pastebinit from my ppa, i bumped it, it has all the fixes.
[22:51] <cjwatson> Keybuk: because nothing actually adds individual users to 'users'
[22:51] <asac> fta: yeah. will give it a try ;)
[22:51] <cjwatson> if you want to talk about bizarrely named groups ...
[22:51] <asac> thanks
[22:51] <Keybuk> cjwatson: nothing should add users to plugdev anymore though
[22:51] <cjwatson> I can't help it that the rug got pulled out from under me :P
[22:51] <cjwatson> users isn't appropriate, I'd be happy with something that is
[22:51] <Keybuk> heh
[22:51] <asac> mathiaz: can you take care that the -dev pacakge mess gets resolved ;)?
[22:52] <Keybuk> my concern is that people keep filing bugs referring to plugdev
[22:52] <Keybuk> because we still create it
[22:52] <Keybuk> even if the group was renamed, I'd be happy
[22:52] <Keybuk> it would stop a torrent of wrong bugs
[22:52] <cjwatson> yes, I have no intention of changing base-passwd because before I can do that I need to implement debconf support
[22:52] <mathiaz> asac: yop
[22:52] <asac> mathiaz: cool ... so i can go to sleep soon :)
[22:52] <cjwatson> otherwise everyone who has ever installed Ubuntu will get a non-debconf prompt when upgrading
[22:52] <Keybuk> cjwatson: I thought we had debconf support now?
[22:52] <cjwatson> no.
[22:52]  * Keybuk is sure we had this discussion last time ;)
[22:52] <cjwatson> it's been on my to-do list since 2004
[22:53] <cjwatson> it's actually quite complicated
[22:53] <cjwatson> anyway, I only really care about something the first user can access
[22:53] <cjwatson> since I'm not sure plugdev was any better than that
[22:53] <Keybuk> admin?
[22:53] <cjwatson> s'pose that might work
[22:54] <cjwatson> removing the old group from people's systems is still going to be very hard
[22:54] <Keybuk> I don't really care overly about removing the old group
[22:54] <Keybuk> but people justify bugs with "this is a new install and the group was still created"
[22:54] <cjwatson> is there a way to say "this filesystem should be mountable by users at the console"?
[22:55] <Keybuk> not with /sbin/mount itself
[22:55] <cjwatson> also, I have grave reservations about Ubuntu's list of global static users and groups ever diverging from Debian's
[22:55] <cjwatson> there is only one namespace there and it ain't big
[22:55] <cjwatson> a removal itself might not be a problem, but I don't want it to set a precedent
[22:57] <Keybuk> since many of our core system pieces are quite different from Debian's, we're surely always going to differ on such things as groups?
[22:58] <cjwatson> we never have in terms of the global static users and groups until now
[22:58] <cjwatson> plugdev was added to Debian in response to Ubuntu's need, essentially
[22:58] <cjwatson> and then used in various places in Debian I think
[22:58] <cjwatson> global static users/groups are very, very rarely needed. so I don't think that assertion holds at all
[22:58] <Keybuk> well, no
[22:58] <Keybuk> we're trying to phase out all of the groups that a user might need to be a member of
[22:59] <cjwatson> there have been been fewer than 50 ever
[22:59] <cjwatson> (of each)
[22:59] <Keybuk> and use other means to do that authentication
[22:59] <cjwatson> right, but I'm not going to go removing global static groups as the wind changes, sorry. We still have operator for goodness' sake :)
[23:00] <cjwatson> IME, (a) there is value in continuity, (b) knee-jerk removals result in the need for knee-jerk readditions later
[23:00] <cjwatson> I would be happy if we can get to the point where we no longer need to add the first user to plugdev
[23:01] <cjwatson> and can document it as obsolete in Ubuntu
[23:01] <Keybuk> we've removed things like scanner already ;)
[23:01] <Keybuk> well, since the installer is the thing creating plugdev
[23:01] <Keybuk> and the thing putting the first user into plugdev
[23:01] <cjwatson> scanner was not a global static group
[23:01] <Keybuk> and apparently the only thing still using plugdev ...
[23:01] <cjwatson> no, the installer is not the thing creating plugdev
[23:01] <cjwatson> base-passwd is the thing creating plugdev
[23:01] <Keybuk> that's kinda blocking your own argument on yourself
[23:03] <cjwatson> give me a better solution. admin strikes me as a poor solution, design-wise, since it's root-equivalent by definition
[23:04] <Keybuk> I can't do that without knowing *why* you set that gid= in /etc/fstab
[23:04] <cjwatson> read the changelogs and the bug references therein?
[23:04] <cjwatson> surely when removing a feature it is appropriate to research it!
[23:04] <cjwatson> partman-basicfilesystems is the package in question
[23:04] <cjwatson>   * Mount FAT and NTFS with umask=007,gid=46 (static group plugdev), so that
[23:05] <cjwatson>     users can easily be given privileges to read/write mounted Windows
[23:05] <cjwatson>     filesystems, and so that the first user can do so automatically (closes:
[23:05] <cjwatson>     Malone #8048, #25071).
[23:05] <Keybuk> that sounds like a wrong change though
[23:05] <cjwatson> those bugs have fairly extensive discussion
[23:05] <Keybuk> certainly abusing plugdev
[23:05] <cjwatson> those bugs have fairly extensive discussion
[23:05] <Keybuk> plugdev was intended as a group to allow the console user to access removable devices
[23:05] <cjwatson> you can't possibly have had time to read it in the gap between my posting that and you saying that
[23:05] <Keybuk> my machine is behaving very strangely and I can't open any windows or tab away from this one
[23:05] <cjwatson> Martin Pitt, the inventor of plugdev IIRC, suggested it as an option
[23:06]  * Keybuk wouldn't have done that
[23:06] <Keybuk> it merges privileges
[23:07] <Keybuk> if everything that wanted "the user that installed the system" to have access to things, we may as well just have a group for that
[23:07] <Keybuk> not "oh, we happen to have this random other group we use for something else, we could just use that group"
[23:07] <Keybuk> still
[23:08] <Keybuk> I'm clearly not going to persuade you
[23:08] <cjwatson> you're not going to persuade me that you get to give me grief about something that was extensively discussed among our best security-oriented developers at the time, and appeared to be the least bad solution available, no
[23:08] <cjwatson> I am entirely happy to drop in a better solution; I just don't feel that I have seen one yet
[23:09] <cjwatson> and in the meantime I do not feel that we should deliberately break things
[23:09] <Keybuk> I would rename the group to "windows" or something
[23:09] <Keybuk> because that way, it will stop people repeatedly filing bugs because they read about plugdev somewhere
[23:09] <cjwatson> we can't rename it without addressing the debconf problem
[23:09] <cjwatson> and frankly that will just lead to a different set of bugs
[23:10] <cjwatson> (renaming it to "windows")
[23:10] <Keybuk> yes, it will lead to a set of bugs where users actually describe the problem they're having
[23:10] <Keybuk> ;)
[23:10] <cjwatson> I'm sorry that you get hard bugs. Join the club :-P
[23:10] <Keybuk> they're usually fun
[23:11] <Keybuk> "blah is not in the plugdev group."  "Correct -> invalid"
[23:11] <cjwatson> seems like an appropriate response :)
[23:11] <Keybuk> actually, I have a fun one where a guy keeps un-wont-fixing his bug that his iPod isn't in group floppy ;)
[23:11] <cjwatson> I could adjust the base-passwd documentation in Ubuntu so that you have something "authoritative" to point to
[23:11] <cjwatson> and to deconfuse anyone who looks there
[23:11] <Keybuk> the udev docs are quite clear
[23:12] <Keybuk> people would just file bugs on base-passwd to say the docs are wrong ;)
[23:12] <cjwatson> the udev docs are hardly the authoritative source for the semantics of global static groups
[23:12] <cjwatson> I am entirely happy to reject base-passwd bugs without needing to propose breaking udev ;-)
[23:12] <Keybuk> they're the authorative source for the groups given to things in /dev
[23:12] <cjwatson> yes
[23:13] <Keybuk> and quite clear that no user should ever be put into one of those groups
[23:13] <Keybuk> anyway
[23:13] <Keybuk> I'm going to reboot this thing
[23:13] <Keybuk> it did the same thing yesterday, then the problem mysteriously went away overnight
[23:13] <Keybuk> and now it's doing it again
[23:13] <Keybuk> silly thing
[23:17] <Keybuk> cjwatson: on further thought, it would probably be nice to have a document about the system static groups explaining what they're for, and what uses them
[23:22] <cjwatson> Keybuk: /usr/share/doc/base-passwd/users-and-groups.* is such a document (accuracy due to changing winds notwithstanding; happy to update it)
[23:27] <cjwatson> Keybuk: btw, sorry for being snappy above - have screaming baby here and it's all a bit fraught :(
[23:28] <cjwatson> I do strongly believe in stepwise improvement as you know, but needn't have been sarky about it