[00:05] <Turl> hi
[00:05] <Turl> will pidgin 2.6.1 get into karmic?
[00:06] <Turl> there's a bug for that, it doesn't seem to have any 'official' opinion on the subject https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/415908
[00:07] <Turl> 2.6.1 is in debian experimental, whereas ubuntu has 2.5.8
[05:19] <dave-ubuntu1> im looking for what mode of operation, algorithm, hashing algorithm, and keysize the ubuntu juanty alternate install cd supports
[05:20] <dave-ubuntu1> anyone home? :/
[05:24] <dave-ubuntu1> if you have an answer to my question please mail me at: davexthc@gmail.com or respond to https://answers.launchpad.net/ubuntu/+question/81467
[05:26] <dave-ubuntu1> thanks in advance
[05:47] <dave-ubuntu-1> i would like to add #ubuntu had no answer to my question afrer many hours
[05:48] <dave-ubuntu-1> also if if it inst implemented i suggest when creating an encrypted LVM at least have the option to dd urandom to the target disk
[06:41] <dholbach> good morning
[06:52] <pitti> Good morning
[06:53] <dholbach> hi pitti
[06:56] <pitti> ScottK: sorry, was sleeping; seems it built by now
[06:56] <highvoltage> morning dholbach and pitti
[06:57] <dholbach> hey highvoltage
[06:59] <StevenK> Morning pii
[06:59] <pitti> hey StK
[06:59]  * StevenK glares at his 't' key, which apparently works now
[06:59] <foxbuntu> hey all, looking for a little advice on where to look for something
[06:59]  * StevenK goes back to lurking, suitably embarrassed
[07:00] <foxbuntu> I am trying to preseed a default for a gconf key but seem to figure out how to make it global for all users (including newly created ones)
[07:09] <TheMuso> foxbuntu: You want dh_gconf and debian/gconf-defaults file
[07:10] <foxbuntu> TheMuso, thanks! I will look at those
[07:10] <TheMuso> foxbuntu: np
[07:52] <foxbuntu> TheMuso, mind giving me a little help with dh_gconf?
[07:55] <TheMuso> foxbuntu: Sure.
[07:56] <TheMuso> If you want a good example, have a look at the ubuntustudio-default-settings package, that uses it.
[07:56] <mattn> good morning - is there a way to install some gnome templates (xdg) via the package manager for every user?
[07:57] <foxbuntu> TheMuso, well the only question is, since the package already uses dh do I need to do anything other than add a debian/gconf-defaults file?
[07:57] <mattn> some standard way? or do i have to copy them manually to the home dirs?
[07:57] <dholbach> hola juanje!
[07:58] <juanje> hola dholbach! :-)
[07:59] <TheMuso> foxbuntu: Just make sure the binary package in question has ${misc:Depends} in the Depends field in debian/control.
[08:01] <TheMuso> foxbuntu: and if you have more than one binary package, make sure the file is debian/$package.gconf-defaults
[08:01] <TheMuso> where $package is the package name.
[08:02] <pitti> dholbach: I'm doing some sponsoring now, are you currently hammering at the queue and we need to coordinate? or can I just fire at will?
[08:02] <dholbach> pitti: just go ahead :)
[08:02]  * pitti hugs dholbach
[08:02]  * dholbach hugs pitti back
[08:02]  * dholbach needs to prepare his UDW session :)
[08:03] <dholbach> maybe I'll do some more sponsoring later on
[08:03] <foxbuntu> TheMuso, hmm, I have done both of those, and the conf still doesnt show up in place after the install, also in the dh log after build there is nothing for dh_gconf
[08:04] <TheMuso> foxbuntu: ok hang on a sec
[08:04] <TheMuso> foxbuntu: What packaging system are you using?
[08:04] <foxbuntu> TheMuso, np, thanks in advance for all the help
[08:05] <foxbuntu> TheMuso, cdbs
[08:05] <TheMuso> foxbuntu: Right you do need to explicitly call dh_gconf, at least thats what I had to do with ubuntustudio-default-settings.
[08:06] <foxbuntu> TheMuso, alright, so just add it to the debian/rules thenN?
[08:06] <TheMuso> foxbuntu: I suggest you download the source for ubuntustudio-default-settings and have a look at debian/rules
[08:06] <foxbuntu> TheMuso, will do
[08:07] <foxbuntu> TheMuso, ahhh...thats what I was missing... thanks!
[08:08] <TheMuso> np
[08:32] <pitti> slangasek: mmm, current live CDs are well within size limits again
[08:33] <pitti> slangasek: documentation gets stripped now, and gnome-games alone bought us 16 MB \o/
[08:34] <slangasek> pitti: w00t
[08:36] <pitti> can I seed frozen bubble now? :-)
[08:36] <StevenK> pitti: What was the gnome-games change?
[08:36] <pitti> StevenK: gnome help translations get stripped now, and stuffed into langpacks
[08:36] <StevenK> \o/
[08:37] <pitti> and I did a no-change upload of mousetweaks and gnome-games yesterday (against the new mangler)
[08:37] <pitti> I needed two packages for testing, and I wanted the CDs to not be oversized any more
[08:39] <StevenK> 0830 is oversized
[08:39] <pitti> but not 0831 (today)
[08:39] <pitti> that's what I meant
[08:40] <pitti> I did the stripping/langpack-o-matic changes yesterday
[08:40] <slangasek> pitti: no, but you can make a new derivative called frozenbubbluntu
[08:40]  * pitti sobs
[08:40] <pitti> blubbuntu!
[09:37] <sebner> pitti: yeah, back in action at least. Is there anything else I could do (debug?) or do we have to wait for other traces, that tell you more or do we have to wait for upstream?
[09:38] <pitti> sebner: at this point I'm waiting for Lennart's (upstream's) response
[09:38] <sebner> kk :)
[09:38] <pitti> I don't know about the black magic that libatasmart does, I'm afraid
[09:39] <sebner> pitti: heh, not that bad (since it works with the workaround) but release is nearing and should be fixed anyways before it
[09:45] <pengo1> I cannot believe this bug persists. https://bugs.launchpad.net/bugs/150872
[09:50] <pengo> (according to reports in the bug report anyway)
[09:50] <pengo> makes me sad
[10:13] <matteo> ciao
[10:13] <matteo> there is a package in ubuntu I use
[10:13] <matteo> that's libdmtx
[10:13] <matteo> it's version 0.6.0 while upstream is 0.7.0
[10:14] <matteo> debian sid already has 0.7.0 so i'm using the sd package
[10:14] <matteo> the maintainer is the MOTU
[10:15] <matteo> i have filed a bug report
[10:15] <matteo> tme ago
[10:15] <matteo> there is a way to join the team and do the upload myself?
[10:15] <matteo> I have some PPA and i know good debian packaging system
[10:17] <matteo> https://bugs.launchpad.net/ubuntu/+bug/396131
[10:17] <lifeless> there is, but its not overnight, got to let people get to know you
[10:18] <lifeless> what you can do, right now, is follow the 'sync' process documented in ubuntu-policy and on the ubuntu wiki, and that will get it updated
[10:18] <matteo> what sync? from debian?
[10:18] <lifeless> we're in feature freeze, so it may need a FFe approval
[10:18] <lifeless> yes
[10:18] <matteo> oh :(
[10:18] <torkel> matteo: you probably want to join #ubuntu-motu
[10:18] <matteo> i have ugly #ifdef in my code
[10:18] <matteo> to support both debian and ubuntu
[10:36] <pitti> meh, usb-creator seems completely broken right now :/
[10:37] <hyperair> what's wrong with it?
[10:38] <pitti> NotImplementedError: add_image is not implemented by the backend.
[10:38] <pitti> I can't add an .iso
[10:38] <hyperair> ouch
[10:38]  * hyperair takes note not to wipe thumbdrive until usb-creator's fixed.
[10:38]  * pitti installs jaunty version
[10:39] <pitti> "Unable to determine the partition number" -- WTH?
[10:39] <pitti> seems I won't create an usb install stick today :/
[10:39] <davmor2> pitti: fortunately for me I keep one main box on a stable version for just that occasion :)
[10:43] <ogra> pitti, broken for .img as well btw
[10:43] <ogra> i know evand has a fix pending for that
[10:44] <ogra> (we talked on friday)
[10:47] <ogra> pitti, https://launchpad.net/bugs/420438
[10:48] <pitti> ogra: right, sounds like it; I added a vfat partition now, and it works with the jaunty version now
[10:48] <ogra> right
[10:48] <ogra> i rolled back to jaunty as well, but it doesnt get me anywhere since jaunty had no .img support at all
[10:50] <davmor2> ogra: can't you just add image-writer for that ?
[10:51] <ogra> davmor2, well, imagewriter is supposed to be replaced by usb-creator
[10:51] <ogra> indeed imagewriter works, its a dumb dd frontend, had to break :)
[10:51] <ogra> *hard
[10:52] <davmor2> ogra: yeah but as a temporary measure I meant
[10:52] <ogra> sure, but then i can just dd anyway :)
[13:59] <AnAnt> Hello, tzdata on jaunty needs to be updated
[14:29] <cody-somerville> pitti, When I open jockey-gtk and try to activate a restricted driver in Xubuntu it says "You are not authorized to perform this action.". Why would it start doing that?
[14:30] <pitti> cody-somerville: hm, seems you don't have policykit-1-gnome?
[14:30] <pitti> it needs that to ask you for your password for authorization
[14:31] <pitti> cody-somerville: hm, no, it's a dependency of jockey-gtk
[14:31] <pitti> I guess you have it installed, but it's not running
[14:31] <pitti> cody-somerville: can you confirm that pidof polkit-gnome-authentication-agent-1 is empty?
[14:32] <sgallagh> Question: Can someone point me at a page listing the standard configure paths expected for an Ubuntu build? (e.g. ./configure --prefix=/ --sysconfdir=/var/lib etc.)
[14:32] <pitti> cody-somerville: and if so, can you please change /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop to say "OnlyShowIn=GNOME;Xfce;"? does it start automatically then?
[14:37] <cody-somerville> pitti, pidof is indeed empty
[14:37] <cody-somerville> pitti, I need to reboot anyhow so I'll see if that change autostarts it
[14:37] <cody-somerville> pitti, brb
[14:42] <cody-somerville> pitti, Adding XFCE worked like a charm! :)
[14:42] <pitti> 04-add-xfce.patch.disabled
[14:42] <pitti> o_O
[14:43] <pitti> cody-somerville: okay, will fix; thanks
[14:43] <davmor2> cody-somerville: I bugged that a week or so ago :)
[14:43] <cody-somerville> davmor2, bug #?
[14:43] <pitti> davmor2: oh, do you have a bug #?
[14:44] <davmor2> pitti, cody-somerville: bug 417462
[14:44] <pitti> davmor2: thanks
[14:58] <mdke> kees: not sure if you've seen http://ardchoille42.blogspot.com/2009/08/canonical-advocates-insecure-practices.html
[15:08] <Yoe> where are these debug packages?
[15:08] <mdke> kees: seems to have comments disabled :(
[15:09] <directhex> mdke, people who post blog posts which require response, but don't have comments enabled, require punishment. possibly with a 2-by-4
[15:12] <cody-somerville> mdke, Whats your position on the issue?
[15:14] <mdke> directhex: yes, I guess it's intentional
[15:14] <mdke> cody-somerville: I'm not a security expert (and kees is) but from what I can see, there is nothing on the wiki page or the blog post that explains why enabling the root account is more dangerous than using sudo
[15:15] <ScottK> It's not in many circumstances.
[15:16] <ScottK> The one security advantage to sudo is enhanced logging of who did what.
[15:17] <mdke> ok
[15:17] <mdke> I guess if you have both, it gives a malicious users two possible passwords to guess/force, rather than one
[15:17] <mdke> but that's not really something that makes enabling the root account inherently dangerous, afaics
[15:18] <ScottK> That's a security advantage, not risk.
[15:18] <mdke> anyway, the wiki page should reflect our policy, and as far as I'm aware kees is in about the best position to determine what that policy is, if it requires further discussion it should be escalated in the usual way
[15:18] <ScottK> At least on a server as long as you disable root login via ssh
[15:19] <cody-somerville> mdke, Its also probably needed, as kees said in his e-mail, for some users who have legacy tools/scripts/infrastructure requiring an actual root account and don't take advantage of sudo.
[15:19] <ScottK> mdke: It's a wiki.  If people want to give information on alternative ways to do stuff, it is expected.
[15:19]  * mdke nods
[15:19] <mdke> wiki edit wars are no substitute for proper discussion on a mailing list
[15:19] <ScottK> We don't want 'wiki police' running around and deleting stuff that's "not doing it right"
[15:20] <mdke> especially not wiki vigilantes :)
[15:21] <virtuald> sudo can be configured to ask for the root password. anyway the no root password thing makes me feel i should have a more secure password for my account?
[15:22] <ScottK> mdke: Also we have a cultural norm of not reverting reversions to avoid  wiki wars.  The guy that made the blog post is IMO wrong on that account.
[15:25] <mdke> ScottK: well, his post got reverted
[15:25] <mdke> his edit, i mean
[15:26] <mdke> ScottK: oh, I see what you mean now
[15:27] <cody-somerville> "I have served as an op in official Ubuntu IRC channels where telling others how to enable root can get you kicked out of the channel." <-- Wow.
[15:28] <jcastro> let me guess, RootSudo?
[15:30] <ScottK> Yep
[15:53] <mdke> pitti: I saw that you uploaded the new pkgbinarymangler yesterday so I will do a new ubuntu-docs upload soon with all the translations and we will see how it works :)
[15:54]  * ogra looks for his hard hat for tomorrow :)
[15:54] <mdke> heh
[15:55] <ogra> mdke, btw i like to tell people that sudo vs root account is mainly a usability thing (despite the logging ScottK mentioned there is not much added security)
[15:55] <ScottK> And the logging thing is totally irrelevant for single user systems.
[15:56] <ogra> yeah
[15:56] <ScottK> It's more of a tool for the autopsy than a security feature anyway.
[15:56]  * mdke nods
[16:05] <lamont> it used to be (apparently) that DEBIAN_FRONTEND was set when running postinst...  did that go away recently?
[16:10] <jdstrand> actually, there are a few benefits of sudo: a) logging (as mentioned), b) no password for a well known account (ie root). this is especially good when combined with our sshd_config of allowing root logins and keeps people from brute-forcing root and c) it encourages the good behavior of not logging in as root
[16:11] <ScottK> jdstrand: I think it's a given if you enable root you have to disable ssh login as root.
[16:11] <jdstrand> in and of itself is there a tremendous security advantage? no. added together I think it adds security to the system overall
[16:12] <jdstrand> ScottK: it is logically a given, but it is not a given with the current system
[16:12] <ScottK> True, but I file that under "don't change this unless you know what you are doing".
[16:12] <jdstrand> and it is only logically a given if you know what you are doing
[16:12] <jdstrand> ScottK: I agree
[16:14] <thebishop> hi, I'm working with a handheld device that uses MTP for file transfer.  The trouble is the most recent version of mtpfs only works in Hardy, I can't get it working in Jaunty
[16:15] <tkamppeter> pitti, hi
[16:15] <pitti> hi tkamppeter
[16:15] <thebishop> can anyone tell me what changed in how Jaunty handles MTP devices compared to Hardy?
[16:16] <pitti> tkamppeter: I had a question for you in bug 420015
[16:16] <pitti> tkamppeter: is it actually easily possible to tell which devices are USB printers? (for creating an udev rule); otherwise I'd just have the backend run as root
[16:18] <pitti> tkamppeter: I'll use the "root backend" approach for now; I can revert it if/when we get udev rules
[16:19] <superm1> tkamppeter, can you email that patch again attached with that change since holtmann doesn't want to take the Changelog entry out himself again
[16:21] <tkamppeter> pitti, yes. See the udev rules of system-config-printer-udev (/lib/udev/rules.d/70-printers.rules) for udev rules only starting a script when a printer is (dis-)connected.
[16:22] <pitti> ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", GROUP="lp", MODE="660"
[16:22] <pitti> tkamppeter: ^ could you please give this a quick test? I can't access an USB printer under karmic right now
[16:23] <tkamppeter> pitti: See http://pastebin.ubuntu.com/262581/ for udev rules which determine and use bus and device number of the connected USB device.
[16:24] <pitti> tkamppeter: but that's a per-vendor/product list again, and always behind and outdated by nature
[16:24] <pitti> that's not covered by ATTR{bInterfaceClass}=="07"?
[16:26] <pitti> tkamppeter: a rule like the above is reasonable to commit to udev, but http://pastebin.ubuntu.com/262581/ absolutely isn't
[16:26] <pitti> that should be shipped by hplip then
[16:26] <pitti> but that has its own backend anyway, doesn't it?
[16:28] <tkamppeter> pitti, the pastebin stuff is not to demonstrate how to determine what is a printer, but how to extraxt bus and device number so that one can manipulate /dev/bus/usb/*/* files (to find the right one).
[16:29] <tkamppeter> pitti, I thought about (but can be overkill):
[16:33] <tkamppeter> ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev}; B=$${X%%%%.*}; D=$${X#*.}; file=`printf /deb/bus/usb/%%03i/%%03i $$B $$D`; chgrp lp $$file; chmod 660 $$file'"
[16:35] <pitti> tkamppeter: why not simply GROUP="lp", MODE="660" ?
[16:35] <pitti> that's what they are meant for
[16:35] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 25 minutes in #ubuntu-classroom
[16:40] <tkamppeter> pitti, is /dev/bus/usb/*/* automatically the file where GROUP="lp", MODE="660" acts on?
[16:40] <pitti> tkamppeter: yes
[16:40] <tkamppeter> if I do ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", GROUP="lp", MODE="660"
[16:41] <pitti> tkamppeter: I put a proposed rule into the bug report (same as I pasted above) for testing
[16:42] <tkamppeter> and connect the DesignJet 130 (a printer not covered by HPLIP) the permissions and ownerships do not get changed, but
[16:42] <tkamppeter> ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", RUN+="udev-configure-printer add %p"
[16:42] <tkamppeter> starts udev-configure-printer.
[16:43] <pitti> tkamppeter: where did you add the rule?
[16:43] <pitti> # libusb device nodes
[16:43] <pitti> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0664"
[16:43] <pitti> ^ from 50-udev-default.rules
[16:43] <pitti> so it needs to run later than 50-*
[16:44] <tkamppeter> In /lib/udev/rules.d/70-printers.rules, right before the rule to start udev-configure-printer (did not want to create a new file for the test and wanted to have it done before udev-configure-printer).
[16:45] <pitti> tkamppeter: added updated rule to bug report
[16:48] <tkamppeter> pitti, should it not be /etc/udev/rules.d/69-cups.rules as there is already /lib/udev/rules.d/70-printers.rules
[16:49] <pitti> doesn't matter much
[16:49] <pitti> tkamppeter: uploading new cups to experimental and karmic now, so that this gets fixed
[16:50] <tkamppeter> pitti, but why does my rule not work if it is in /lib/udev/rules.d/70-printers.rules, right before the rule for udev-configure-printer?
[16:50] <pitti> I don't know
[16:52] <tkamppeter> pitti, before you upload new CUPS packages, one point:
[16:52] <pitti> (too late..)
[16:53] <pitti> tkamppeter: would be interesting to see an udevadm test output for the printer, to see whether the rule matches at all
[16:54] <tkamppeter> pitti: The usblp kernel module should not be completely thrown out of the distro. It should only get deactivated for systems actually running CUPS.
[16:54] <pitti> tkamppeter: right, that happens now, the blacklist file is shipped by cups
[16:55] <tkamppeter> pitti, so my suggestion is to add a file /etc/modprobe.d/blacklist.conf file
[16:55] <tkamppeter> So you did it already? Great.
[16:55] <pitti> tkamppeter: I added blacklist-cups.conf
[16:55] <pitti> then the apparmor profile update, and usb backend as root (for now)
[16:55] <tkamppeter> Yes, I meant blacklist-cups.conf.
[16:56] <tkamppeter> pitti, how did it work with the udevadm test?
[16:57] <pitti> tkamppeter: you need the sysfs path of the printer device (udevadm monitor --udev -e, then plug it in), and then udevadm test devices/..., the output shoudl show the matching rules
[17:00] <tkamppeter> pitti did you not put the udev rule into the CUPS package?
[17:01] <pitti> tkamppeter: no, I didn't; it doesn't belong there, and you said it doesn't work
[17:01] <pitti> tkamppeter: I install the backend to run as root for now
[17:08] <tkamppeter> pitti, here is the udevadm result: http://pastebin.ubuntu.com/262600/
[17:18] <kevdog> any plans for ubuntu to add the lzma file compression/decompression utilities lzma, lzip, or xz to its repositories.  I read that Slackware is now distributing files from its repository in .txz format
[17:20] <maxb> !info lzma hardy
[17:20] <maxb> kevdog: Look before you assume something is not there!
[17:21] <kees> mdke: yeah, saw the blog post.  I like how he didn't include further emails with him.  anyway, as discussed, I don't think having a root account makes a system less secure.  there is one good point about knowing the "root" account exists, but that's pretty minor if it has a good password.
[17:21] <neilwilson> mterry: Are you around?
[17:21] <kevdog> maxb: I looked in my repository and did see anything regarding xz.  lzma is a part of 7zip, but I was wanting the standalone program if possible
[17:22] <kees> mdke: I'm not hugely interested in "fighting" for having it in the wiki or not; my angle was simply "this smells like censorship".  It's documented in "man sudo_root", so I can always point there.
[17:22] <ScottK> kevdog: xv is in xv-utils
[17:22] <ion> xz-utils: /usr/bin/xz
[17:22] <ScottK> v/z
[17:23] <maxb> kevdog: What I just pointed out *is* a standalone program. Please head over to #ubuntu or #ubuntu+1 as appropriate for assistance installing/using stuff already in the repositories
[17:23] <ScottK> maxb: It's worthin noting it's onlyl in Karmic though, not in a release.
[17:24] <maxb> ScottK: but.... <maxb> !info lzma hardy  <ubottu> lzma (source: lzma): .... Version 4.43-12ubuntu1 (hardy) .... !?
[17:24] <ScottK> maxb: I was talking about xz.
[17:24] <kevdog> maxb: #ubuntu pointed me here.  Im using intrepid.  As far as using an apt-cache search xz -- nothing comes up with relevant results.  There is no /usr/bin/xz in my install -- possibly my fault
[17:25] <ScottK> kevdog: No xz in Intrepid, just Karmic.
[17:25] <maxb> OK, well, you also asked about lzma, which is there.
[17:25] <kevdog> ScottK: Thanks -- you've answered my question -- what about lzip?
[17:25] <maxb> karmic only, too
[17:25] <kevdog> maxb: cool -- Thanks guys
[17:26] <maxb> Is there anyone around who feels like sponsoring an upload of Subversion? LP 406245
[17:27] <ScottK> Got FFe?
[17:27] <maxb> FFe is granted
[17:29] <tkamppeter> pitti, still there?
[17:36] <ScottK> maxb: Looking into it.
[17:36] <maxb> yay, thanks
[17:41] <mterry> neilwilson, will be around in 20m
[17:47] <kees> pitti: is my reply to bug 413278 sufficient for an SRU?  Sorry I hadn't been clear enough.
[18:03] <mathiaz> cjwatson: hi - I've gone through an cloud installation from the -server iso
[18:04] <mathiaz> cjwatson: and it seems that the eucalyptus-cc package is not installed during the Cluster installation.
[18:05] <mathiaz> marjomercado: hi - I've written some test cases for UEC
[18:05] <mathiaz> marjomercado: http://testcases.qa.ubuntu.com/Install/UECInstall
[18:06] <mathiaz> marjomercado: could you add these to the ISO testing tracker?
[18:06] <pitti> kees: ah, thanks
[18:24] <slangasek> mathiaz: probably not, but I can :)
[18:25] <t0bi> wheren't there supposed to be talks regarding the ubuntu developer week in this channel?
[18:27] <mathiaz> slangasek: ok.
[18:28] <slangasek> t0bi: talks are held in #ubuntu-classroom
[18:28] <t0bi> ah, thx!
[18:37] <tkamppeter> pitti, still there?
[18:46] <mathiaz> slangasek: are you taking care of updating the iso tracker with the new test cases?
[18:46] <slangasek> mathiaz: yes
[18:46] <mathiaz> slangasek: great - here is another set of testcases:
[18:46] <mathiaz> slangasek: http://testcases.qa.ubuntu.com/System/CloudImages
[18:46] <TheSteve0> I am running Karmic and I would love to give feedback - what is the best IRC channel to do that in
[18:47] <sgallagh> Question: Can someone point me at a page listing the standard configure paths expected for an Ubuntu build? (e.g. ./configure --prefix=/ --sysconfdir=/var/lib etc.)
[18:48] <TheSteve0> I should say I am running Karmic from 8/29 and applying multiple daily updates
[18:51] <ScottK> TheSteve0: You should file bugs at launchpad.net.  You can send email to ubuntu-devel-discuss@lists.ubuntu.com.  IRC is possibly #ubunt+1.
[18:55] <TheSteve0> scottK I don't know what you mean by that IRC channel
[18:55] <ScottK> maxb: svn test build takes a long time on my laptop.....
[18:56] <ScottK> TheSteve0: I had a typo.  #ubuntu+1 is the irc channel for discussion of issues and problems with the developmet release of Ubuntu.
[18:57] <TheSteve0> scottK excellent - thanks
[19:18] <slangasek> mathiaz: are those test cases specific to EC2?  Are there additional test cases for UEC pending (per Matt's mail)?
[19:28] <ncb000gt> Is there any reason that files listed with dpkg-deb --contents <package> would not be installed properly when using sudo dpkg -i <package>?
[19:29]  * ccheney may finally be moving, looking at house today that is 375 m^2 with additional 200 m^2 attic walk out storage
[19:31] <ScottK> maxb: Subversion uploaded.  Thank you for your contribution to Ubuntu.
[19:35] <slangasek> ncb000gt: because another package that you have installed Replaces: that package
[19:36] <ncb000gt> slangasek: Perfect! Thank you kindly!
[20:13] <jdstrand> seb128: hi! I've got a fix for bug #422130 and bug #417736 I plan to upload today. will this conflict with anything you are doing?
[20:13] <jdstrand> bug #422130
[20:13]  * jdstrand just made it public...
[20:13] <jdstrand> bug #422130
[20:13] <jdstrand> meh
[20:14] <jdstrand> seb128: bug #422130 is a bug in hamster fixed by this commit: http://git.gnome.org/cgit/hamster-applet/patch/?id=e9b7738328637ccc5aa49f63296c77c04927b7db
[20:14] <jdstrand> thanks ubottu
[20:16] <seb128> jdstrand, hello, no change are planned on evince so upload whatever you need to change
[20:16] <jdstrand> seb128: what about hamster?
[20:16] <seb128> jdstrand, you can also upload the hamster change
[20:17] <jdstrand> seb128: thanks! :)
[20:17] <seb128> thank to you for working on those!
[20:17] <jdstrand> seb128: I'm kinda surprised how dependent I've become on hamster :)
[20:17] <seb128> ;-)
[20:20] <sgallagh> mathiaz: ping
[21:01] <mathiaz> slangasek: thanks for updating the tracker
[21:01] <slangasek> mathiaz: did you see my question about whether there were separate UEC test cases pending?
[21:01] <slangasek> (vs. EC2)
[21:03] <mathiaz> slangasek: hm - the test cases are the same, but both EC2 and UEC images should be tested
[21:03] <mathiaz> slangasek: as they're different
[21:04] <mathiaz> slangasek: both UEC and EC2 images should go through http://testcases.qa.ubuntu.com/System/CloudImages
[21:04] <slangasek> are they?  I thought the image was supposed to be identical, distributed via 2 different channels
[21:04] <slangasek> how do you test "availability zones" for UEC?
[21:04] <mathiaz> slangasek: different clusters
[21:05] <slangasek> and  should UEC point at the ec2 archive mirrors?
[21:05] <mathiaz> slangasek: IIUC availability zones are different clusters in UEC
[21:05] <slangasek> ok
[21:05] <mathiaz> slangasek: hm right. This has to be updated.
[21:05] <mathiaz> slangasek: I'll update the testcases then.
[21:05] <slangasek> ok, cheers
[21:07] <mathiaz> slangasek: test case wiki page updated.
[21:07] <slangasek> ok
[21:07] <mathiaz> slangasek: I've added a new test case - UEC Image
[21:12] <mathiaz> slangasek: the other issue we run into this morning while testing the cloud installation on the server iso was that the eucalyptus-* packages weren't installed
[21:12] <mathiaz> slangasek: the packages are on the isos and the eucalyptus udeb is trying to install tham
[21:12] <mathiaz> slangasek: *them*
[21:21] <mdke> kees: if its a valid use case and doesn't have negative security implications, I think it *should* be in the wiki. anyway, it is there now and the guy seems to have stopped editing it, I believe. Did you resolve anything in later emails?
[21:27] <kees> mdke: I had replied to him with my justifications (before he posted to his blog -- and he didn't seem to publish *that* email...) so I figure I'm done with it for now.
[21:29] <mdke> kees: fair enough, thanks for making the effort
[21:51] <slangasek> mathiaz: I currently don't have an ISO test setup here; do you have enough information to file a bug against the installer about this?
[21:54] <mathiaz> slangasek: well - there isn't anything in the log
[21:57] <jtimberman> anyone here use sbuild?
[22:04]  * jtimberman sorted, nm!
[22:18] <YokoZar> Apparently there's something about launchpad's build daemons that I don't know.  I have a rules file that's little more than a copy command and it's building on i386 but failing on amd64 and I have no idea why. http://launchpadlibrarian.net/31090181/buildlog_ubuntu-karmic-amd64.wine1.2-gecko_1.0.0-0ubuntu2_FAILEDTOBUILD.txt.gz
[22:18] <YokoZar> It works when I build locally with dpkg-buildpackage -rfakeroot too
[22:18] <cjwatson> mdke: I'll get round to fixing it in karmic this week; I don't really think it merits an SRU, to be honest
[22:21] <soren> cjwatson: Can you ping me when you're done with Eucalyptus for today?
[22:22] <soren> cjwatson: I have a few more things I'd like to get done and then I'll upload at some point.
[22:23] <soren> cjwatson: I'm sprinting in St. Louis, so it's still early for me. I'll make sure to get it done so that whatever we do will be on tomorrow's dailies.
[22:23] <soren> slangasek: We would really appreciate some attention to bug 420035
[22:24] <soren> slangasek: There's a bunch of other interesting bug fixes in upstream's bzr, and we'd like not have to filter out these new features.
[22:26] <cjwatson> mathiaz: yep - fixed in bzr now
[22:26] <cjwatson> mathiaz: or should be, anyway
[22:26] <mathiaz> cjwatson: great - thanks
[22:27] <cjwatson> soren: I'm done for the moment, please do upload
[22:27] <soren> cjwatson: Would you prefer I do it now, or is it cool if I wait a few hours?
[22:27] <cjwatson> don't care
[22:28] <cjwatson> this was essentially running through today's installer and fixing all the issues I could see
[22:28] <cjwatson> which unfortunately wasn't many because the fact that eucalyptus-cloud doesn't get installed rather screws up the world
[22:28] <soren> cjwatson: Yes, we noticed. We were just about to work on that when I saw your commits, so thanks :)
[22:30] <cjwatson> soren: if you guys have time, it would be worth doing a test run of today's installer in the ordinary server mode, selecting eucalyptus-simple-cluster in tasksel
[22:30] <soren> mathiaz: ^^
[22:30] <cjwatson> soren: I'm a bit worried by the fact that I haven't yet been able to test a from-scratch installation of the cloud/cluster controllers in karmic
[22:30] <mathiaz> cjwatson: we're current testing all of this.
[22:31] <mathiaz> cjwatson: is there anyway to test your changes before waiting for a new round of dailies?
[22:31] <soren> cjwatson: We sould be significantly closer to that by tomorrow.
[22:31] <cjwatson> YokoZar: your package is architecture-specific but you're doing work in binary-indep, rather than in binary-arch where you should be doing it
[22:31] <cjwatson> mathiaz: "the ordinary server mode, selecting eucalyptus-simple-cluster in tasksel"
[22:31] <cjwatson> mathiaz: will not actually test my changes directly but will test the stuff that's significantly less well-tested and thus significantly scarier
[22:32] <mathiaz> cjwatson: ok.
[22:32] <cjwatson> YokoZar: you can reproduce this locally with debuild -B
[22:33] <cjwatson> mathiaz: the main thing this won't test, of course, is the installer integration that deals with creating a node preseed file
[22:34] <YokoZar> cjwatson: ahh I guess that happened when I migrated it from all to 3 arches.  Thanks that clears it.
[22:35] <cjwatson> mathiaz: what you could do is as follows: boot the UEC installer in expert mode (i.e. select UEC at boot menu and use F6 to switch on expert mode), run through the installer until immediately after "retrieving installer components" or whatever it's called, switch to tty2, nano /var/lib/dpkg/info/eucalyptus-udeb.postinst, apply my changes, save and exit, switch to tty1, select "change debconf priority", select "high", continue
[22:35] <cjwatson> mathiaz: actually, I might try that myself now
[22:39] <jdstrand> kirkland: fyi, bug #359338 should no longer be a blocker for you
[22:39] <kirkland> jdstrand: \o/
[22:40]  * kirkland high fives jdstrand 
[22:40] <jdstrand> kirkland: I assume you'll let evand know when he is around?
[22:40] <jdstrand>  5
[22:40] <jdstrand> o/
[22:40] <kirkland> jdstrand: let evan know what, exactly?
[22:41] <jdstrand> kirkland: that it is not a blocker. I thought that was the last thing for the installer. However, I forgot it was in email, so I'll respond there
[22:41] <cjwatson> soren: seems like it'd be safer to || true that dpkg-statoverride --remove call?
[22:42] <cjwatson> soren: and using dpkg-statoverride for this is fundamentally broken, in case you didn't already know :)
[22:42] <cjwatson> dpkg-statoverride is a *user* override
[22:43] <cjwatson> soren: packages are supposed to create any users/groups they need to own their files in their preinst, and then just ship the files owned by the correct user/group in the filesystem tarball in the .deb
[22:43] <kirkland> jdstrand: great, thanks ;-)
[22:44] <cjwatson> soren: certainly, without the || true, that's going to fail on initial installation - the if ! getent block will create a statoverride for euca_rootwrap in /usr/lib not in /usr/share, and then dpkg-statoverride --remove will fail because the override doesn't exist
[22:44] <soren> cjwatson: Even for setuid files?
[22:44] <cjwatson> yep
[22:44] <soren> cjwatson: Ok.
[22:45] <soren> cjwatson: I got my inspiration from some other package that shipped a setuid binary..
[22:45] <soren> cjwatson: How does that work on the initial isntall, though?
[22:45] <soren> cjwatson: when its first installed, it the user eucalyptus user doesn't exist, so what would happen then?
[22:45] <cjwatson> some packages inherit a crazy view of the world from the really old way things used to work
[22:45] <cjwatson> you create the eucalyptus user in the preinst if it doesn't exist
[22:46] <soren> Then I need a Pre-Depends on adduser, don't I?
[22:46] <cjwatson> yes
[22:46] <cjwatson> this is better than the alternative
[22:47] <soren> Fascinating :)
[22:47] <cjwatson> if you create the user in the preinst, then it's available when dpkg-deb unpacks the tarball
[22:47] <cjwatson> http://lists.debian.org/debian-devel-announce/2001/01/msg00004.html
[22:48] <soren> Sure. I just thought Pre-Depends was something we tried really, really hard to avoid.
[22:48] <cjwatson> also http://lists.debian.org/debian-mentors/2001/02/msg00174.html may help
[22:49] <cjwatson> Pre-Depends is often to be avoided, but this is one of its standard uses
[22:49] <cjwatson> it shouldn't be avoided at the cost of poor behaviour elsewhere
[22:49] <soren> cjwatson: Doesn't the first link say that I /should/ use dpkg-statoverride?
[22:49] <soren> Oh, /me just read the second link..
[22:49] <cjwatson> not in your maintainer scripts
[22:50] <jono> hey all
[22:51] <jono> can I run Devicekit on Karmic alongside HAL?
[22:51] <cjwatson> there is some justification for using dpkg-statoverride in maintainer scripts on occasion, to migrate overrides around when files change name
[22:51] <cjwatson> the reason I went to look at your change was that I wrote code to do this very recently in man-db and I wanted to compare yours with mine :-)
[22:52] <mathiaz> kees: what's your take on bug 194140?
[22:52] <cjwatson> it's probably too much effort unless it's likely that lots of sysadmins will have used statoverrides, which they probably won't have dared to do when the package is scribbling over them itself
[22:52] <tkamppeter> rickspencer3: hi
[22:52] <davmor2> jono: why would you need too?
[22:53] <jono> davmor2, to write some software that uses DeviceKit
[22:53] <kees> mathiaz: i have not been able to reproduce it
[22:54] <davmor2> jono: I thought devicekit was mostly implemented in karmic
[22:54] <slangasek> jono: if you're running karmic, you already have devicekit (or as much of it as is implemented)
[22:55] <sivang> hi all
[22:55] <sivang> does anyboidy know where I can find daffyd harris ?
[22:56] <davmor2> with a name like that I'm going to guess at Wales
[22:56] <sivang> well, I want to talk to him on IRC
[22:56] <jono> slangasek, in the default install?
[22:56] <sivang> I'mm find his email
[22:56] <slangasek> jono: yes
[22:56] <soren> cjwatson: Hm... So adduser in preinst (so with a Pre-Depends: on adduser) is the preferred way to do something like this or is there a third way that doesn't suck at all?
[22:56] <rickspencer3> hi tkamppeter
[22:56] <davmor2> jono: yes
[22:56] <cjwatson> mdke: ah, I see Brian already fixed the guide in karmic
[22:57] <jono> slangasek, ahhh great :)
[22:57] <seb128> jono, that's what gvfs uses by default in karmic
[22:58] <jono> seb128, ahhh great :)
[22:58] <jono> thanks for info, chaps
[22:58] <cjwatson> soren: adduser in preinst is preferred for this, to the best of my knowledge
[22:58] <cjwatson> specifically in the case where the package needs to ship a file owned by a particular user
[22:59] <cjwatson> soren: this really doesn't suck at all in practice; eucalyptus-common is extremely unlikely to be unpacked in an environment where adduser is not already configured
[22:59] <cjwatson> I mean, even without the pre-depends
[23:00] <cjwatson> pre-depends get sucky when they're used in less widely separated parts of the stack
[23:01] <cjwatson> sivang: I don't believe he's involved with Ubuntu any more; try other contact methods
[23:04] <soren> cjwatson: Do you have any idea why mlocate is using dpkg-statoverride?
[23:06] <soren> cjwatson: I'll fix up Eucalyptus to not use dpkg-statoverride. Thanks for clarifying this.
[23:09] <cjwatson> soren: no, but at least it uses a --list check to ensure that it doesn't conflict with existing sysadmin overrides, so its implementation isn't buggy, merely (IMO) awkward
[23:09] <soren> *cough* Yeah, that is a good idea :)
[23:12] <mathiaz> slangasek: some of the opendrim-lmp-* packages are in State: Failed to upload - how should this be fixed?
[23:13] <slangasek> mathiaz: hrm, were the source packages buildable while still in universe?
[23:13] <mathiaz> slangasek: nope - one of the build-dependency (sfcb) was in multiverse
[23:13] <slangasek> hum
[23:14] <slangasek> which ones are failed-to-upload?
[23:15] <mathiaz> slangasek: opendrim-lmp-baseserver, opendrim-lmp-ip, opendrim-lmp-ethernetport
[23:23] <soren> cjwatson: Could you take a peek at a diff for this for me
[23:23] <soren> ?
[23:24] <cjwatson> soren: sure
[23:24] <soren> cjwatson: http://pastebin.com/f69e08d22
[23:25] <soren> cjwatson: I'm not sure if I'm being overly defensive.
[23:26] <soren> cjwatson: Disclaimer: I've not tested it yet.
[23:28] <cjwatson> soren: hmm, one awkwardness with this scheme is that you do have to ensure that euca_rootwrap is group eucalyptus in the tarball yet - that may be tricky
[23:28] <cjwatson> s/yet //
[23:28] <soren> cjwatson: *chuckle*
[23:28] <soren> cjwatson: Err.. Yeah.
[23:28] <cjwatson> soren: this code looks fine, but maybe I led you up the garden path, sorry, I can't think how to safely make it the right group in the tarball :-(
[23:29] <soren> cjwatson: Heh :)
[23:29] <cjwatson> in that case the fallback would be to use a --list check as in mlocate
[23:29] <cjwatson> damn and blast, etc.
[23:29] <slangasek> .oO ('fakeroot adduser ...')
[23:29] <cjwatson> that really is foul, there should be a better way
[23:29] <soren> cjwatson: No worries. It was an interesting thought experiment.
[23:30] <cjwatson> you want something like fakeroot_allow_user/group
[23:30] <cjwatson> which talks to the faked
[23:32] <soren> I'm not sure I like the idea of putting gain-root-command specific stuff in the rules file :)
[23:33] <soren> In fact, I'm quite sure I don't like that idea. :)
[23:35] <cjwatson> oh, also, 04750 is stated by policy as being wrong for setuid executables - should be 04754
[23:36] <cjwatson> on the basis that there's no point in making an executable non-world-readable when anyone can go to the archive and find out what it contains
[23:36] <soren> Heh :) good point.
[23:37] <cjwatson> "Cannot find Eucalyptus bootstrapper: com/eucalyptus/bootstrap/SystemBootstrapper"
[23:38] <soren> cjwatson: :(
[23:40] <soren> cjwatson: I'll poke Dan in a second about it.
[23:41] <cjwatson> eucalyptus-msgs-1.6-devel.jar has that class
[23:42] <cjwatson> and that file is being opened
[23:42] <soren> cjwatson: http://pastebin.com/f36b620cb instead, then?
[23:43] <ebroder> TheMuso: You said a while back that you were concerned that the attached debdiff for bug #330766 "could break dir/file handling in .pulse". Could you clarify what you mean by that?
[23:44] <soren> cjwatson: Oh, I'll see if I can do the 4750->4754 thing as well.
[23:44] <cjwatson> soren: yeah, that looks better - I'd || true the --list just in case somebody makes the postinst set -e in the future
[23:45] <soren> cjwatson: Oh, I didn't realise that it was considered an error condition. Thanks.
[23:46] <cjwatson> yeah, it's picky
[23:46] <TheMuso> ebroder: Will comment in the bug.
[23:46] <ebroder> TheMuso: Thanks
[23:51] <ion> Home as... ntfs? :-D
[23:53] <soren> cjwatson: http://pastebin.com/ffdb84c3
[23:53] <ebroder> ion: I've specifically seen it happen with networked homedirs when you run out of quota
[23:54] <TheMuso> ebroder: Seems I didn't comment in the bug, and I thought the diff contained a different patch, so no things look ok actually.
[23:55] <ebroder> Ok, thanks. Anybody from ubuntu-sru want to ACK bug #330766?
[23:55] <dieselmachine> I'm in need of assistance with applying a patch to some source code
[23:56] <dieselmachine> The patch is for a newer version of Ubuntu than that which I am using
[23:57] <dieselmachine> But the relevant parts appear to be the same, so I assume it should work
[23:57] <dieselmachine> How do I replace the current version on my system with the modified source I have?
[23:58] <dieselmachine> Also, gvfs is garbage and it infuriates me that such a brutal bug was present for so long with no action being taken
[23:59] <tormod> dieselmachine, debuild -b -us -uc, then dpkg -i the resulting binaries
[23:59] <cjwatson> soren: looks fine except that I think you should remove the old statoverride too