[00:05] <slangasek> philsf: it's a question of the behavior when turning on filesharing for the first time, when packages get auto-installed for you
[00:05] <slangasek> so a proper test should involve removing the libpam-smbpass package (I think that's the only one)
[00:06] <philsf> slangasek: I did it, and couldn't reproduce the bug with a guest allowed share
[00:06] <slangasek> sec, let me review the bug
[00:06] <philsf> I did purge samba-common and all of its rdepends and logged out to make sure I had a fresh environment, but the shares are in fact created after the installation of samba and libpam-smbpass, and they work without a logout/login cycle. I tried this more than once, in two boxes, both with Hardy.
[00:07] <slangasek> philsf: purging samba-common probably doesn't remove you from the sambashare group, if you were previously added to it :)
[00:07] <cjwatson> NCommander: what's up?
[00:08] <philsf> slangasek: that's probably it, but why isn't the group removed?
[00:08] <slangasek> philsf: the second part of the behavior only applies to non-guest shares
[00:08] <slangasek> philsf: because removing guests is wrong, generally
[00:08] <philsf> removing guests? or groups?
[00:09] <NCommander> cjwatson, any idea what voodoo will be needed to fix the current d-i/ARM builds?
[00:09] <cjwatson> NCommander: nothing, wait for the current kernel upload to build?
[00:10] <cjwatson> I already spoke with rtg about it and it looks like he took that into account
[00:10] <NCommander> Ah
[00:10] <NCommander> Cool
[00:25] <philsf> slangasek: you were right about the group, the package in -proposed works for me. I'm confirming the bug as soon as I test in the second machine
[00:25] <slangasek> great, thanks!
[00:25] <philsf> no, thank you. bye
[03:45] <superm1> tkamppeter_, i was wondering.  is there a particular reason that  "Show printers shared by other systems" isn't enabled by default in the gnome printer tool?
[06:09] <dholbach> good morning
[06:11] <LaserJock> hi dholbach
[06:11] <dholbach> hi LaserJock, hi warp10
[06:12] <warp10> morning dholbach!
[06:18] <dholbach> cody-somerville: what do you think about bug 311571?
[06:18] <LaserJock> I've been somewhat annoyed by that one in the past
[06:24] <LaserJock> seems kind of odd to have ${Upstream-Version} on Conflicts
[07:39] <pitti> Good morning
[07:49] <tkamppeter> superm1, "Show printers shared by other systems" isn't enabled in s-c-p because it is not enabled in CUPS. pitti, why do we not enable to accept broadcasted CUPS queues from other machines by default in CUPS?
[07:51] <pitti> superm1: hard to say really, it's full of comments about 180
[07:51] <pitti> superm1: I don't have a problem with letting 180 move to -updates, since it's completely new
[07:51] <pitti> superm1: but so far I didn't see a clear statement that the new 178 works
[07:52] <pitti> tkamppeter: we discussed that in the past, and the prerequisite for that is to change KDE and GNOME to clearly tell apart automatically detected from manually configured printers in the print dialogs, so that you can't lure someone into using a bad printer (or at least it's more obvious)
[07:53] <tkamppeter> pitti, are bugs reported to KDE and GNOME?
[07:54] <pitti> tkamppeter: not sure, I don't think I filed them
[07:54] <tkamppeter> superm1, ^^^
[07:55] <tkamppeter> pitti, can you do so, otherwise the developers of the dialogs are not aware of the problem. You must report to GTK and Qt, as they provide the currently used dialogs.
[07:56] <pitti> okay
[08:07] <tkamppeter> pitti, thanks.
[08:14] <mdke> dholbach: thanks for your comment on bug 126988, but I don't understand why that is happening. Revisions 735 to 737 introduce quite substantial changes, and Launchpad shows me them in the web interface. Are you sure you have the right branch?
[08:15] <mdke> dholbach: from the diff you've posted, it doesn't look like the package even has the right version number, I bumped it to 2.24.1+svn20090109ubuntu1 in revision 736
[08:16] <dholbach> mdke: my mistake - sorry
[08:17] <mdke> dholbach: ok! No worries
[08:17] <mdke> dholbach: happy 2009 by the way
[08:18] <dholbach> mdke: and the same to you :)
[08:29] <dholbach> mdke: uploading
[08:29] <dholbach> ... which might take a bit of time :)
[08:30] <mdke> dholbach: great, thanks
[10:52] <rniamo> hi
[10:53] <rniamo> how could i do to redirect a pipe in a socket in both writing and reading ?
[10:53] <Keybuk> a pipe is one-way only
[10:54] <Keybuk> whatever you write to it comes out the reading end
[10:54] <Keybuk> it's not possible to read and write from the same end
[10:54] <Keybuk> if you want to do that, you need a socket
[10:54] <rniamo> in fact i want to do a command like this : cmd1 | cmd2 but cmd1 and cmd2 on two diffrent PC
[10:55] <Keybuk> cmd1 | ssh otherhost cmd2 ?
[10:55] <rniamo> in fact i have to write a bash-lite
[10:55] <rniamo> so i can't use ssh
[10:55] <cjwatson> "have to write"?
[10:55] <rniamo> my problem is i don't know how to read on the server from the client
[10:55] <Mithrandir> you're not really explaining what your are trying to do, and I believe what you are trying to do has little to do with Ubuntu development.
[10:56] <cjwatson> this is sounding a bit like a homework question ...
[10:56] <rniamo> yes
[10:56] <rniamo> unix homework
[10:56] <cjwatson> don't ask those here, please. This is a working channel.
[10:56] <Keybuk> rmcbride: http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html
[10:56] <rniamo> where could i ask it please ?
[10:56] <jpds> rniamo: Try: ##linux.
[10:56] <cjwatson> rniamo: that really isn't our problem; ask your teacher if you need help
[10:57] <cjwatson> we're not here to help people pass their CS homework
[10:57] <Keybuk> (most of us never passed *our* CS homework) :p
[10:57] <Mithrandir> Keybuk: we didn't?
[10:57] <StevenK> Speak for yourself
[10:57] <StevenK> I know I did
[10:57] <directhex> i passed the fun bits
[10:57] <rniamo> i just want some help, sorry if it is the bad chan
[10:57] <StevenK> Sockets programming isn't exactly fun, but it is interesting
[10:57] <mok0> rniamo: check out netcat
[10:58] <Keybuk> StevenK: I find it fun
[10:58] <mok0> rniamo: it does something similar
[10:58] <rniamo> netcat ?
[10:58] <mok0> rniamo: yes. Ask Mr. Google
[10:58] <StevenK> Keybuk: You wrote a replacement for init, this makes you a masochist.
[10:59] <rniamo> my problem is that socket are ok, pipe are ok but not both together
[10:59]  * directhex ports init to ironpython
[10:59] <Keybuk> StevenK: I prefer other people to inflict the pain ;)
[10:59] <StevenK> cjwatson: Did you follow the jaunty-unr discussion at UDS?
[10:59] <mok0> rniamo: right. netcat communicates via sockets
[11:00] <rniamo> my problem is here http://paste.linuxassist.net/169910
[11:00] <rniamo> i would like to add a close(0); dup(cbCmd->sock);
[11:00] <StevenK> cjwatson: Essentially, -umpc goes away, and -netbook-remix turns up. I have a uncommited branch in the mobile seeds for this, but it also requires the task name to change, which I recall you saying needs tasksel changes. I looked at tasksel, and I ran away screaming ...
[11:02] <Keybuk> ugh
[11:02] <StevenK> cjwatson: Also, I'd like you to sanity check my commit, because I'd like to grow a ship seed, but the one that is in ubuntu.jaunty is perfectly fine.
[11:02] <Keybuk> random sleep statements in cron.daily makes Keybuk unhappy
[11:22] <cjwatson> StevenK: unr> no, I didn't
[11:22] <cjwatson> StevenK: where's your branch?
[11:22] <StevenK> cjwatson: I'm pushing it to a seperate location right now.
[11:22] <cjwatson> StevenK: tasksel updates are trivial as long as you realise that almost all of the interesting stuff for us is autogenerated by ubuntu-seeds.pl
[11:22] <cjwatson> and that you *must* *not* *touch* ubuntu-tasks/ by hand
[11:23] <StevenK> cjwatson: Yeah, I looked at ubuntu-seeds.pl source and then decided the best step would be to talk to you. :-)
[11:28] <StevenK> cjwatson: My branch is at sftp://chinstrap/home/stevenk/mobile.jaunty
[11:33] <ccm> pitti: ping
[11:35] <ccm> can somebody besides pitti tell, why i cannot find a debug package for "mairix"?
[11:35] <Keybuk> wow
[11:36] <Keybuk> just applying the "no legacy ptys" change to the kernel config reduces the average pid by ~1000
[11:36] <Keybuk> not surprising, but shows just how much we did just for them
[11:36] <cjwatson> ccm: http://ddebs.ubuntu.com/pool/universe/m/mairix/
[11:36] <Keybuk> actually
[11:36] <Keybuk> by ~2000
[11:36] <Keybuk> because I forgot, each legacy pty had two kobjects
[11:36] <Keybuk> which means two udev processes per kobject per trigger
[11:37] <Keybuk> we trigger twice
[11:38] <ccm> cjwatson: thank you. is it normal that i cannot install this directly via aptitude?
[11:40] <cjwatson> ccm: you would have to add an appropriate line to sources.list
[11:40] <cjwatson> that is normal
[11:43] <ccm> thought I'd that and the dbg package is not listed in packages.ubuntu.com either, but anyway, i can work with the url
[11:43] <ccm> thank you very much
[11:44] <pitti> ccm: what cjwatson said; see https://wiki.ubuntu.com/DebuggingProgramCrash
[11:44] <pitti> for instructions
[11:45] <cjwatson> packages.ubuntu.com only looks at the main archive
[11:45] <sebner> pitti: hallo mighty pitty \o/, any plans to merge newest debhelper? :)
[11:45] <cjwatson> debug symbol packages are intentionally in a separate archive
[11:46] <pitti> sebner: by default I'm not chasing any merges any more, unless someone asks me with a good reason :)
[11:46] <sebner> pitti: csharp support for licensecheck \o/ (Asked by me in Debian also) ^^
[11:48] <StevenK> pitti: Oh, I wanted your opinion on bug 312659?
[11:49] <pitti> "Use the bug subscription, Luke!" :-)
[11:49] <seb128> pitti: we didn't have retracers running for over a month apparently, do you plan to work on those or should I look at that (I'm busy updating GNOME but I can try to have a look this week)?
[11:49] <pitti> StevenK: will look in a minute
[11:49] <pitti> seb128: that's on my TODO list this week (get jaunty retracers up and running, and care for the other ones)
[11:49] <pitti> seb128: yesterday I fixed the client side apport stuff, now I'm ready to work on the server side
[11:50] <seb128> pitti: ok thanks, I will let you do that then, I've lot of catching up to do on GNOME
[11:50]  * seb128 hugs pitti
[11:50]  * pitti hugs the Gnominator
[11:50] <pitti> sebner: ok, can do
[11:51] <sebner> pitti: \o/. besides I think there are a lot other cool improvements since there are some versions between actual ubuntu and actual debian version
[11:51] <pitti> StevenK: looks fine to me
[11:52] <StevenK> pitti: Yeah, I think it needs to be shot, too, but wanted to check. As well as wondering if the blacklist can deal with wildcards
[11:53] <pitti> StevenK: wildcards> not as far as I know
[11:54] <cjwatson> I would doubt it
[11:55] <StevenK> That's going to be fun to sort out, then.
[11:55] <StevenK> I'll remove it and db4.3 tomorrow
[11:55] <pitti> StevenK: why? blacklist is source based
[11:56] <StevenK> pitti: Exactly. Just depends how much source packages we're talking
[11:56] <pitti> so you don't need to care about the bazillion binaries
[12:05] <superm1> pitti, well i've got a large variety of hardware (including that machine I brought to UDS) working with 177.82 that i've been using since 177.82 was released.  I was one of the original folks affected by it's original bug reported to NV (The long suspends). I'll add a comment to the bug.
[12:10] <pitti> superm1: thanks; so if you give your ok on the bug, and there aren't any reports about regressions, this is good to go
[12:10] <pitti> (sorry if that came through twice, I got disconnected)
[12:10] <superm1> pitti, okay great thanks
[12:11] <superm1> in the future need to make sure these bugs dont get hijacked by new releases so they are easier to discern and track
[12:13] <pitti> tkamppeter: I filed cups bug 3052, which is a prerequisite for changing the gtk/qt print dialogs
[12:13] <pitti> tkamppeter: I just discovered that cups doesn't actually seem to tell locally configured vs. autodetected
[12:14] <pitti> sebner: sid has 7.0.17, jaunty has 7.0.17ubuntu1 ?
[12:15] <sebner> pitti: ARGH. sry. I mean devscripts. sry sry sry
[12:15] <pitti> sebner: ah, ok; I just looked at the experimental debhelper, and that seems a bit delicate to merge
[12:17] <sebner> pitti: heh, don't worry. I'm only interested in devscripts from sid :D
[12:17] <pitti> sebner: that's a rather complicated merge; unless you beat me to it and do it yourself, mind to send me an email about it? I won't do it right now
[12:17] <pitti> or do you want to prepare and test the merge yourself?
[12:18] <sebner> pitti: I'm afraid that I won't have time besides that's stuff for pros like you :) Just do it anytime you have time and passion for it =)
[12:20] <cjwatson> StevenK: you sure that inheriting from ubuntu.jaunty (rather than platform.jaunty) is a good idea? you've given the live seed different inheritance than it has in ubuntu.jaunty, which is a bit ... interesting
[12:20] <cjwatson> though I suppose technically feasible
[12:20] <cjwatson> StevenK: have you run this through germinate to look at the result?
[12:21] <cjwatson> StevenK: no netbook-remix-dev?
[12:21] <StevenK> mobile-dev is dead
[12:21] <Baby> pitti: ping! :)
[12:21] <pitti> Baby: hello
[12:21] <StevenK> cjwatson: We don't need it and decided it was time to kill it at UDS.
[12:22] <cjwatson> ok
[12:22] <StevenK> cjwatson: platform.jaunty doesn't have ship.
[12:22] <Baby> pitti: :)
[12:22] <cjwatson> StevenK: but ubuntu.jaunty's ship inherits from desktop
[12:23] <StevenK> cjwatson: I suppose I can drop live from mobile.jaunty's STRUCTURE, and it will sort it out?
[12:23] <cjwatson> StevenK: did you consider whether you would be better off writing your own ship seed?
[12:23] <cjwatson> StevenK: do you want live or ship-live?
[12:23] <cjwatson> I'm not entirely clear on what you actually want, which makes it hard to advise :)
[12:24] <StevenK> cjwatson: Oh, right. We want the list of packages that are included as .debs on the Live CDs
[12:24] <cjwatson> that is NOT ship, it's ship-live
[12:24] <StevenK> Which I think is ship-live
[12:24] <cjwatson> very important to be clear on the distinction
[12:24] <cjwatson> what do you want in the live filesystem?
[12:25] <cjwatson> and do you really want all the stuff that's in ubuntu.jaunty's live and ship-live?
[12:25] <cjwatson> I wouldn't have thought you'd want ndiswrapper or ISDN utilities, for instance
[12:25] <StevenK> Well, from this seed base, either mobile-mid or mobile-netbook-remix plus casper and ubiquity
[12:25] <cjwatson> nor that you would necessarily want the same language packs
[12:26] <DktrKranz> could a sponsor for main look at bug 254790? It blocks some dietlibc fixes I'd like to upload.
[12:26] <cjwatson> or even perhaps the same filesystem support
[12:26] <cjwatson> StevenK: it sounds to me as if you should inherit from platform.jaunty and write your own live and ship-live seeds, just as e.g. Kubuntu does
[12:26] <StevenK> cjwatson: I said the same thing in the session, and persia talked about threatning to find a MID form-factor device with ISDN. :-)
[12:26] <cjwatson> otherwise you're going to end up with a bunch of junk you don't want
[12:27] <cjwatson> and you won't easily be able to control it
[12:27] <cjwatson> as soon as you want to control it, you're going to end up writing your own live and ship-live seeds anyway
[12:27]  * StevenK nods
[12:27] <cjwatson> so you might as well start out that way, I think
[12:27] <persia> StevenK, I threatened to show you my CF ISDN card that I used on my Zaurus for connectivity for years, rather.
[12:27] <StevenK> Yeah, makes sense.
[12:28] <cjwatson> also, if you need different shipped objects one of which is mobile-mid + live and one of which is mobile-netbook-remix + live, you're going to need two live-a-like seeds (and ship-live-a-like, presumably)
[12:28] <cjwatson> but you can perhaps worry about that later
[12:28] <StevenK> So fix that, commit that, fiddle with mobile-meta and upload it, and then prod you to fix tasksel?
[12:28] <StevenK> persia: Woot, two technologies I hate in the same device, Compact Flash and ISDN.
[12:29] <cjwatson> this is because a seed can only be germinated against a single set of ancestor seeds, and if you germinate live to inherit from netbook-remix and then try to use it with mid, you may well end up with missing dependencies
[12:29] <cjwatson> StevenK: yes. Note also that your branch doesn't seem to be up to date with current mobile.jaunty
[12:30] <StevenK> Mmmmm
[12:30] <cjwatson> so you'll need to merge into mobile.jaunty rather than just pushing over the top
[12:30] <StevenK> cjwatson: It isn't, on purpose
[12:30] <cjwatson> well that's a bug :)
[12:30] <cjwatson> don't lose history even if you want to revert it
[12:30] <StevenK> cjwatson: Oh, it's from the same base, so it's under control
[12:31] <cjwatson> fix the things I mentioned and push again, then I can have another look?
[12:31] <StevenK> Hm. I unbound, commited and push. Now what do I do ...
[12:31] <cjwatson> commit and push again?
[12:31] <cjwatson> (what are you trying to do?)
[12:32] <StevenK> Trying to figure out how to resurrect {,ship-}live
[12:32] <cjwatson> 'vi live'
[12:33] <cjwatson> or are you trying to make it have the same file-id as the corresponding files in ubuntu.jaunty so that you can merge? that may not be necessary
[12:33] <StevenK> I'm trying to get the old files back
[12:33] <cjwatson> what old files?
[12:33] <cjwatson> in what branch?
[12:34] <cjwatson> the live and ship-live seeds haven't been in mobile.jaunty since r1310
[12:34] <StevenK> {,ship}live used to exist in mobile.{intrepid,jaunty}
[12:35] <StevenK> Yup, those are what I'm trying to resurrect, since they probably have most of the right content
[12:35] <cjwatson> so, firstly, you *could* just re-add them afresh; essentially the only thing that will break is merges from ubuntu.jaunty, which are not that important anyway
[12:35] <cjwatson> however, it is *slightly* more elegant to have them share a file-id I suppose
[12:35] <persia> bzr revert ship --revision 1310 ?
[12:35] <persia> Err.  --revision=1310
[12:36] <StevenK> Ah, that would be the magic
[12:37] <cjwatson> oh, that works, I was going to suggest get -r1309 and add --file-ids-from
[12:37] <cjwatson> but persia's approach is shorter
[12:37] <cjwatson> also, -r1309 not 1310 (1310 is the revision that removed them)
[12:37] <persia> Oh, right.
[12:37] <persia> Also probably want to use the correct filenames.
[12:37] <StevenK> Yeah, I remembered that, and s/10/09/ before running
[12:37] <StevenK> I did that too
[12:38]  * StevenK waits for bzr push
[12:38] <StevenK> cjwatson: Pushed
[12:39] <StevenK> cjwatson: I didn't change what live inherients from, since I'm still unsure about that bit.
[12:52] <tkamppeter> pitti, CUPS is already capable of telling whether a queue is locally defined or picked up from a broadcast. CUPS queues have a CUPS_PRINTER_DISCOVERED bit set then. See /usr/include/cups/cups.h, enumeration cups_ptype_e.
[12:53] <Keybuk> sure
[12:54] <Keybuk> cjwatson: udev has the same need
[12:54] <Keybuk> we load modules, but want to silently succeed as cheaply as possible if the module is a built-in
[12:54] <cjwatson> apw: http://bazaar.launchpad.net/~ubuntu-core-dev/hw-detect/ubuntu/revision/104, http://bazaar.launchpad.net/~ubuntu-core-dev/mdcfg/ubuntu/revision/1072, and http://bazaar.launchpad.net/~ubuntu-core-dev/partman-md/ubuntu/revision/909 are all bodges around this same problem
[12:54] <cjwatson> apw: the second and third are sane enough actually, but the first is a good illustration of the difficulty
[12:55] <cjwatson> (the second and third were patches for real installer bugs TBH; it was using has-the-module-been-loaded-yet as a key for rather too much initialisation code)
[12:55] <apw> ok so why can't we just modprobe, ignore the result
[12:55] <apw> and then try and use the functionality and blow up then if its not there?
[12:56] <cjwatson> the installer tries to support a variety of kernels fairly cleanly, partly because of custom kernels (people do in fact do that quite a bit) and partly because the kernel keeps changing under us :)
[12:56] <cjwatson> and it's much better to be able to report "this facility is unavailable" rather than "thingummyflop blew up with ENOSYS"
[12:56] <cjwatson> (or EINVAL more likely I guess)
[12:56] <apw> right, but is not the test in #3 there actualy a 'do we have the function'
[12:57] <apw> that should be after an ignored modprobe
[12:57] <cjwatson> probably best look at #1 instead
[12:57] <cjwatson> the module_probe function there is a wrapper for something that tries to load the module and otherwise fails with a red-screen
[12:57] <Keybuk> the difficult bit is telling the difference between "module is built-in" and "module is missing"
[12:57] <cjwatson> and the bodge is that I've had to incorporate a check for whether the function is present
[12:58] <apw> right, you've done what i am saying
[12:58] <cjwatson> which is, frankly, a pig to do sometimes; it's not easily possible for dm-round-robin without actually setting up a hardware round-robin multipath, for instance
[12:58] <apw> just i think you should probe the modules as well
[12:58] <apw> and ignore any failure
[12:58] <apw> so it works either way
[12:58] <cjwatson> I think that would be a straightforward regression in the installer's ability to report errors
[12:58] <cjwatson> it would fall over much later with a much more obscure error
[12:59] <apw> not if you do it like
[12:59] <apw> if ! dmsetup version; then
[12:59] <apw>   modprobe foo || true
[12:59] <apw>  if ! dmsetup_version; then
[12:59] <apw>     ERROR
[12:59] <cjwatson> so how do I do that for dm-round-robin please? :)
[13:00] <cjwatson> (I did look, quite hard)
[13:00] <apw> well there is an issue
[13:00] <apw> do you always know the kernel before hand?
[13:00] <cjwatson> and honestly, all this having to putz about with dmsetup is really clumsy
[13:00] <Keybuk> doesn't that defeat the object of building in in the first place
[13:00] <cjwatson> that code used to be 'module_probe dm-mod'
[13:00] <cjwatson> quick and easy
[13:00] <Keybuk> if it's more expensive to determine whether something is built-in than to load it as a module ?
[13:00] <cjwatson> right, I definitely want something as lightweight as possible
[13:01] <apw> ...
[13:01] <apw> so does the installer CD know the kernel its built with?
[13:01] <apw> could we extract the information out of the kernel as we build the CD?
[13:01] <cjwatson> the installer CD might, but I'm not going to hardcode that knowledge into installer scripts!
[13:01] <apw> so you _know_
[13:01] <cjwatson> some of this code is run in contexts where that is not helpful
[13:01] <apw> stupid kernel
[13:02] <cjwatson> it would be *much* *MUCH* better for it to detect; Keybuk's proposed modprobe option is *exactly* what I'm looking for
[13:02] <apw> but modprobe simply cannot know
[13:02] <apw> as things stand, either its =y or =n, but i don't know which
[13:02] <cjwatson> isn't the presence of the driver exposed in /sys?
[13:03] <cjwatson> also, BTW, it's not a matter of what the installer CD is built with; the installer loads udebs containing kernel modules into memory at runtime
[13:03] <apw> that is true of some modules, but like crypto, does that appear as a driver?
[13:03] <cjwatson> the modular ones do
[13:03] <cjwatson> the non-modular ones *currently* don't
[13:04] <cjwatson> but we could just go back to building them as modules until that knowledge is available
[13:04] <cjwatson> though we'd still have the dm problem
[13:05] <apw> well you may have a case to back those out if we cant get a sensible fix before JJ releases
[13:05] <apw> one of the good things is that you have blown up now, before it set in stone
[13:05] <Keybuk> cjwatson: the presence of a driver is exposed
[13:05] <Keybuk> not the presence of a module
[13:05] <Keybuk> you don't pass driver names to modprobe
[13:05] <Keybuk> you pass module names
[13:05] <cjwatson> apw: indeed
[13:06] <apw> module aliases may help here to convert back
[13:06] <cjwatson> Keybuk: I don't see e.g. dm-mod exposed anywhere in /sys
[13:06] <Keybuk> right, it wouldn't be
[13:06] <Keybuk> it's a subsystem
[13:09] <apw> we do build in the config, into the kernel right?
[13:10] <apw> so we can get it out in theory
[13:11] <cjwatson> are you thinking of CONFIG_IKCONFIG_PROC?
[13:11] <apw> after boot, so we can reconstruct /boot/config-*
[13:11] <apw> we have half of that turned on
[13:11] <apw> the half that keeps the stuff in the on disk binary image of the kernel
[13:11] <apw> i believe
[13:11] <cjwatson> I would echo Keybuk's comment that grepping a text file (kernel-generated or otherwise) for this is going to be slow
[13:11] <Keybuk> I have an amusing idea ;)
[13:12] <Keybuk> you could auto-generate a modprobe.d blacklist file
[13:12] <cjwatson> you could have /sys/config/FEATURE
[13:12] <cjwatson> present or absent
[13:12] <apw> cjwatson, the code you have there is running a depmod -a
[13:12] <apw> so any single additional grep is free by comparison
[13:12] <Keybuk> apw: who would own the list of config -> module name mappings?
[13:13] <cjwatson> that's only because it might have just loaded modules. The same consideration does not apply during boot
[13:13] <cjwatson> er by loaded modules I mean installed some udebs containing modules
[13:13] <cjwatson> that is also not the case in every installer context in question
[13:15] <apw> Keybuk, i wonder if that is expressed in the kernel
[13:15] <Keybuk> apw: it would have to be
[13:16] <Keybuk> maintaining a kernel config (kernel maintained) to module name (kernel maintained) mapping outside the kernel is not exactly a plan made of awesome
[13:17] <Keybuk> from the modprobe pov. we simply need a list of module names that we can silently succeed because they have been built-in
[13:17] <cjwatson> yeah, I'm not keen on having to name the feature in installer code either
[13:18] <cjwatson> from my POV the config feature name is a kernel implementation detail that might change at any time; the module names are at least a little more persistent than that
[13:18] <apw> and none of it is obvious in the source
[13:19] <Keybuk> implementing the "succeed silently" in modprobe is easy
[13:19] <Keybuk> we just make the module name an empty alias
[13:19] <apw> the hard part is getting that list
[13:19] <cjwatson> could that be exported via depmod then
[13:19] <Keybuk> so modprobe dm-mod would be equilent to just modprobe ""
[13:19] <cjwatson> ?
[13:19] <Keybuk> cjwatson: yeah, I'd append it to modules.alias
[13:19] <Keybuk> the hard part, as apw says, is getting that list
[13:20] <apw> what if we did a hybrid approach
[13:20] <apw> you tell us which modules you are using and somehow we work out the config
[13:20] <apw> options they represent
[13:20] <Keybuk> apw: from a udev point of view, everything ;)
[13:20] <cjwatson> apw: that's really tricky in general, that installer code is dynamic, synced/merged from Debian, etc.
[13:21] <apw> perhaps that could be kept with the config info so it would be kept up to date
[13:21] <cjwatson> where does the information that goes into modinfo come from?
[13:21] <Keybuk> cjwatson: the modules themselves
[13:21] <Keybuk> it's a section in the .ko that depmod reads
[13:21] <cjwatson> Keybuk: right, but I mean where in the kernel source
[13:21] <cjwatson> what's the macro that does it
[13:21] <cjwatson> or struct or whatever
[13:21] <apw> the module alaises, are complex
[13:21] <apw> there are some magic programs which mush it about to make them
[13:22] <apw> from some of the other structures in the kernel
[13:22] <Keybuk> actually, that's an interesting point, we'd need the modaliases of the modules that are built-in too
[13:22] <apw> just been looking at it for MMC
[13:22] <cjwatson> but at least it is in the C files and not just in the Makefiles
[13:22] <Keybuk> otherwise we'd waste a lot of time
[13:22] <cjwatson> which means the problem is tractable
[13:22] <apw> but you can't tell from the foo.c what the .ko is called
[13:22] <cjwatson> you just need to make MODULE_* do something useful for built-in drivers
[13:22] <cjwatson> oh, that is only in Makefile?
[13:22] <cjwatson> bah
[13:22] <Keybuk> the name of the module is only in the Makefile
[13:23] <Keybuk> apw: what happens to MODULE_DEVICE_TABLE for the kernel?
[13:23] <Keybuk> in fact, can you extract MODULE_* at all for built-ins ?
[13:23] <apw> there is a a script which converts that into specific format MODULE_ALIAS entries
[13:23] <cjwatson> you'd have to put a section in vmlinuz that's later stripped
[13:23] <cjwatson> I think
[13:23] <apw> which are then compiled and linked with the .o to make the .ko
[13:24] <Keybuk> apw: yeah, but where do they go when you link the .o into built-in.o ?
[13:24] <apw> hrmm, you mean is there one in vmlinux
[13:24] <apw> that we are not looking at
[13:24] <Keybuk> that's what I mean, yes ;)
[13:24] <apw> when i was looking at depmod (a long time ago) i think it did read and skip vmlinux for most things
[13:24] <apw> so it might be in there
[13:25] <cjwatson> __MODULE_INFO is an empty macro for built-ins
[13:25]  * apw needs a module which is built in
[13:25] <Keybuk> unix
[13:25] <cjwatson> right now, the information is not in the .o files that get linked into built-in.o
[13:25] <cjwatson> but it could be if you mucked about with moduleparam.h
[13:25] <apw> yeah, so there is no equivalent
[13:25] <apw> well you'd need to modpost vmlinux too
[13:26] <cjwatson> well, I didn't think it could be done entirely without kernel changes, certainly
[13:26] <Keybuk> cjwatson: the other problem is the kernel developers got clever with Make
[13:26] <cjwatson> but I was wondering if there was a relatively lightweight set of changes possible
[13:26] <Keybuk> so the only difference between a .ko compile and a .o one is just whether some variable is y or m ;)
[13:26] <Keybuk> obj-y += something.o
[13:26] <Keybuk> vs.
[13:26] <Keybuk> obj-m += something.o
[13:26] <cjwatson> yeah, I know
[13:26] <cjwatson> MODULE is defined for obj-m, though
[13:27]  * Keybuk can't remember where the ko names are defined
[13:27] <apw> ok lets look at it the other way round
[13:27] <apw> we have a probe point 'module_init'
[13:27] <apw> right now when we load one it makes /sysfs/module/<foo>
[13:28] <apw> perhaps we could hijack that and have a /sys/build-in/<foo> appear
[13:28] <Keybuk> couldn't we just have a /sys/module/<foo> for built-ins?
[13:28] <cjwatson> hm, excuse me, baby needs feeding
[13:29] <Keybuk> I guess you wouldn't do that actually, because the kobjects would be different
[13:29] <Keybuk> but /sys/built-in/<foo> would be nice
[13:31] <Keybuk> apw: actually, where *are* module names defined?!
[13:31]  * apw is looking at that right now
[13:31] <apw> there is a MODULE define floating about
[13:37] <apw> actually the specific line obj-$(CONFIG) += foo.ko
[13:38] <apw> does give you the mapping from CONFIG_foo to foo.ko
[13:38] <Keybuk> err
[13:38] <Keybuk> I don't see that line anywhere?
[13:38] <Keybuk> it's always
[13:38] <Keybuk> obj-$(CONFIG) += foo.o
[13:38] <apw> obj-$(CONFIG_DM_DELAY)          += dm-delay.o
[13:39] <apw> yeah that one
[13:39] <apw> and that _is_ the .ko name
[13:39] <Keybuk> so the ko name is the name of the first object?
[13:39] <apw> not the first object,
[13:39] <apw> all objects
[13:39] <Keybuk> err
[13:39] <apw> everything on the right there is a real module
[13:39] <Keybuk> how does it deal with multiple .o files for one module?
[13:39] <apw> obj-$(CONFIG_BLK_DEV_DM)        += dm-mod.o
[13:39] <Keybuk> obj-$(CONFIG_HERMES)            += orinoco.o hermes.o hermes_dld.o
[13:39] <apw> dm-mod-objs     := dm.o dm-table.o dm-target.o dm-linear.o dm-stripe.o \
[13:39] <apw>                    dm-ioctl.o dm-io.o dm-kcopyd.o
[13:39] <apw> via _magic_
[13:40] <Keybuk> oh, I see what you mean
[13:40] <apw> /lib/modules/2.6.27-10-generic/kernel/drivers/net/wireless/hermes.ko
[13:40] <apw> yeah all of yours there are real places
[13:41] <apw> s/places/modules
[13:44] <apw> Keybuk, it is _possible_ we still have a THIS_MODULE, when we are building in
[13:44] <apw> if so we migth be able to magic up soimething in /sys/ for the module names
[13:44] <apw> needs some playing ...
[13:45]  * apw drops to test a kernel
[13:51] <soren> Sorry, but I don't see why we can't just grab whatever's in obj-y and put that in the blacklist file as Keybuk suggested (stripping the .o extension, of course).
[13:51] <Keybuk> soren: I'd put it in the alias file
[13:52] <soren> Right, or that.
[13:52] <soren> Is the obj-y variable perhaps not global?
[13:52]  * soren hasn't really quite worked out the details of the kernel's makefile magic yet
[13:53] <soren> Oh, right, definitely the alias file.
[13:55]  * soren was still thinking in installer context, but of course we want this in the installed system as well and have it work with different versions of the kernel installed.
[14:16] <cjwatson> StevenK: as long as you merge into current mobile.jaunty (should end up with the same output) to preserve history, then I think that's fine
[14:16] <cjwatson> StevenK: I do think you're likely to want to pare down live and ship-live at some point
[14:16] <cjwatson> StevenK: but otherwise go ahead
[14:20] <slytherin> could an archive admin please prioritise the sync of plexus-io (bug #312789) from unstable: it's blocking processing of a host of other syncs for maven support
[14:23] <cjwatson> slytherin: done
[14:23] <cjwatson> yeesh, enough duplicates? :)
[14:24] <slytherin> cjwatson: that was due to the bug in requestsync. :-)
[14:24] <slytherin> cjwatson: thanks.
[14:25] <Laney> Which release first enabled recommends-by-default? Intrepid or Hardy?
[14:26] <seb128> intrepid
[14:26] <Laney> thanks
[14:37] <soren> Apparantly, I told the update-grub ucf thing the wrong thing at some point, and now my menu.lst is never updated anymore. How am I supposed to fix this?
[14:37] <soren> I know how I *could*, but how *should* I do it?
[14:39] <ScottK> File a bug and then complain a lot?
[14:39] <soren> Not my style :)
[14:40] <ScottK> Right, mine neither, but it seems the most common approach.
[14:44] <slytherin> cjwatson: can you please also check the plexus-io binary in queue if you have time?
[14:49] <cjwatson> slytherin: done
[14:50] <slytherin> cjwatson: thanks. Now I can lods of sync requests when I go home. :-)
[14:51] <persia> soren, do an md5sum, and push that to the ucf md5sum file.
[14:51] <soren> persia: Seriously? That's what we tell users to do?
[14:52] <persia> soren, man ucf provides detailed instructions on this procedure.
[14:52] <soren> persia: As I said: I know how I *could* do it. :)
[14:52] <persia> In practice it's usually something like md5sum foo.conf > md5sum file.
[14:52] <persia> Since it's a one-liner, it's been historically easy to put on wiki pages, in IRC, etc.
[14:53] <persia> soren, Feel free to implement --takeover if you prefer :)
[14:55] <pitti> tkamppeter: oh, cool, thanks; seems that lpstat just does not expose that
[15:18] <kirkland> cjwatson: okay, so what action is to be taken with respect to the crypto modules?  should that patch be reverted by rtg?
[15:19] <kirkland> cjwatson: and they be added to crypto-modules?
[15:19] <kirkland> cjwatson: or are we holding out for a magic modprobe option that --succeeds-if-already-built-in ?
[15:19] <cjwatson> well, that would be my favoured action for now, although if some magic modprobe option is likely to be feasible in the short term then that would be fine
[15:19] <cjwatson> rtg: what do you think?
[15:21] <rtg> cjwatson: I don't have an issue with restoring crypto as modules, but it seems like this is gonna be a generic issue with the installer, i.e., determining what functionality exists in the kernel v.s. modules.
[15:21] <rtg> its just 3 more modules that have to be installed at boot time
[15:21] <cjwatson> it is a generic issue, but I think for the sake of expediency I would be happy to work around it elsewhere; it's just that crypto turns out to be rather hard to work around in that kind of way
[15:21] <cjwatson> apw pointed out that if you're using crypto modules then you're probably going to end up stopping and waiting for a password anyway
[15:22] <cjwatson> really the only other significant case is dm*, and I've basically already worked around that (albeit with some internal cursing :-) )
[15:22] <rtg> kirkland: that true? when auto-login is enabled?
[15:23] <cjwatson> at any rate, I'm not sure the encrypted-filesystem case should be taken as the fast path
[15:23] <rtg> cjwatson: we made the assumption that any file system that is oft used should be built in
[15:24] <cjwatson> I understand that, just saying that if you're encrypting filesystems then your system is going to take longer to boot anyway
[15:25] <rtg> cjwatson: ok, I'll back out those changes, i.e., crypto-fs, CBC, AES, and (something else, can't remember exactly).
[15:27] <kirkland> rtg: is what part true?
[15:27] <cjwatson> rtg: thanks, much appreciated; that'll relieve some headaches
[15:27] <rtg> kirkland: do you have to pause for a crypto passwd during auto-login?
[15:27] <cjwatson> rtg: I suspect that the modprobe --ok-if-built-in option is the right long-term answer
[15:27] <kirkland> rtg: ebc
[15:28] <kirkland> rtg: if you are auto-logging in, on a machine installed on top of lvm+crypt, then yes
[15:28] <rtg> kirkland: how about encrypted /home or Private?
[15:29] <kirkland> rtg: you're talking about an encrypted private directory, plus auto-login, you'll get prompted when you open your Private directory
[15:29] <kirkland> rtg: encrypted home + auto-login are mutually exclusive
[15:29] <rtg> kirkland: good, thats what I expected :)
[15:29] <kirkland> rtg: ie, yes, you will need to enter a password to login to a system with an encrypted home
[15:30] <kirkland> cjwatson: okay, so rtg is going to back out cbc, aes, and ecb of kernel builtin's ...  who's going to make sure that they simultaneously get pushed to crypto-modules?
[15:30] <cjwatson> that happens automatically, relax :)
[15:30] <kirkland> cjwatson: :-)
[15:30] <rtg> cjwatson: it'll take an hour or 2, but I'll get those changes uploaded today.
[15:31] <cjwatson> crypto-modules is built by the kernel
[15:31] <cjwatson> rtg: oh, you will need to make sure they're listed in debian/d-i/modules/crypto-modules in the same commit though
[15:31] <rtg> I also have to remember to get them back into the d-i information
[15:31] <kirkland> cjwatson: and what about getting the encrypt-home code in the installer to apt-get install crypto-modules?  should i make ecryptfs-utils depend on that?
[15:31] <cjwatson> kirkland: I already did that
[15:31] <kirkland> cjwatson: \o/
[15:32] <cjwatson> the only possible change still required is to have user-setup modprobe some things up-front before chrooting
[15:32] <kirkland> cjwatson: ah, okay.  i will need those 3 modules loaded, before running ecryptfs-setup-private (aes, cbc, ecb)
[15:33] <cjwatson> is there any circumstance in which it might want different modules?
[15:33] <tkamppeter> pitti, I have a question about a possible Intrepid SRU, where the fix is not a small patch.
[15:34] <kirkland> cjwatson: well, ecryptfs support far more ciphers, but the "Ubuntu Encrypted Private" and "Ubuntu Encrypted Home" setups are fairly constrained to aes
[15:35] <cjwatson> ok, on its way
[15:36] <cjwatson> and then that should make partman-crypto automatically start working again
[15:43] <pitti> tkamppeter: well, ask :)
[15:54] <alex-weej> does anyone know the status of multiarch?
[15:54] <alex-weej> i am continuously kicked in the balls for running 64 bit
[15:54] <alex-weej> wine needs 32 bit pulseaudio ALSA plugin in order to work properly
[15:55] <alex-weej> and it's not in ia32-libs
[15:55] <cjwatson> no status to the best of my knowledge
[15:55]  * directhex summons Mithrandir 
[15:55]  * alex-weej wonders if it's worth opening a blueprint
[15:56] <cjwatson> I doubt it
[15:56] <cjwatson> I mean, you could add to the thousands of blueprints that already exist
[15:57] <cjwatson> but it won't have any effect on magicking up people to work on it
[15:57] <alex-weej> of course, but at least it can be tracked better and i wouldn't have to come here asking
[15:57] <directhex> did you do a search for blueprints before asking?
[15:58] <cjwatson> only if there's only one canonical (ahem) blueprint for it. In reality I suspect there are several already, none of which have their status updated ...
[15:58] <alex-weej> directhex: i googled.
[15:58] <alex-weej> nothing
[15:58] <cjwatson> items not on the roadmap and without developers working on it simply aren't going to have status regularly updated
[16:02] <tkamppeter> pitti, it is bug 314018. The GS 8.63 breaks bold text in PS output of OOo when converting to PDF while printing (/usr/lib/cups/filter/pstopdf.
[16:03] <tkamppeter> pitti, this problem is fixed in Ghostscript 8.64 (release on Feb 1), see http://bugs.ghostscript.com/show_bug.cgi?id=689970 and http://bugs.ghostscript.com/show_bug.cgi?id=690220
[16:03] <pitti> tkamppeter: is this a regression?
[16:04] <tkamppeter> pitti, yes. In Hardy PS never got converted to PDF when printing.
[16:05] <tkamppeter> Unfortunately, the fix is not a simple patch, see http://bugs.ghostscript.com/show_bug.cgi?id=690025#c7 which refers to fixes for the above-mentioned two bugs.
[16:13] <pitti> tkamppeter: so it's http://ghostscript.com/pipermail/gs-cvs/2008-November/008772.html and http://ghostscript.com/pipermail/gs-cvs/2008-November/008827.html ?
[16:13] <pitti> tkamppeter: size-wise they are quite big, indeed, but still bearable with lots of testing
[16:13] <pitti> tkamppeter: however, the second patch changes the API/ABI, which worries me
[16:13] <pitti> we shouldn't do that in an SRU
[16:19] <pitti> tseliot: hey, happy new year!
[16:20] <tseliot> pitti: happy new year to you ;)
[16:20] <tkamppeter> pitti, and they say that the patches are based on more text rendering improvements.
[16:20] <pitti> tseliot: we will go through the specs in today's desktop team meeting and take a look at what's realistic for Jaunty; would you like to (and do you have time to) join?
[16:20] <pitti> tkamppeter: is there an easier workaround?
[16:21] <tseliot> pitti: sure, when/where is it?
[16:21] <pitti> changes to ghostscript have a large regressio npotential
[16:21] <pitti> tseliot: in 9 minutes (1730 CET) in #ubuntu-desktop
[16:21] <tseliot> pitti: ok, I'll be there
[16:22] <pitti> great, thanks
[16:22] <pitti> tseliot: you can lurk, I'll ping you when it becomes interesting for you; shouldn't take more than 10 minutes for you
[16:22] <tseliot> ok, great
[16:36] <tkamppeter> pitti, I have done two quick tests with OOo by myself and Bold printing works for me. So the bug seems to occur only with certain fonts (otherwise we must have already received complaints before release of Intrepid). So it seems that the bug is not so severe.
[16:43] <pitti> Riddell: this print dialog http://people.ubuntu.com/~pitti/screenshots/print_dialog_kde.png -- is this Qt, or KDE?
[16:44] <pitti> Riddell: I'd like to file the corresponding Qt/KDE bug for bug 314408 upstream
[16:44] <Riddell> pitti: there's no kde dialogue any more, Qt only
[16:44] <pitti> Riddell: ah, nice, thanks
[16:44] <tkamppeter> pitti, I have found a simple workaround: When one runs "ps2ps" over the faulty PS file and prints (or converts with ps2pdf) the resulting PS file, the output is correct.
[16:45] <Riddell> pitti: Qt bugs go to http://trolltech.com/developer/task-tracker
[16:45] <Riddell> or ask ThomasZ
[16:48] <tkamppeter> pitti, so one only needs to check whether incoming PostScript is from OOo and if so one massages it with ps2ps, as one already does with incoming PS from encrypted PDFs printed with Adobe Reader.
[17:04] <dholbach> bryce: will you upload the patch on bug 181948?
[17:05] <bryce> dholbach: I can.  I reviewed it when we were in freeze so assumed someone would take care of it later
[17:07] <dholbach> bryce: rock on! :)
[17:07] <sebner> dholbach: may I answer in german if it's only for you? :)
[17:07] <dholbach> sebner: eh?
[17:08] <sebner> dholbach: you sent me a mail today about further questinos
[17:08] <sebner> *questions
[17:08] <dholbach> sebner: sure, do it if that's easier for you
[17:08] <dholbach> that's fine :)
[17:08] <dholbach> thanks in advance
[17:08] <bryce> dholbach: speaking of which... I do my 1-hr sponsorship each week, however post-freeze it is problematic because you can't upload anything
[17:08] <sebner> dholbach: I don't care but since we are both native german speakers ^^
[17:09] <bryce> dholbach: this last go-around I still did it, but just listed my view on patches even if they couldn't be uploaded at the time
[17:09] <dholbach> bryce: I know - I think it's good to state that, unsubscribe the team and assign it to you, so you can upload it in the next cycle
[17:09] <bryce> dholbach: however I wonder if it even makes sense to be doing any sponsorship work post-freeze
[17:09] <dholbach> bryce: it very much depends on the case
[17:09] <dholbach> if it's important, it should go in
[17:09] <bryce> dholbach: well I'm usually not one to judge importance, since they're almost always non-xorg stuff
[17:10] <dholbach> if it has a bunch of duplicates and fixes it, it should go in :)
[17:10] <dholbach> a simple string fix can wait for release+1
[17:19] <Keybuk> cjwatson: what's $dh{NOSCRIPTS} all about?
[17:20] <Keybuk> looking at dh_installudev, it seems to have a block to modify preinst/postinst
[17:20] <Keybuk> but we don't use that do we?
[17:21] <cjwatson> $dh{NOSCRIPTS} is set when the -n option is used
[17:22] <cjwatson> and we certainly do use that block, in that it's active - I have no idea whether it does anything useful for us
[17:22] <cjwatson> the script fragments in question are in autoscripts/
[17:22] <cjwatson> and appear to be moving conffiles around
[17:23] <cjwatson> cf. debhelper 5.0.45 changelog
[17:24] <Keybuk> right
[17:24] <Keybuk> but they're moving things in/out of the parent directory of udev
[17:25] <Keybuk> which is things Debian do, but not us
[17:25] <cjwatson> might affect sidegrades from old versions of Debian to Ubuntu, but *shrug*. If you want to remove it it's your call. Don't you need similar logic to decide whether to remove or keep files in /etc/udev/rules.d/ anyway though?
[17:26] <Keybuk> hmm
[17:26] <Keybuk> looks like it's sidegrade stuff yeah
[17:27] <Keybuk>   * dh_installudev: Install udev rules directly into /etc/udev/rules.d/, not
[17:27] <Keybuk>     using the symlinks. MD has agreed that this is more appropriate for most
[17:27] <Keybuk>     packages.
[17:27] <Keybuk> matches that changelog entry
[17:27] <Keybuk> I was thinking of abusing that to handle the automigration yeah ;)
[17:28] <cjwatson> you could always just extend it; I tend to leave such code there forever
[17:28] <cjwatson> (but I have the feeling we've had this discussion before ...)
[17:29] <Keybuk> :D
[17:30] <Keybuk> well, yes
[17:30] <Keybuk> as in copying that block a couple more times
[17:30] <Keybuk> I thought we must have that disabled somehow, but it doesn't look like it
[17:30] <Keybuk> I can see it in preinsts, etc.
[17:46] <Keybuk> cjwatson: http://people.ubuntu.com/~scott/debhelper_7.0.17ubuntu2.debdiff
[17:46] <Keybuk> does that look sane?
[17:49] <tkamppeter> pitti, I hav now suggested a workaround to the reporters of bug 314018, but if one uses a printer with the pxlmono Ghostscript driver one gets easily bitten by http://bugs.ghostscript.com/show_bug.cgi?id=690025 then. So the workaround is not perfect.
[17:51] <mathiaz> zul: there was discussion about kde requiring mysql 5.1 in jaunty
[17:52] <zul> is it on a mailing list somewhere
[17:52] <cjwatson> Keybuk: substituting the same autoscript twice is a bit unusual and perhaps deserves a comment, but it looks like it should be OK, yes
[17:52] <Riddell> not sure what the context for this conversation is but amarok needs mysql 5.1's embedded library
[17:53] <Riddell> mathiaz, zul ^^
[17:53] <Keybuk> cjwatson: ironically, this means our dh_installudev matches udev upstream ;)
[17:53] <Keybuk> and Debian's changes everything strangely :p
[17:53] <cjwatson> heh
[17:53] <zul> Riddell: we are thinking about upgrading mysql 5.1 for jaunty
[17:53] <mathiaz> Riddell: right - that's what I remember
[17:53] <Keybuk> and I so keep typing devmapper when I mean debhelper
[17:54] <zul> mathiaz: 117 packages will need to be updated for the mysql library
[17:54] <Riddell> zul: who's we?  I believe server team want 5.0 from UDS conversations
[17:54] <mathiaz> Riddell: and amarok is targeted for main for jaunty?
[17:54] <zul> Riddell: correct
[17:54] <Riddell> mathiaz: it would be a big blow if it wasn't
[17:54] <Keybuk> actually, that's not quite right :-/
[17:56] <mathiaz> zul: considering that we only want one version of mysql in main, we'll have to decide if we go for 5.1 soon
[17:57] <zul> mathiaz: im just afraid of things that will break if we do decide to go for 5.1
[18:03] <Keybuk> cjwatson: http://people.ubuntu.com/~scott/debhelper_7.0.17ubuntu2.debdiff
[18:03] <Keybuk> that should be much better
[18:05] <cjwatson> oh yes, of course it would have to be a different fragment
[18:05] <Keybuk> that'll remove /etc/udev/rules.d/NN-something.rules if unmodified
[18:05] <Keybuk> because the package ships /lib/udev/rules.d/NN-something.rules anyway
[18:05] <cjwatson> Keybuk: you should check $old ne $rule for the postinst substitution
[18:06] <Keybuk> if modified, it'll leave it - udev handles the override
[18:06] <Keybuk> ah, good point
[18:06] <Keybuk> rather than $default
[18:06] <cjwatson> (which can supersede the $default check, I think)
[18:06] <cjwatson> I'm struggling to figure out why you're moving it about inside /etc in the postinst
[18:06] <Keybuk> isn't it directly equivalent?
[18:07] <Keybuk> because if it was previously using the default, it would be 50-foo.rules
[18:07] <Keybuk> but would now have /lib/udev/rules.d/40-foo.rules
[18:07] <cjwatson> not directly equivalent if $dh{PRIORITY} happens to be 50 but not $default
[18:07] <Keybuk> so it moves the one in /etc to 40-foo.rules to match
[18:07] <Keybuk> err, if $dh{PRIORITY} is 50, then it'll be 50 across the board
[18:07] <cjwatson> oh, err, right. I think. ok
[18:07] <Keybuk> so you don't need to do the move
[18:07] <Keybuk> you only need to do the move because the default changes
[18:08] <Keybuk> if you're not using the default, no move is required
[18:08] <cjwatson> oh, yeah, I see how $default is handled above
[18:08] <cjwatson> I think that debdiff is fine
[18:09]  * Keybuk tests on a selection of packages
[18:10] <pitti> tkamppeter: (was in a meeting, will reply in 30 mins)
[18:33] <Keybuk> hah!
[18:34] <Keybuk> only two packages in our default install actually use dh_installudev *sigh*
[18:35] <sebner> Keybuk: ahoi! I heard you are responsible for MoM. What's now with new MoM -> DaD progress?
[18:35] <Keybuk> sebner: I don't know
[18:35] <sebner> nah
[18:36] <sebner> Keybuk: so who knows? ;)
[18:36] <Keybuk> Adri2000 I guess
[18:37] <Adri2000> ahah
[18:37] <sebner> Keybuk: he told me to ask you :P
[18:38] <Adri2000> bug #192972
[18:38] <Keybuk> yay loop
[18:48] <Adri2000> Keybuk: is there something I can do to help get the "server support" ?
[18:48] <Keybuk> Adri2000: well, the basic problem is your patch relies on mod_python
[18:48] <Keybuk> MoM is an attractive attack vector if it suddenly has server scripting support
[18:49] <Keybuk> so any script code should be very paranoid and very well audited
[18:49] <Keybuk> CGI would be inherently nicer
[18:52] <Adri2000> ok. well if you really want cgi, given that I don't know much about it, if anyone wants to help out with that, it'd be very welcome
[18:52] <cjwatson> Keybuk: I was going to make pcmciautils use it in this round
[18:52] <Keybuk> (elmo is disagreeing with me, which goes to show you should never second guess a sysadmin :p)
[18:55] <Adri2000> Keybuk: who makes the final decision of whether mod_python is ok or not?
[18:56] <Keybuk> Adri2000: canonical sysadmin, I guess
[18:56] <Keybuk> I don't think we have a procedure :p
[18:57] <LaserJock> Keybuk: armwrestle?
[18:57] <LaserJock> maybe rock-paper-scissors
[18:57] <LaserJock> or mao
[18:58] <jpds> LaserJock: Chess.
[18:58] <Mithrandir> I think you have to make elmo do his laugh-of-doom
[18:59] <Mithrandir> nah, too easy.
[19:00] <LaserJock> heh
[19:00] <elmo> well, I'm less concerned about CGI vs mod python, than I am about the generic security issues, and honestly, I think someone with a background in web security needs to look at this
[19:00] <elmo> unless I'm missing something glaring, it does absolutely no filtering on the comments whatsoever
[19:07] <Adri2000> right
[19:20] <pitti> tkamppeter: only with certain fonts> that's relieving
[19:20] <pitti> Riddell: I filed a bug there, but didn't get an URL, nor does it appear in the search; do these tickets get manual approval?
[19:22] <pitti> tkamppeter: pstops> can this be done in /etc/cups/oopstops.convs, or in the oopstops filter itself?
[19:25] <pitti> tkamppeter: I replied to the bug report, let's discuss it there (I'm sub'ed now)
[19:30] <Riddell> pitti: yes they're hidden until someone approves it
[19:43] <pitti> Riddell: ah, ok; thanks
[19:50] <tkamppeter> pitti, are you sure that you have posted into bug 314018? You are subscribed there, but there is no comment from, you.
[19:53] <pitti> tkamppeter: weird -- seems it ate my comment
[19:53] <pitti> tkamppeter: anyway, it was just what I asked here in IRC
[19:58] <slytherin> cjwatson: do you have time for few more syncs?
[20:00] <tkamppeter> pitti, I have answered to bug 314018.
[20:01] <pitti> tkamppeter: ah, thanks; well, if it's easier to implement in pstopdf, I'm okay with it; I looked at the diff, and it looked quite focussed
[20:02] <tkamppeter> pitti, my only problem with it is that it breaks pxlmono/pxlcolor: http://bugs.ghostscript.com/show_bug.cgi?id=690025
[20:03] <pitti> tkamppeter: ah, right, I remember; if it actually breaks existing things, it doesn't qualify for an SRU
[20:03] <pitti> if it's too hard to fix, we should probably just leave it alone in intrepid and just fix it properly in jaunyt
[20:03] <pitti> it's not the worst bug in the world
[20:04] <pitti> kirkland: do you think you can have ecryptfs-desktop-ui drafted by the end of the week? do you think it's a realistic target for jaunty?
[20:04] <pitti> kirkland: (I wonder if I should put it as a jaunty goal)
[20:06] <kirkland> pitti: hey
[20:06] <pitti> happy new year, Dustin!
[20:06] <kirkland> pitti: same to you!
[20:06] <kirkland> pitti: hmm, i can draft the to-do doc by the end of the week
[20:06] <kirkland> pitti: dendrobates- doesn't want me working on ecryptfs for this cycle, though
[20:07] <kirkland> pitti: so what i have been doing on ecryptfs has mostly been above and beyond
[20:07] <kirkland> pitti: normal job responsibilities
[20:07] <kirkland> pitti: dendrobates- has sort of asked kees/jdstrand/mdeslaur (securtiy people) to do ecryptfs maintenance
[20:08] <kirkland> pitti: and for the desktop team to do the ui aspects
[20:08] <pitti> okay
[20:08] <pitti> just asking because you are currently set as the drafter for this spec
[20:08] <kirkland> pitti: right
[20:08] <kirkland> pitti: i'll draft the design doc by end of week
[20:08] <kirkland> pitti: and you can size it
[20:08] <kirkland> pitti: fair?
[20:09] <pitti> kirkland: do you think drafting the spec is something that this community person would do as well?
[20:09] <pitti> kirkland: absolutely
[20:09] <pitti> ah, Michael
[20:09] <kirkland> pitti: michael rooney, you mean?
[20:09] <pitti> right
[20:09] <kirkland> pitti: perhaps, though I don't mind doing it, especially if it needs to be done asap.
[20:11] <pitti> kirkland: if you could do the drafting (with the knowledge about what's possible to do), and I'll do some refinement (wrt. desktop integration), that would be great
[20:11] <kirkland> pitti: sounds fine, i can do that
[20:12]  * pitti hugs kirkland, thanks
[20:13]  * kirkland high fives pitti o/*\o
[20:23] <pitti> Riddell: I set some tentative priorities to the kubuntu specs; please feel free to fix (or yell at me to change it)
[20:26] <Adri2000> elmo: well, you were right, there is at least one leak where one could easily put its own html/javascript/whatever code on the page that would be intrepreted :p
[20:28] <Adri2000> elmo and Keybuk : I'm going to fix that (among other things) and push it to my bzr branch
[20:35] <pitti> good night everyone
[20:35] <jpds> gute nacht pitti.
[21:18] <slytherin> Can any of the archive admins please process sync bugs 314470 314487 314505?
[21:59] <aib> i am getting an assembler segfault during compile which suggests that the assembler uses a different version of libopcodes than which is being linked against.
[21:59] <aib> and the version of libopcodes on my system is suspciously new. /usr/lib/libopcodes-2.18.93.20081009.so
[22:00] <aib> http://gcc.gnu.org/ml/gcc-help/2009-01/msg00047.html
[22:00] <aib> can someone run a test for me to see if this is ubuntu?
[22:01] <aib> pecl install channel://pecl.php.net/svn-0.5.0   would do it
[22:13] <aib> i was kicked from #ubuntu for asking someone to help me troubleshoot this
[22:14] <aib> its potentially a serious issue - not appreciated
[22:14] <jpds> aib: Try asking in #ubuntu-ops.
[22:18] <ghostcube> hi guys can i may ask you if its planned to bring back the jackd audio output plugin to the xine-lib package
[22:20] <Riddell> ghostcube: unlikely, xine is in main, jack is in universe
[22:20] <ghostcube> hmm Riddell yeah but it i sneeded on kde4 to get jackd to the phonon backend sources to use it with the kde apps
[22:21] <ghostcube> is there any repackaged version you know of ? with jackd support in ppa ?
[22:23] <TheMuso> ghostcube: This is also an issue with other packages wanting to work with jack which exist in main. Until the source package of jack-audio-connectino-kit is in main, nothing in main can be built against it.
[22:24] <TheMuso> gah jack-audio-connection-kit
[22:24] <ghostcube> ui
[22:26] <ghostcube> ok :( bye guys
[22:27] <directhex> hm. what sort of times is dholbach about?
[22:27] <jnjackins> I have an extra box lying around that I'd like to install jaunty on. Alpha 2 or daily build?
[22:29] <Laney> kirkland: re: bug #243205, do you have any objections to me doing the new merge (0.9.0)?
[22:29] <TheMuso> jnjackins: Probably start with alpha 2 and then upgrade.
[22:29] <kirkland> Laney: you're welcome to do the merge, but i'd recommend using update-motd to publish that status
[22:29] <kirkland> Laney: it's better suited to publish mythtv-status
[22:30] <Laney> kirkland: I know nothing about that
[22:30] <LaserJock> directhex: dholbach is usually around business hours (little earlier) European time
[22:30] <kirkland> Laney: i've been meaning to talk to the upstream maintainer about it
[22:30] <kirkland> Laney: if you'd like to talk to upstream about that, bonus points!
[22:30] <Laney> do any other distros have update-motd?
[22:31] <kirkland> Laney: not that i know of
[22:31] <directhex> LaserJock, right, k. i've cornered meebey, and he's up for a developer week session
[22:36] <blizzkid> kirkland: you here?
[22:37] <kirkland> blizzkid: hi
[22:38] <blizzkid> kirkland: hi, sorry to bother you, but I read your challenge, and I tried it, but every time I try to decrypt the file, I get the message "bad key". Is that because of a wrong passphrase? Or am I missing something else?
[22:38] <kirkland> blizzkid: this isn't the proper place for this
[22:38] <blizzkid> can I msg you?
[22:38] <kirkland> blizzkid: sure
[23:00] <maxb> I posted https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-December/006560.html, but there's been no reply. Should I just be patient? Repost to ubuntu-devel@? Somewhere else?
[23:02] <james_w> maxb: the list of packages would have been useful
[23:02] <james_w> https://launchpad.net/~ubuntu-cruft-busters
[23:03] <james_w> you can subscribe that team to the bugs
[23:04] <cjwatson> maxb: if you can write a script which generates a report based on Sources and Packages files from a local archive mirror, I'd be happy to integrate that into the archive team's pool of such reports
[23:04] <cjwatson> then we would clean them up frequently
[23:06] <maxb> aha. Now I know what to do with bugs to flag them for the attention of the appropriate people, I shall start filing them
[23:07] <cjwatson> maxb: seriously I'd rather that we could get this into people.ubuntu.com/~ubuntu-archive and *not* file bugs
[23:08] <cjwatson> bugs are a more heavyweight way to process this kind of thing than a one-page report that we can just run down
[23:08] <cjwatson> they will take more ~ubuntu-archive effort and delay other things
[23:08] <cjwatson> a one-page report would be so much better, as this is a real problem I know
[23:09] <maxb> A fair proportion of the outdates are FTBFSes - those probably ought to be bugs, no?
[23:10] <cjwatson> oh, sure, if there's actually a source change to be made
[23:10] <maxb> Most of the rest are Packages-arch-specific related
[23:11] <cjwatson> but if the problem is that the packages need to be removed, I would prefer that those were not filed as bugs
[23:11]  * cjwatson -> bed
[23:22] <maxb> Is there anything special I should know about making a script suitable for people.ubuntu.com/~ubuntu-archive ? Or should I just leave it set up to download the data from a mirror, and leave it up to the archive admins to tweak it to run on people.ubuntu.com/~ubuntu-archive ?
[23:23] <TheMuso> crimsun: Yeah we could, would it not make things distorted etc for users who are not affected by  bug 275998