=== bregma_ is now known as bregma === tkamppeter_ is now known as tkamppeter === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === asac_ is now known as asac === dendro-afk is now known as dendrobates [02:20] lamont: so I'm pretty sure that postfix used to copy sasl modules over into its chroot without my intervention; this seems to have broken with the convertion of cyrus-sasl2 to multiarch, but I can't find where in the code it would do the copy. Can you cluebat me? [02:31] lamont: ah n/m, I've probably managed to break saslauthd [02:41] lamont: hmm, nope, saslauthd doesn't look like it was ever configured... so something else has gone wrong [02:47] does Feature Freeze mean that it's too late for new packages from Debian to get into Oneiric? [02:48] jbicha: with a good reason, you can still get them in, just file for an exception [02:48] micahg: ok, thanks, I'll give it a try then [02:48] *if you have a good reason :) [02:50] it'll just depend on if someone bothers to sponsor it in, otherwise it will happen automatically next cycle [02:51] we'll still be going through the sponsorship queue regularly, the trick is only the FFe for new packages === dendrobates is now known as dendro-afk === Arcademan is now known as Arcademan` === Arcademan` is now known as iArcade === iArcade is now known as Arcademan [03:30] Hello, I have c++ program that I would like to put in a .deb package and make available for people. I'm not familiar with the build scripts anyone with a url? [03:43] merlot: https://wiki.ubuntu.com/PackagingGuide/Complete is the full packaging guide; depending on what you want to do it can be a bit of overkill. [03:46] merlot: If you just want something simple, there are tools being developed. http://pkgme.net/ would be something to look into. [03:53] RAOF: Do I need to read the automake manual first? I just have a single .cpp file. [03:53] I've done make files before but not sure how to do this with automake [03:54] Ah. Your program is even simpler than that :). [03:55] Automake would likely be overkill there. I'm not sure how well pkgme handles plain makefile buildsystems. [03:55] On the other hand, it would also be fairly easy to whip up a source package by hand in that case. [03:56] https://wiki.ubuntu.com/PackagingGuide/Complete#Basic_Packaging isn't a bad guide there. [04:39] Good morning [05:01] * slangasek waves to pitti [05:02] hey slangasek [05:02] lamont: postfix figured out; patch pushed to oneiric === tkamppeter_ is now known as tkamppeter [06:59] good morning [07:41] doko_: I got a yelp merge proposal, OK to upload gnome-ish packages again? [07:47] pitti: fine, as long as it doesn't leave some packages unbuildable. didn't start the rebuild yet [07:47] no, shouldn't; no ABI change, and builds fine locally [07:49] slangasek: a [07:49] ta [07:54] doko_: anything blocking the rebuild from happening? [07:55] slangasek, time \o/ ... will start it today [07:55] ok :) [08:17] @pilot in === udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev [08:18] tkamppeter: I changed my mind: http://bugs.debian.org/637978 I think it's a greatly better way to solve this. [08:18] Debian bug 637978 in cups "cups: Please add a dpkg trigger to update PPDs on driver upgrades" [Wishlist,Open] === doko_ is now known as doko [08:30] OdyX: dpkg trigger sounds a lot more elegant indeed, thanks for working on this! [08:30] pitti: thank tkamppeter for writing the postinst in the first place; it sounds almost easy now. :-) [08:33] hey guys would anyone be able to help me? I'm getting an error when I try and run sudo pbuilder create [08:34] merlin371: probably more luck if you paste (pastebin) the error message :-) [08:34] :D [08:34] E: Failed getting release file http://ppa.launchpad.net/qbzr-dev/ppa/ubuntu/dists/natty/Release [08:34] E: debootstrap failed [08:34] that's what I get [08:38] OdyX, great. I like this. This perfectly overcomes the conflict between PPD updater and non-CUPS spooler support in Debian. [08:39] OdyX, thanks for working on this. [08:39] tkamppeter: actually, it's probably a damn simple patch as almost everything is already in CUPS's postinst. [08:39] (if we accept updating "all" queues' PPDs at any driver upgrade, but I think that this is sustainable (and safe)) [08:43] OdyX, to check whether a driver package should trigger the update, the packages are all which contain *.ppd files under /usr/share/ppd and/or /usr/share/cups/model, files in /usr/share/cups/drv and/or files in /usr/lib/cups/driver. In addition it should be possible to manually mark a package as a printer driver package so that it triggers a PPD update. [08:43] OdyX, every update of any printer driver package should trigger a PPD update then. [08:44] tkamppeter: my strategy was just to trigger a CUPS "update all your queues' PPDs" whenever another package touches anythin under /usr/lib/cups/filter or /usr/lib/cups/driver [08:46] merlin371: Why is it trying to grab a PPA during debootstrap? [08:46] merlin371: Also know as: stop doing that :) [08:47] our number [08:47] erk [08:48] RAOF I really dont know :P [08:49] merlin371: How are you calling pbuilder? [08:49] sudo pbuilder create [08:50] merlin371: Pastebin your ~/.pbuilderrc? [08:52] it's just one line http://pastebin.com/Jf5h5TGR I added what was said on the tutorial :) [08:53] Hm. And /etc/pbuilderrc? [08:53] http://pastebin.com/eCbKY025 [08:54] I'm guessing that's the problem? [09:11] what mirrorsite should I use on it? [09:18] OdyX, you need change this strategy a little bit: The update should be triggered if anything under /usr/lib/cups/driver, /usr/share/cups/drv, /usr/share/ppd, /usr/share/cups/model, or /usr/share/foomatic is touched. All this influences PPD files. [09:19] tkamppeter: reasonably easy; I'll put my level-0 patch to the bugreport within the hour. [09:20] OdyX, it is also needed to mark binary packages manually as needing a PPD update after installation, as it can happen that the data on which the PPDs are based are in another binary package than the executable in /usr/lib/cups/driver. [09:21] tkamppeter: the trigger always happens at the end of the installation process, so that should be OKay. [09:22] OdyX, important is that one can mark packages manually when one creates them that they need the trigger. [09:23] tkamppeter: I don't understand why: if one package installs / upgrade a file under any of those directories, then the trigger will update all queues. [09:26] merlin371: Just remove the mirrorsite and it'll use archive.ubuntu.com [09:27] OdyX, imageing that package A installs an executable /usr/lib/cups/driver/A and this executable supplies PPDs to CUPS based on data in /usr/share/A. Now a printer driver package B puts data files into /usr/share/A in order to get its PPDs supplied via /usr/lib/cups/driver/A. Now let us have an update which only updates B and not A. This should also trigger the PPD update. [09:27] ya it's working now RAOF thanks :) [09:28] tkamppeter: if B puts a file into /usr/lib/cups/driver, it'll be OK. [09:32] OdyX, so we must tell to packagers that every printer driver package which needs a PPD update has to put a file into the said directories. If it does not need so for itself to work, it should simply put a zero-byte dummy file. [09:33] tkamppeter: well… for a driver to be recognised (and used) by CUPS, doesn't it already have such a requirement ? [09:34] OdyX, principally yes and as AFAIK all current driver poackages have at least one file in the appropriate directories.. [09:35] tkamppeter: I sent the patch to the bug, it "works here", but is certainly imperfect. [09:37] tkamppeter: what will be needed at "postinst removal" time on the driver packages is to add a versioned Breaks on cups, to ensure proper upgradeability. [09:37] pitti, OdyX is introducing an infrastructure to eliminate repeated code in the postinst files of printer drivers. Should this go into Oneiric or wait for P. [09:37] tkamppeter: the patch should be rather easy, just re-run the configuration for a trigger [09:37] this seems fine for me for oneiric [09:38] all of the actual code is already happening after all [09:38] pitti: said patch is on the bug: http://bugs.debian.org/637978 . [09:38] Debian bug 637978 in cups "cups: Please add a dpkg trigger to update PPDs on driver upgrades" [Wishlist,Open] [09:38] pitti, OK, then if the appropriate CUPS is up, I will remove the code from the postinst files of the drivers. [09:39] tkamppeter: I'm available to coordinate this trough Debian unstable: I propose we do the updates on the Debian side and "just" sync to Ubuntu. [09:39] OdyX: thanks, that looks fine [09:39] 1.4.8 moved to testing, so I'm fine with uploading 1.5.0-2 to unstable now [09:40] pitti: I dislike the '.*' regex as it creates a 14'000 lines file in /tmp, but I couldn't find my way around it. [09:48] OdyX, why the '\' before the '.', does this not make the regexp matching only URIs beginning with any number of '.'s (which are all, as zero '.'s is included). Would it not be more intuitive to have the regexp empty or ".*"? [09:50] tkamppeter: shell escaping. Otherwise the ".*" gets transformed as ".gitrc .bashrc …" [09:50] (well at least here it was needed) [09:52] OdyX, another problem is that the drivers used individual regexps to assure that PPDs get only updated with PPDs of the same driver (and flavor of the driver like HPLIP and Gutenprint have IJS and CUPS Raster drivers). The regexps also overcome weird nickname changes between driver versions. [09:53] OdyX, so what we really need is that the drivers deliver their individual regexps but the code for the update is centralized. [09:54] tkamppeter: I thought about that, yeah. And feared it would be necessary. [09:55] tkamppeter: idea: cups triggers on any file in /usr/lib/cups/driver/regexes/ and drivers put their regex in those files: /usr/lib/cups/driver/regexes/${package}, which the trigger then reads. [09:55] OdyX, so the CUPS package could deliver the code in a script which takes two (optional) parameters (the regexps). But we must do all these script runs at the end of the installation, in the trigger stage, to assure that for a CUPS user CUPS is running. [09:56] tkamppeter: then use my "cupsppdupdate" (just a dump of the postinst): http://anonscm.debian.org/gitweb/?p=collab-maint/pkg-printing-tools.git;a=blob;f=cupsppdupdate/cupsppdupdate;h=dadc19a658904830122a72b54958f99f58118e99;hb=HEAD [09:56] it even has a manpage. [09:57] OdyX, OK, but let us use /usr/share/cups/regexps, as once the regexps are not executable programs (so they do not belong into /usr/lib) and second, /usr/lib/cups/driver/ should not get a subdirectory. [09:57] sure. I picked a random name. [09:57] make that "driver-regexps", to be fully clear. [09:58] OdyX, let us improve the name: /usr/share/cups/ppd-updaters [09:59] tkamppeter: As it's your code, are you going to implement it in cups or do you need me to provide patches ? (I can do it, it's just a matter of not doing things twice.) [10:00] OdyX, and note that there are two regexps, do not hardcode gennicknameregexp to empty.\ [10:01] tkamppeter: I mostly copy-pasted this from rastertosag-gdi's, feel free to make it even better. [10:01] OdyX, as you are already on it, provide me the patch. Please base it on the current HEAD, which is 1.5.0 (probably in experimental). [10:01] tkamppeter: okay. Will prepare somethin. [10:08] OdyX, you can base the trigger on files in /usr/share/cups/ppd-updaters/ then. A PPD update without regexps does not make sense, as updating all queues easily leads to switches to an unwished driver. [10:26] tkamppeter: opinions on rleigh's answer on the bugreport ? [10:30] hi [10:31] just a question: is there something special on natty's libc related to getaddrinfo? (no, I don't want support but it looks like I've found a "bug" or feature or something forcing getaddrinfo to lookup dns instead of /etc/hosts [10:40] fish_: best thing to do would be to raise a bug, with a minimal code example - and output on natty, and maverick - showing the difference. [10:41] Daviey: well, I don't have a maverick here right now.. but i'll open a bug with code example and output on natty vs debian/testing [10:41] fish_: That sounds great! [10:46] OdyX, I have answered Roger's question now. [10:55] Daviey: ah damn... shame on me *facepalm*.. soo stupid typo.. hostname was 'apollo' but hosts entries apollon... ;) [10:58] fish_: heh.. at least you caught it :) [11:00] yeah, but kind of frustrating to spend so much time on a so stupid typo ;) [11:09] tseliot: could you please look at the fglrx-installer part of bug 827046? [11:09] Launchpad bug 827046 in fglrx-installer (Ubuntu) "package grub-gfxpayload-lists 0.2.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/827046 [11:11] cjwatson: sure, I'll investigate the issue. Thanks for reporting [11:11] uploading the workaround now [11:12] thanks [11:17] thanks [11:26] tkamppeter: Too bad: dpkg-triggers only launches …/postinst triggered /usr/share/cups/ppd-updaters [11:26] tkamppeter: that means I don't know which package got updated. === zyga is now known as zyga-doctor [11:31] smoser / cjwatson / stgraber : is bug #759545 likely to be addressed for Oneiric? Thanks [11:31] Launchpad bug 759545 in grub2 (Ubuntu Oneiric) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545 [11:32] OdyX, we must somehow do one run of the ppd-updater in the end of the installation process and if there are no traces of which packages got actually updated, we must do updates on all regexp files in /usr/share/cups/ppd-updaters. To make it not too slow we must run "lpinfo -m" once and use this output for all updates. [11:33] OdyX, perhaps we can determine by file change dates which packages got replaced with the current update and which not? [11:33] tkamppeter: that means maintaining states for those, I don't want that. [11:34] tkamppeter: "run lpinfo -m" once means having that not in a separate script, but all in the postinst (I can do that actually, not hard). === yofel_ is now known as yofel [11:46] Daviey: not from my side [11:47] Sweetshark, hi, any reason for not building lo in the libreoffice ppa? [11:47] I'd take patches but it's a horrible rathole of a bug and IMO attempts to fix it have a very high propensity to go wrong [11:49] doko: -l10n needs translate-toolkit-1.9 and that seems to be a bit messy repository-wise on our side. [11:50] Sweetshark, what's the issue with translate-toolkit, if we do not import the translations, or do we? [11:51] cjwatson: it uses ucf, right? [11:51] Daviey: sort of, it's a mix of ucf and manual handling [11:51] which is why it's a pain [11:52] doko: I trying a build without translate-toolkit which would work hopefully, but I wanna see a successful local build first. [11:52] Sweetshark, comment out the export-gsi target [11:54] cjwatson: I'll see if smoser has any thoughts, it's really quite ugly at the moment.. but don't want to do more damage trying to fix it! :) [12:04] tkamppeter: okay, I'm done. Pushing the patch to the bug in seconds… [12:07] tkamppeter: http://people.debian.org/~odyx/tmp/04dde8d6a3f412b3e6b1d3a36e8bae06/cups-triggers_1.5.0-1.1.debdiff fyi. === bregma_ is now known as bregma === dendro-afk is now known as dendrobates [12:44] OdyX, great, thank you. I will look into it. [12:53] Processing 8 changed doc-base files... [12:53] Errors were encountered while processing: [12:53] /var/cache/apt/archives/gstreamer0.10-camerabin_0.10.22-2ubuntu2_amd64.deb [12:53] Error in function: [12:53] SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1) [12:53] ev: ^^^ there seems to be a replaces missing === zyga-doctor is now known as zyga [13:01] james_w: hello! do you have a advice for me? I'm trying to build a tree with a "flat" debian directory, i.e. instead of debian/changelog just changelog. it used to be possible to do this with bzr-buildpackage in --merge mode, but now its no longer. any hints for me how to make it work again? [13:01] james_w: fwiw its lp:~vmbuilder-dev/vmbuilder/packaging === dendrobates is now known as dendro-afk [13:21] doko: okay, thanks [13:21] hallyn: hi, I would like to do a new release of ubuntu-vm-builder but bzr-buildpackage is rather unhappy, do you have any preferences about how the package should be build? I would like to move it to a bzr-buildpackage configuration, it will require a working vcsversion.py, not sure yet how that is generated. or what method did you used in order to create the source package? [13:27] mvo: [13:27] hallyn: if you don't have any preferences, I would simply move the packaging into a new debian/ subdir [13:28] mvo: I guess i just stick the packaging dir in there by hand for each build [13:28] hallyn: and generate the vcsversion.py via a bzr-buildpackage build hook [13:28] that is, lp:~vmbuilder-dev/vmbuilder/packaging under lp:vmbuilder [13:28] mvo: Hmm, what are you doing with it exactly> [13:28] ? [13:28] mvo: that's fine with me, though. Please go ahead and document the new workflow somewhere. [13:28] Daviey: fixing it enough so that it can generate oneiric images [13:29] hallyn: sure, I will create a debian/README.source [13:29] mvo: thanks! [13:29] .. we were thinking of dropping it from the archive soon.. because nobody is maintaining it. [13:29] hallyn: but the idea is that bzr-buildpackage will be enough, nothing else [13:29] Daviey: I know and yet livebuild is not (yet) a replacement IMO, at least last I checked it was not at all trivial to build a vm image with it [13:30] Daviey: and honestly I think we need to have something as simple as "whatever build kvm oneirc" [13:30] yeah, I'm rather using 'vm-new -t mini' as a replacement [13:30] mvo: bzr-buildpackage from vm:vmbuilder ? [13:30] hallyn: vm-new ? [13:30] hallyn: from the packageing checkout [13:31] hallyn: so what do I need to install to get vm-new :) and will it be able to genertate images for older distro releases as well (I assume so, right)? [13:31] Daviey: vm-tools - see https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment [13:31] mvo: yup, shoudl work for all releases. That's a requirement for security team [13:32] eh, if I have to do all the 5 steps and create this textfile in ~ I think we are not quite there yet [13:32] coudl be, but if there will be wider useage perhaps we cans mooth that out [13:32] s/cans mooth/can smooth/ [13:32] mvo: would you like a python gui as well? :P [13:32] I mean, no offense, but I'm really impatient and for me this is a tool [13:33] mdeslaur: no, just "vm-new kvm oneiric" or whatever synatx after I installed it [13:33] no exports, no textfiles [13:33] mvo: Yeah, it was just on my todo to raise an archive removal request this week. :) [13:33] Daviey: jinkeys. i thought we were waiting for 12.04 to actually pull it [13:33] I think that is too early, IMO we need at least document what replaces it [13:33] vm-new --mvo-mode kvm oneiric [13:34] :) [13:34] mdeslaur: yeah vm-new --auto kvm oneiric ;) [13:34] Daviey: note that vm-builder should mainly still work! We just don't want to be maintaining all the little corner cases that break. [13:34] mdeslaur: no offense, I think this is all wonderful work, but this last bit for just works(tm) is missing ;) [13:34] mvo: mdeslaur: i'd like to find some time to smooth some of that out and maybe make a package of it [13:34] hallyn: I hit a corner case everytime i use it :) [13:35] Daviey: you *are* a corner case [13:35] thanks. :) [13:35] ok well then maybe i shoudl bump priority of productizing vm-tools? [13:35] note it's still not a full vmbuilder replacement as it requires running qemu/kvm... [13:36] well rather that than reinventing d-i :) [13:36] I'm not sure vm-tools is something that ought to be a package or a product [13:36] it's a 2000 line bash script full of workarounds and hacks [13:36] mdeslaur: Does it support foreign arches btw? armel on amd64 host? [13:37] It's not a vmbuilder replacement...it's just some scripts that we use to help us create vms [13:37] * Daviey makes a mential note that this really needs clarification at the next UDS with what we are doing. [13:39] heh :) I will just go ahead and do my tiny tiny fix for vmbuilder to make it create oneiric VMs, I'm not attached to it in any way, but I need something like this that is so simply that even I can use it [13:40] mdeslaur: hm. but don't you think that sort of thing always will necessarily be so? [13:41] echo mvo > vmbuilder-maintainers.list [13:41] mdeslaur: always have to deal with little per-distro/per-release special cases, as well as local mirroring/network context? [13:42] anyway, i'll wait then :) [13:43] hallyn: yes, but I don't think a 2000 line bash script is the way to handle it...package it if you want, but you'll be spending all your time SRUing fixes to it [13:43] updates break it, new releases break it, etc. [13:44] ironically, it's not a vmbuilder replacement...it used to be a wrapper _around_ vmbuilder :P [13:45] hallyn: /usr/bin/vm-tool could just be a wrapper to wget from http://people.ubuntu.com/~mdeslaur/vm-tool and exec as root. Seems clean enough to me :) [13:45] yes, but most bug reports for vmbuilder didn't come from vm-tools users :) [13:45] cause it had fewer options. [13:46] Daviey: there you go! +1 [13:46] hallyn: right...so what we need then is a vmbuilder replacement that only uses command line opts, and then modify vm-new to use that replacement to add all our hacks and customizations [13:47] well, one coudl argue that we spend enough time maintaining an installer that requiring users to set up their own pre-seeded install isn't unreasonable [13:47] mdeslaur: let's have Daviey write it :) [13:47] hallyn: ah! sounds like a plan :) [13:49] Hmm. [13:49] I'll write it in go. [13:50] Daviey: there you go, and you'll win a prize :) [13:50] Daviey: \0/ [13:50] (i'm an alien, i always have a big head) [13:50] maybe testdrive is the tool that should be used [13:50] it doesn't actually install [13:51] heh.. smoser and perhaps RoAkSoAx was quite keen for cobbler/koan to be considered for a replacement [13:51] do they have a prototype? [13:51] RoAkSoAx did show me how easy it could be with koan. [13:52] yes, I actually started to try and get koan working and packages [13:53] but I lost patience and added preseeding to vm-new instead [13:53] but koan would be a lot better at a package app than a 2000 line bash script [13:54] RoAkSoAx: ^ if you've been advocating it as a replacement, do you have something close to a package providing a cmd-line tool that can be tried out? [13:55] Daviey: uh, now, you're uploading gtk-vnc with sbeattie's fix right? [13:55] yes sir! [13:56] Daviey: thanks :) [13:56] imo the right way to build vms is via network or cd boot [13:57] which is waht koan does, but which can also be fairly easily done without cobbler requirement [13:57] see my 'cobbler-devenv' and the way it builds a reproducible image [13:58] the one nasty thing in it is that it ahas to extract the initramfs and gues at the command line parameters that would be set by syslinux [13:58] imo the right way to fix *that* is to have the installer optionally read a seed file off a LABELed disk. [13:58] then we'd just attach a second ISO or floppy disk that had a preseed in it it and a label named "PRESEED" on the filesystem. [13:58] and boot the Cd [13:59] smoser: yes, that's how the new mini type for vm-new works [13:59] I nabbed that idea+code from yours :) [13:59] works very nicely [13:59] and no root! [13:59] but really, we need more cooperation from the installer [13:59] parsing syslinux is no fun, and changes every release. [13:59] smoser: you and your care for non-root... [14:00] don't you run everything as root anyway? [14:00] * hallyn loads up a flash website [14:00] oh, i like root, and i like the fact that i have root on just about every machine Daviey touches. [14:00] :) [14:01] heh [14:02] hallyn: btw, I still haven't merged your mini iso stuff in, I was trying to get virt-install to use a initrd without rebuilding the iso [14:02] hallyn: but haven't succeeded yet [14:02] hallyn: sudo apt-get install koan :) [14:03] hallyn: https://help.ubuntu.com/community/Cobbler/Deployment#Deploying via koan [14:03] hallyn: and yes smoser's cobbler devenv is also pretty cool [14:08] hallyn: btw.. SRU's version on changelog's are like (if changelog is ubuntu2 then SRU is ubuntu2.1) [14:11] RoAkSoAx: my understanding was that that's only needed if the next release has ubuntu3, but not if it switched to a whole new version [14:12] but in any case yeah i did notice i didn't do that in the other debdiff. [14:12] but since i've deleted that, you can all just STEP OFF! :) [14:13] all right time to figure out wtf is going on with libvirt+cgroup-bin [14:13] hallyn: but I should proceed with the SRU's right? [14:18] RoAkSoAx: the ones i asked about yesterday? yes please [14:18] hallyn: cool. Looking at them right now ;) === dendro-afk is now known as dendrobates [14:33] pitti: ping https://bugs.launchpad.net/ubuntu/+bug/817133/comments/13 :) [14:33] Ubuntu bug 817133 in Ubuntu "[FFe] [needspackaging] ubuntuone-installer needs packaged" [High,New] [14:35] hallyn: uploded! [14:35] RoAkSoAx: thanks! [14:36] RoAkSoAx: i may have to submit another upload soon-ish :( think we need a cgrulesengd policy for libvirt. not sure yet === dendrobates is now known as dendro-afk [14:36] hallyn: ok, just let me know ;) [14:44] jbernard: hey, do you have a sec? [14:45] jbernard: i have a cgrules.conf entry: [14:45] root:libvirtd * libvirt/ [14:46] but libvirt only ended up in cpu:libvirt, but is in devices:/sysdefault (and sysdefault for all the others) [14:46] just wanna make sure i'm not doing something wrong with the entry [14:50] well this must be a bug [14:59] meh. perhaps we want the default libcgroup install to run cgrulesd but NOT cgred [14:59] smoser: ^ [14:59] smoser: have you tried running '/usr/sbin/cgrulesengd -v -d'? every task create causes that thing to work [15:00] maybe they should be split up into two packages [15:00] well, that's for later i guess. fix the bug first [15:03] hallyn, i think libvirt works fine [15:04] its cgroups-bin that is the issue [15:04] its not starting before libvirt and then libvirt has to be restarted and 'restart libvirt' doesn't funciton [15:04] smoser: no [15:05] smoser: yes cgroups-bin is the issue. but just bc it reclassifies libvirt under /sysdefault [15:05] it *has* to start before libvirt. we have upstart enforcing that [15:06] well, ok [15:07] what you point to is the better fix, but it's a fix in libvirtd! it should be able to handle having its cgroup changed [15:07] i.e. it starts in '/', then cgred gets aroudn to reclassifying it [15:08] Does anyone know why installing devscripts ends up asking a dpkg question about postfix setup? (I understand the dependency tree, but I'm curious if there's a good reason we need to keep doing this...) [15:08] cjwatson, seems like you would know ^^ [15:09] I do not [15:09] try lamont [15:10] cjwatson, thanks! lamont, consider yourself asked :) [15:10] mterry: Are you asking why postfix asks debconf questions, or why devscripts is pulling it in? [15:10] infinity, devscripts->bsd-mailx->default-mta->postfix is the chain I think [15:10] infinity, I guess why it should ask debconf questions [15:11] Because an MTA that asks no questions ends up being nearly useless. [15:11] When we shipped one by default, we used to go questionless, and people complained because it was neutered (it had to be to not have open ports). [15:11] smoser: (honestly, it doesn't quite make sense to me. the code seems to do the right thing. this shouldn't be happening) [15:12] When we moved all the m-t-a deps to recommends, we un-neutered postfix. [15:12] And I suppose then things went pear-shaped with install-recommends-by-default, where people now get asked questions sometimes, but... It beats typing "apt-get install postfix" and ending up with something that doesn't actually work as an MTA. [15:13] infinity, I'm looking at making the fresh-to-Ubuntu-packaging experience easier, and the dpkg question seems to be a point of pain. I'm trying to see what could be done to make that easier/go away [15:13] --no-install-recommends will make it go away. :P [15:14] OdyX, I have tested your patch and added it to Debian's BZR repo of CUPS now. [15:14] tkamppeter: yay. Did you need to change stuff ? [15:14] pitti, can you upload the CUPS package to Debian and Ubuntu? Thanks. [15:15] infinity, bsd-mailx is used for 'bts', 'mass-bug', and 'pts-subscribe' devscripts. I assume those are all useful enough that we couldn't tweak them or move them to a suggested package or something? [15:15] OdyX, no, worked out of the box. I have tested by updating rastertosag-gdi appropriately. [15:15] mterry: mailx itself is already suggested... [15:15] mterry: But perhaps in a recommends chain from another recommends? [15:16] mterry: install another mta explicitly such as nullmailer, then you won't get postfix at all [15:16] That's an option, sure. [15:16] Laney, hm [15:17] infinity, bsd-mailx is in the recommends for devscripts, not suggests [15:17] I dunno. Call me crazy, but if people can't answer a debconf prompt, or figure out how to install another MTA to avoid a dependency, their packages will frighten me. ;) [15:17] infinity, :) actually, I'm coming at this from the "quickly" side, where the tool is doing the packaging for the user [15:17] infinity, so I'm targetting a pretty packaging-leery audience that doesn't want to see such questions [15:18] Suggests: bsd-mailx | mailx [15:18] mterry: Which version are you seeing that as a recommends? [15:18] tkamppeter: by re-reading the patch, I think we should put the lpinfo -m in a if [ "$1" = configure ] || [ "$1" = triggered ]; then …; endif to not launch it in other cases. [15:21] infinity: appears to be recommends on natty [15:22] * infinity is curious when that changed. [15:22] git blaming now [15:22] infinity, 2.10.69ubuntu2 [15:22] infinity, in oneiric [15:23] grr, wrap-and-sort === dendro-afk is now known as dendrobates [15:24] Anyhow, that's probably the "correct" solution for us, going forward. [15:24] http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commit;h=563f6ae2376c852c22d5a960ff1a4547ac33973b [15:25] Neutering postfix for the sake of an odd use-case of "devscripts being used by people who don't understand what devscripts is for" seems odd to me. :P [15:25] barry: there is a minor problem with the m2crypto upload, it accidentally patches the removed file back in and one of the patches include to seperate fixes [15:25] barry: the former is not really a problem, as the file was confirmed as free by the author, the latter would be nice for the future merge in P [15:26] tkamppeter: ah, thanks for committing the patch [15:26] jtaylor: can you submit a bug report on it? [15:27] should I fix it? [15:27] no functional change so no exception necessary [15:28] jtaylor: that would be great; happy to sponsor it [15:29] infinity, ok, I can look into why it is now a recommends instead of a suggest and maybe it's a revertable change... [15:29] mterry: Err. No, it's now a suggests. It *was* a recommends. [15:30] mterry: As in, this is fixed in unstable and oneiric. [15:30] barry: not sure if I should remove the unintentional adding of the file, as there is an allowance by the author to distribute it, maybe just add a notice to the patch? [15:32] jtaylor: good question. ScottK might have some input on that. if there's some definitive reference for its free-ness, adding that to the patch and leaving the file included should be okay i think [15:32] infinity, guh, I'm using two laptops, one oneiric and one natty [15:32] infinity, looking at natty, but mentally thinking oneiric, because that's where my chat is [15:32] infinity, ok, awesome [15:37] Okay, this is really starting to irk me: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist === kklimonda is now known as Guest54756 [15:41] bdmurray: ping [15:41] (might be too early for you tho) [15:42] barry: not if I'm in London (which I am) [15:42] bdmurray: ah! cool. do you have a few minutes to talk about launchpad bugs? [15:42] barry: yes [15:43] bdmurray: i'll go to pvtmsg [15:48] tkamppeter: uploaded [15:51] pitti, thanks. [15:53] yay, thanks ! [15:53] OdyX: thanks muchly [15:54] cyphermox: any idea on how to get evolution to not segfault on startup now that I've updated to oneiric? [15:54] Now it's time to update all drivers to use that. Yay. === Guest54756 is now known as kklimonda [15:54] mdeslaur, run it in gdb? [15:54] (that does it for me) [15:56] seb128: nope, no dice :( === deryck is now known as deryck[lunch] === beuno is now known as beuno-lunch [16:18] Laney: ah, I missed the existence of syncpackage -d, thanks [16:18] np [16:20] and I was just about to file a sync request for ubuntu-dev-tools... :) [16:21] NEVER AGAIN! [16:28] doko: are you tagging Java on ARM related bugs in any way? [16:29] hallyn: Daviey: just read a little of the above conversation; cobbler+koan is *very* slick for that [16:30] jamespage: jamvm [16:31] cjwatson: where can I find the usb images? [16:33] doko: nowhere yet, I'm to sort them out this week [16:33] cjwatson: are these a subset of the dvd images, or is there something more installed? [16:34] pitti: replied on bug. sorry for all the confusingness of it all. :) [16:35] doko: they should end up being roughly a subset [16:36] cyphermox: hmm...I think doing dpkg -P evolution-webcal fixed it [16:36] kirkland: can it be reduced to a single command line tool to create any supported ubuntu release? [16:37] cyphermox: or one of these: dpkg -P libecal1.2-8 libebook1.2-10 libebackend1.2-0 libebook1.2-8 libedata-book1.2-8 [16:39] hallyn: hmm, good question; with the right preseed, yes, i don't see why not [16:39] hallyn: poke RoAkSoAx, as he's really deft at it [16:40] we have, i think it's on his brain :) [16:40] thanks [16:56] cjwatson: do you mind if i sync mono or would you still like to reserve it to test? [16:57] kenvandine: hey, now I understand what you said yesterday :) [17:02] Laney: could I still reserve it just for a bit longer, I'd like to test that fix [17:02] yep [17:02] Laney: hm, I notice that BaseWrapper has a __call__ method that's return self._lpobject [17:02] you could actually do the sync if you want, I've got to walk home now [17:02] Laney: do you think that violates encap too? [17:02] I sort of agree that at least the bare copyPackage method probably ought to be done in lpapicache, so that callers just see Archive wrapper objects, though [17:03] I see why it can be pragmatically useful, but I'd prefer to keep stuff in ubuntutools as far as possible [17:03] like I say, don't block on that though — we can do it later [17:03] I'm doing it now anyway :) [17:03] seems like a very odd use of __call__ [17:04] indeed === deryck[lunch] is now known as deryck [17:04] I wonder if it's made use of anywhere [17:04] hard to tell ... [17:04] sadly [17:05]