[02:20] <slangasek> 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] <slangasek> lamont: ah n/m, I've probably managed to break saslauthd
[02:41] <slangasek> lamont: hmm, nope, saslauthd doesn't look like it was ever configured... so something else has gone wrong
[02:47] <jbicha> does Feature Freeze mean that it's too late for new packages from Debian to get into Oneiric?
[02:48] <micahg> jbicha: with a good reason, you can still get them in, just file for an exception
[02:48] <jbicha> micahg: ok, thanks, I'll give it a try then
[02:48] <micahg> *if you have a good reason :)
[02:50] <jbicha> it'll just depend on if someone bothers to sponsor it in, otherwise it will happen automatically next cycle
[02:51] <micahg> we'll still be going through the sponsorship queue regularly, the trick is only the FFe for new packages
[03:30] <merlot> 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] <RAOF> 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] <RAOF> merlot: If you just want something simple, there are tools being developed.  http://pkgme.net/ would be something to look into.
[03:53] <merlot> RAOF: Do I need to read the automake manual first? I just have a single .cpp file.
[03:53] <merlot> I've done make files before but not sure how to do this with automake
[03:54] <RAOF> Ah.  Your program is even simpler than that :).
[03:55] <RAOF> Automake would likely be overkill there.  I'm not sure how well pkgme handles plain makefile buildsystems.
[03:55] <RAOF> On the other hand, it would also be fairly easy to whip up a source package by hand in that case.
[03:56] <RAOF> https://wiki.ubuntu.com/PackagingGuide/Complete#Basic_Packaging isn't a bad guide there.
[04:39] <pitti> Good morning
[05:01]  * slangasek waves to pitti 
[05:02] <pitti> hey slangasek
[05:02] <slangasek> lamont: postfix figured out; patch pushed to oneiric
[06:59] <dholbach> good morning
[07:41] <pitti> doko_: I got a yelp merge proposal, OK to upload gnome-ish packages again?
[07:47] <doko_> pitti: fine, as long as it doesn't leave some packages unbuildable. didn't start the rebuild yet
[07:47] <pitti> no, shouldn't; no ABI change, and builds fine locally
[07:49] <lamont> slangasek: a
[07:49] <lamont> ta
[07:54] <slangasek> doko_: anything blocking the rebuild from happening?
[07:55] <doko_> slangasek, time \o/ ... will start it today
[07:55] <slangasek> ok :)
[08:17] <ev> @pilot in
[08:18] <OdyX> tkamppeter: I changed my mind: http://bugs.debian.org/637978 I think it's a greatly better way to solve this.
[08:30] <pitti> OdyX: dpkg trigger sounds a lot more elegant indeed, thanks for working on this!
[08:30] <OdyX> pitti: thank tkamppeter for writing the postinst in the first place; it sounds almost easy now. :-)
[08:33] <merlin371> hey guys would anyone be able to help me? I'm getting an error when I try and run sudo pbuilder create
[08:34] <sladen> merlin371: probably more luck if you paste (pastebin) the error message :-)
[08:34] <merlin371> :D
[08:34] <merlin371> E: Failed getting release file http://ppa.launchpad.net/qbzr-dev/ppa/ubuntu/dists/natty/Release
[08:34] <merlin371> E: debootstrap failed
[08:34] <merlin371> that's what I get
[08:38] <tkamppeter> OdyX, great. I like this. This perfectly overcomes the conflict between PPD updater and non-CUPS spooler support in Debian.
[08:39] <tkamppeter> OdyX, thanks for working on this.
[08:39] <OdyX> tkamppeter: actually, it's probably a damn simple patch as almost everything is already in CUPS's postinst.
[08:39] <OdyX> (if we accept updating "all" queues' PPDs at any driver upgrade, but I think that this is sustainable (and safe))
[08:43] <tkamppeter> 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] <tkamppeter> OdyX, every update of any printer driver package should trigger a PPD update then.
[08:44] <OdyX> 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] <RAOF> merlin371: Why is it trying to grab a PPA during debootstrap?
[08:46] <RAOF> merlin371: Also know as: stop doing that :)
[08:47] <sabdfl> our number
[08:47] <sabdfl> erk
[08:48] <merlin371> RAOF I really dont know :P
[08:49] <RAOF> merlin371: How are you calling pbuilder?
[08:49] <merlin371> sudo pbuilder create
[08:50] <RAOF> merlin371: Pastebin your ~/.pbuilderrc?
[08:52] <merlin371> it's just one line http://pastebin.com/Jf5h5TGR I added what was said on the tutorial :)
[08:53] <RAOF> Hm.  And /etc/pbuilderrc?
[08:53] <merlin371> http://pastebin.com/eCbKY025
[08:54] <merlin371> I'm guessing that's the problem?
[09:11] <merlin371> what mirrorsite should I use on it?
[09:18] <tkamppeter> 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] <OdyX> tkamppeter: reasonably easy; I'll put my level-0 patch to the bugreport within the hour.
[09:20] <tkamppeter> 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] <OdyX> tkamppeter: the trigger always happens at the end of the installation process, so that should be OKay.
[09:22] <tkamppeter> OdyX, important is that one can mark packages manually when one creates them that they need the trigger.
[09:23] <OdyX> 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] <RAOF> merlin371: Just remove the mirrorsite and it'll use archive.ubuntu.com
[09:27] <tkamppeter> 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] <merlin371> ya it's working now RAOF thanks :)
[09:28] <OdyX> tkamppeter: if B puts a file into /usr/lib/cups/driver, it'll be OK.
[09:32] <tkamppeter> 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] <OdyX> tkamppeter: well… for a driver to be recognised (and used) by CUPS, doesn't it already have such a requirement ?
[09:34] <tkamppeter> OdyX, principally yes and as AFAIK all current driver poackages have at least one file in the appropriate directories..
[09:35] <OdyX> tkamppeter: I sent the patch to the bug, it "works here", but is certainly imperfect.
[09:37] <OdyX> 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] <tkamppeter> 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] <pitti> tkamppeter: the patch should be rather easy, just re-run the configuration for a trigger
[09:37] <pitti> this seems fine for me for oneiric
[09:38] <pitti> all of the actual code is already happening after all
[09:38] <OdyX> pitti: said patch is on the bug: http://bugs.debian.org/637978 .
[09:38] <tkamppeter> pitti, OK, then if the appropriate CUPS is up, I will remove the code from the postinst files of the drivers.
[09:39] <OdyX> 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] <pitti> OdyX: thanks, that looks fine
[09:39] <pitti> 1.4.8 moved to testing, so I'm fine with uploading 1.5.0-2 to unstable now
[09:40] <OdyX> 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] <tkamppeter> 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] <OdyX> tkamppeter: shell escaping. Otherwise the ".*" gets transformed as ".gitrc .bashrc …"
[09:50] <OdyX> (well at least here it was needed)
[09:52] <tkamppeter> 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] <tkamppeter> OdyX, so what we really need is that the drivers deliver their individual regexps but the code for the update is centralized.
[09:54] <OdyX> tkamppeter: I thought about that, yeah. And feared it would be necessary.
[09:55] <OdyX> 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] <tkamppeter> 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] <OdyX> 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] <OdyX> it even has a manpage.
[09:57] <tkamppeter> 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] <OdyX> sure. I picked a random name.
[09:57] <OdyX> make that "driver-regexps", to be fully clear.
[09:58] <tkamppeter> OdyX, let us improve the name: /usr/share/cups/ppd-updaters
[09:59] <OdyX> 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] <tkamppeter> OdyX, and note that there are two regexps, do not hardcode gennicknameregexp to empty.\
[10:01] <OdyX> tkamppeter: I mostly copy-pasted this from rastertosag-gdi's, feel free to make it even better.
[10:01] <tkamppeter> 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] <OdyX> tkamppeter: okay. Will prepare somethin.
[10:08] <tkamppeter> 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] <OdyX> tkamppeter: opinions on rleigh's answer on the bugreport ?
[10:30] <fish_> hi
[10:31] <fish_> 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] <Daviey> 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] <fish_> 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] <Daviey> fish_: That sounds great!
[10:46] <tkamppeter> OdyX, I have answered Roger's question now.
[10:55] <fish_> Daviey: ah damn... shame on me *facepalm*.. soo stupid typo.. hostname was 'apollo' but hosts entries apollon... ;)
[10:58] <Daviey> fish_: heh.. at least you caught it :)
[11:00] <fish_> yeah, but kind of frustrating to spend so much time on a so stupid typo ;)
[11:09] <cjwatson> tseliot: could you please look at the fglrx-installer part of bug 827046?
[11:11] <tseliot> cjwatson: sure, I'll investigate the issue. Thanks for reporting
[11:11] <cjwatson> uploading the workaround now
[11:12] <cjwatson> thanks
[11:17] <tseliot> thanks
[11:26] <OdyX> tkamppeter: Too bad: dpkg-triggers only launches …/postinst triggered /usr/share/cups/ppd-updaters
[11:26] <OdyX> tkamppeter: that means I don't know which package got updated.
[11:31] <Daviey> smoser / cjwatson / stgraber : is bug #759545 likely to be addressed for Oneiric?  Thanks
[11:32] <tkamppeter> 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] <tkamppeter> OdyX, perhaps we can determine by file change dates which packages got replaced with the current update and which not?
[11:33] <OdyX> tkamppeter: that means maintaining states for those, I don't want that.
[11:34] <OdyX> 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).
[11:46] <cjwatson> Daviey: not from my side
[11:47] <doko> Sweetshark, hi, any reason for not building lo in the libreoffice ppa?
[11:47] <cjwatson> 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] <Sweetshark> doko: -l10n needs translate-toolkit-1.9 and that seems to be a bit messy repository-wise on our side.
[11:50] <doko> Sweetshark, what's the issue with translate-toolkit, if we do not import the translations, or do we?
[11:51] <Daviey> cjwatson: it uses ucf, right?
[11:51] <cjwatson> Daviey: sort of, it's a mix of ucf and manual handling
[11:51] <cjwatson> which is why it's a pain
[11:52] <Sweetshark> doko: I trying a build without translate-toolkit which would work hopefully, but I wanna see a successful local build first.
[11:52] <doko> Sweetshark, comment out the export-gsi target
[11:54] <Daviey> 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] <OdyX> tkamppeter: okay, I'm done. Pushing the patch to the bug in seconds…
[12:07] <OdyX> tkamppeter: http://people.debian.org/~odyx/tmp/04dde8d6a3f412b3e6b1d3a36e8bae06/cups-triggers_1.5.0-1.1.debdiff fyi.
[12:44] <tkamppeter> OdyX, great, thank you. I will look into it.
[12:53] <doko> Processing 8 changed doc-base files...
[12:53] <doko> Errors were encountered while processing:
[12:53] <doko>  /var/cache/apt/archives/gstreamer0.10-camerabin_0.10.22-2ubuntu2_amd64.deb
[12:53] <doko> Error in function:
[12:53] <doko> SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)
[12:53] <doko> ev: ^^^ there seems to be a replaces missing
[13:01] <mvo> 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] <mvo> james_w: fwiw its lp:~vmbuilder-dev/vmbuilder/packaging
[13:21] <ev> doko: okay, thanks
[13:21] <mvo> 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] <hallyn> mvo: <thinking>
[13:27] <mvo> hallyn: if you don't have any preferences, I would simply move the packaging into a new debian/ subdir
[13:28] <hallyn> mvo: I guess i just stick the packaging dir in there by hand for each build
[13:28] <mvo> hallyn: and generate the vcsversion.py via a bzr-buildpackage build hook
[13:28] <hallyn> that is, lp:~vmbuilder-dev/vmbuilder/packaging under lp:vmbuilder
[13:28] <Daviey> mvo: Hmm, what are you doing with it exactly>
[13:28] <Daviey> ?
[13:28] <hallyn> mvo: that's fine with me, though.  Please go ahead and document the new workflow somewhere.
[13:28] <mvo> Daviey: fixing it enough so that it can generate oneiric images
[13:29] <mvo> hallyn: sure, I will create a debian/README.source
[13:29] <hallyn> mvo: thanks!
[13:29] <Daviey> .. we were thinking of dropping it from the archive soon.. because nobody is maintaining it.
[13:29] <mvo> hallyn: but the idea is that bzr-buildpackage will be enough, nothing else
[13:29] <mvo> 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] <mvo> Daviey: and honestly I think we need to have something as simple as "whatever build kvm oneirc"
[13:30] <hallyn> yeah, I'm rather using 'vm-new -t mini' as a replacement
[13:30] <hallyn> mvo: bzr-buildpackage from vm:vmbuilder ?
[13:30] <Daviey> hallyn: vm-new ?
[13:30] <mvo> hallyn: from the packageing checkout
[13:31] <mvo> 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] <hallyn> Daviey: vm-tools - see https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment
[13:31] <hallyn> mvo: yup, shoudl work for all releases.  That's a requirement for security team
[13:32] <mvo> 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] <hallyn> coudl be, but if there will be wider useage perhaps we cans mooth that out
[13:32] <hallyn> s/cans mooth/can smooth/
[13:32] <mdeslaur> mvo: would you like a python gui as well? :P
[13:32] <mvo> I mean, no offense, but I'm really impatient and for me this is a tool
[13:33] <mvo> mdeslaur: no, just "vm-new kvm oneiric" or whatever synatx after I installed it
[13:33] <mvo> no exports, no textfiles
[13:33] <Daviey> mvo: Yeah, it was just on my todo to raise an archive removal request this week. :)
[13:33] <hallyn> Daviey: jinkeys.  i thought we were waiting for 12.04 to actually pull it
[13:33] <mvo> I think that is too early, IMO we need at least document what replaces it
[13:33] <mdeslaur> vm-new --mvo-mode kvm oneiric
[13:34] <mdeslaur> :)
[13:34] <mvo> mdeslaur: yeah vm-new --auto kvm oneiric ;)
[13:34] <hallyn> 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] <mvo> mdeslaur: no offense, I think this is all wonderful work, but this last bit for just works(tm) is missing ;)
[13:34] <hallyn> mvo: mdeslaur: i'd like to find some time to smooth some of that out and maybe make a package of it
[13:34] <Daviey> hallyn: I hit a corner case everytime i use it :)
[13:35] <hallyn> Daviey: you *are* a corner case
[13:35] <Daviey> thanks. :)
[13:35] <hallyn> ok well then maybe i shoudl bump priority of productizing vm-tools?
[13:35] <hallyn> note it's still not a full vmbuilder replacement as it requires running qemu/kvm...
[13:36] <Daviey> well rather that than reinventing d-i :)
[13:36] <mdeslaur> I'm not sure vm-tools is something that ought to be a package or a product
[13:36] <mdeslaur> it's a 2000 line bash script full of workarounds and hacks
[13:36] <Daviey> mdeslaur: Does it support foreign arches btw?  armel on amd64 host?
[13:37] <mdeslaur> 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] <mvo> 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] <hallyn> mdeslaur: hm.  but don't you think that sort of thing always will necessarily be so?
[13:41] <Daviey> echo mvo > vmbuilder-maintainers.list
[13:41] <hallyn> mdeslaur: always have to deal with little per-distro/per-release special cases, as well as local mirroring/network context?
[13:42] <hallyn> anyway, i'll wait then :)
[13:43] <mdeslaur> 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] <mdeslaur> updates break it, new releases break it, etc.
[13:44] <mdeslaur> ironically, it's not a vmbuilder replacement...it used to be a wrapper _around_ vmbuilder :P
[13:45] <Daviey> 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] <hallyn> yes, but most bug reports for vmbuilder didn't come from vm-tools users :)
[13:45] <hallyn> cause it had fewer options.
[13:46] <mdeslaur> Daviey: there you go! +1
[13:46] <mdeslaur> 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] <hallyn> 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] <hallyn> mdeslaur: let's have Daviey write it :)
[13:47] <mdeslaur> hallyn: ah! sounds like a plan :)
[13:49] <Daviey> Hmm.
[13:49] <Daviey> I'll write it in go.
[13:50] <mdeslaur> Daviey: there you go, and you'll win a prize :)
[13:50] <hallyn> Daviey: \0/
[13:50] <hallyn> (i'm an alien, i always have a big head)
[13:50] <mdeslaur> maybe testdrive is the tool that should be used
[13:50] <hallyn> it doesn't actually install
[13:51] <Daviey> heh.. smoser and perhaps RoAkSoAx was quite keen for cobbler/koan to be considered for a replacement
[13:51] <hallyn> do they have a prototype?
[13:51] <Daviey> RoAkSoAx did show me how easy it could be with koan.
[13:52] <mdeslaur> yes, I actually started to try and get koan working and packages
[13:53] <mdeslaur> but I lost patience and added preseeding to vm-new instead
[13:53] <mdeslaur> but koan would be a lot better at a package app than a 2000 line bash script
[13:54] <hallyn> 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] <hallyn> Daviey: uh, now, you're uploading gtk-vnc with sbeattie's fix right?
[13:55] <Daviey> yes sir!
[13:56] <hallyn> Daviey: thanks :)
[13:56] <smoser> imo the right way to build vms is via network or cd boot
[13:57] <smoser> which is waht koan does, but which can also be fairly easily done without cobbler requirement
[13:57] <smoser> see my 'cobbler-devenv' and the way it builds a reproducible image
[13:58] <smoser> 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] <smoser> imo the right way to fix *that* is to have the installer optionally read a seed file off a LABELed disk.
[13:58] <smoser> 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] <smoser> and boot the Cd
[13:59] <hallyn> smoser: yes, that's how the new mini type for vm-new works
[13:59] <hallyn> I nabbed that idea+code from yours :)
[13:59] <hallyn> works very nicely
[13:59] <smoser> and no root!
[13:59] <smoser> but really, we need more cooperation from the installer
[13:59] <smoser> parsing syslinux is no fun, and changes every release.
[13:59] <Daviey> smoser: you and your care for non-root...
[14:00] <hallyn> don't you run everything as root anyway?
[14:00]  * hallyn loads up a flash website
[14:00] <smoser> oh, i like root, and i like the fact that i have root on just about every machine Daviey touches.
[14:00] <smoser> :)
[14:01] <Daviey> heh
[14:02] <mdeslaur> 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] <mdeslaur> hallyn: but haven't succeeded yet
[14:02] <RoAkSoAx> hallyn: sudo apt-get install koan :)
[14:03] <RoAkSoAx> hallyn: https://help.ubuntu.com/community/Cobbler/Deployment#Deploying via koan
[14:03] <RoAkSoAx> hallyn: and yes smoser's cobbler devenv is also pretty cool
[14:08] <RoAkSoAx> hallyn: btw.. SRU's version on changelog's are like (if changelog is ubuntu2 then SRU is ubuntu2.1)
[14:11] <hallyn> 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] <hallyn> but in any case yeah i did notice i didn't do that in the other debdiff.
[14:12] <hallyn> but since i've deleted that, you can all just STEP OFF!  :)
[14:13] <hallyn> all right time to figure out wtf is going on with libvirt+cgroup-bin
[14:13] <RoAkSoAx> hallyn: but I should proceed with the SRU's right?
[14:18] <hallyn> RoAkSoAx: the ones i asked about yesterday?  yes please
[14:18] <RoAkSoAx> hallyn: cool. Looking at them right now ;)
[14:33] <dobey> pitti: ping https://bugs.launchpad.net/ubuntu/+bug/817133/comments/13 :)
[14:35] <RoAkSoAx> hallyn: uploded!
[14:35] <hallyn> RoAkSoAx: thanks!
[14:36] <hallyn> RoAkSoAx: i may have to submit another upload soon-ish :(  think we need a cgrulesengd policy for libvirt.  not sure yet
[14:36] <RoAkSoAx> hallyn: ok, just let me know ;)
[14:44] <hallyn> jbernard: hey, do you have a sec?
[14:45] <hallyn> jbernard: i have a cgrules.conf entry:
[14:45] <hallyn> root:libvirtd   *               libvirt/
[14:46] <hallyn> but libvirt only ended up in cpu:libvirt, but is in devices:/sysdefault (and sysdefault for all the others)
[14:46] <hallyn> just wanna make sure i'm not doing something wrong with the entry
[14:50] <hallyn> well this must be a bug
[14:59] <hallyn> meh.  perhaps we want the default libcgroup install to run cgrulesd but NOT cgred
[14:59] <hallyn> smoser: ^
[14:59] <hallyn> smoser: have you tried running '/usr/sbin/cgrulesengd -v -d'?  every task create causes that thing to work
[15:00] <hallyn> maybe they should be split up into two packages
[15:00] <hallyn> well, that's for later i guess.  fix the bug first
[15:03] <smoser> hallyn, i think libvirt works fine
[15:04] <smoser> its cgroups-bin that is the issue
[15:04] <smoser> its not starting before libvirt and then libvirt has to be restarted and 'restart libvirt' doesn't funciton
[15:04] <hallyn> smoser: no
[15:05] <hallyn> smoser: yes cgroups-bin is the issue.  but just bc it reclassifies libvirt under /sysdefault
[15:05] <hallyn> it *has* to start before libvirt.  we have upstart enforcing that
[15:06] <hallyn> well, ok
[15:07] <hallyn> 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] <hallyn> i.e. it starts in '/', then cgred gets aroudn to reclassifying it
[15:08] <mterry> 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] <mterry> cjwatson, seems like you would know ^^
[15:09] <cjwatson> I do not
[15:09] <cjwatson> try lamont
[15:10] <mterry> cjwatson, thanks!  lamont, consider yourself asked  :)
[15:10] <infinity> mterry: Are you asking why postfix asks debconf questions, or why devscripts is pulling it in?
[15:10] <mterry> infinity, devscripts->bsd-mailx->default-mta->postfix  is the chain I think
[15:10] <mterry> infinity, I guess why it should ask debconf questions
[15:11] <infinity> Because an MTA that asks no questions ends up being nearly useless.
[15:11] <infinity> 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] <hallyn> 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] <infinity> When we moved all the m-t-a deps to recommends, we un-neutered postfix.
[15:12] <infinity> 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] <mterry> 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] <infinity> --no-install-recommends will make it go away. :P
[15:14] <tkamppeter> OdyX, I have tested your patch and added it to Debian's BZR repo of CUPS now.
[15:14] <OdyX> tkamppeter: yay. Did you need to change stuff ?
[15:14] <tkamppeter> pitti, can you upload the CUPS package to Debian and Ubuntu? Thanks.
[15:15] <mterry> 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] <tkamppeter> OdyX, no, worked out of the box. I have tested by updating rastertosag-gdi appropriately.
[15:15] <infinity> mterry: mailx itself is already suggested...
[15:15] <infinity> mterry: But perhaps in a recommends chain from another recommends?
[15:16] <Laney> mterry: install another mta explicitly such as nullmailer, then you won't get postfix at all
[15:16] <infinity> That's an option, sure.
[15:16] <mterry> Laney, hm
[15:17] <mterry> infinity, bsd-mailx is in the recommends for devscripts, not suggests
[15:17] <infinity> 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] <mterry> infinity, :) actually, I'm coming at this from the "quickly" side, where the tool is doing the packaging for the user
[15:17] <mterry> infinity, so I'm targetting a pretty packaging-leery audience that doesn't want to see such questions
[15:18] <infinity> Suggests: bsd-mailx | mailx
[15:18] <infinity> mterry: Which version are you seeing that as a recommends?
[15:18] <OdyX> 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] <Laney> infinity: appears to be recommends on natty
[15:22]  * infinity is curious when that changed.
[15:22] <Laney> git blaming now
[15:22] <mterry> infinity, 2.10.69ubuntu2
[15:22] <mterry> infinity, in oneiric
[15:23] <Laney> grr, wrap-and-sort
[15:24] <infinity> Anyhow, that's probably the "correct" solution for us, going forward.
[15:24] <Laney> http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commit;h=563f6ae2376c852c22d5a960ff1a4547ac33973b
[15:25] <infinity> 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] <jtaylor> 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] <jtaylor> 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] <pitti> tkamppeter: ah, thanks for committing the patch
[15:26] <barry> jtaylor: can you submit a bug report on it?
[15:27] <jtaylor> should I fix it?
[15:27] <jtaylor> no functional change so no exception necessary
[15:28] <barry> jtaylor: that would be great; happy to sponsor it
[15:29] <mterry> 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] <infinity> mterry: Err.  No, it's now a suggests.  It *was* a recommends.
[15:30] <infinity> mterry: As in, this is fixed in unstable and oneiric.
[15:30] <jtaylor> 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] <barry> 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] <mterry> infinity, guh, I'm using two laptops, one oneiric and one natty
[15:32] <mterry> infinity, looking at natty, but mentally thinking oneiric, because that's where my chat is
[15:32] <mterry> infinity, ok, awesome
[15:37] <infinity> 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
[15:41] <barry> bdmurray: ping
[15:41] <barry> (might be too early for you tho)
[15:42] <bdmurray> barry: not if I'm in London (which I am)
[15:42] <barry> bdmurray: ah! cool. do you have a few minutes to talk about launchpad bugs?
[15:42] <bdmurray> barry: yes
[15:43] <barry> bdmurray: i'll go to pvtmsg
[15:48] <pitti> tkamppeter: uploaded
[15:51] <tkamppeter> pitti, thanks.
[15:53] <OdyX> yay, thanks !
[15:53] <pitti> OdyX: thanks muchly
[15:54] <mdeslaur> cyphermox: any idea on how to get evolution to not segfault on startup now that I've updated to oneiric?
[15:54] <OdyX> Now it's time to update all drivers to use that. Yay.
[15:54] <seb128> mdeslaur, run it in gdb?
[15:54] <seb128> (that does it for me)
[15:56] <mdeslaur> seb128: nope, no dice :(
[16:18] <cjwatson> Laney: ah, I missed the existence of syncpackage -d, thanks
[16:18] <Laney> np
[16:20] <tumbleweed> and I was just about to file a sync request for ubuntu-dev-tools... :)
[16:21] <Laney> NEVER AGAIN!
[16:28] <jamespage> doko: are you tagging Java on ARM related bugs in any way?
[16:29] <kirkland> hallyn: Daviey: just read a little of the above conversation;  cobbler+koan is *very* slick for that
[16:30] <doko> jamespage: jamvm
[16:31] <doko> cjwatson: where can I find the usb images?
[16:33] <cjwatson> doko: nowhere yet, I'm to sort them out this week
[16:33] <doko> cjwatson: are these a subset of the dvd images, or is there something more installed?
[16:34] <dobey> pitti: replied on bug. sorry for all the confusingness of it all. :)
[16:35] <cjwatson> doko: they should end up being roughly a subset
[16:36] <mdeslaur> cyphermox: hmm...I think doing dpkg -P evolution-webcal fixed it
[16:36] <hallyn> kirkland: can it be reduced to a single command line tool to create any supported ubuntu release?
[16:37] <mdeslaur> 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] <kirkland> hallyn: hmm, good question;  with the right preseed, yes, i don't see why not
[16:39] <kirkland> hallyn: poke RoAkSoAx, as he's really deft at it
[16:40] <hallyn> we have, i think it's on his brain :)
[16:40] <hallyn> thanks
[16:56] <Laney> cjwatson: do you mind if i sync mono or would you still like to reserve it to test?
[16:57] <Ursinha> kenvandine: hey, now I understand what you said yesterday :)
[17:02] <cjwatson> Laney: could I still reserve it just for a bit longer, I'd like to test that fix
[17:02] <Laney> yep
[17:02] <cjwatson> Laney: hm, I notice that BaseWrapper has a __call__ method that's return self._lpobject
[17:02] <Laney> you could actually do the sync if you want, I've got to walk home now
[17:02] <cjwatson> Laney: do you think that violates encap too?
[17:02] <cjwatson> 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] <Laney> I see why it can be pragmatically useful, but I'd prefer to keep stuff in ubuntutools as far as possible
[17:03] <Laney> like I say, don't block on that though — we can do it later
[17:03] <cjwatson> I'm doing it now anyway :)
[17:03] <cjwatson> seems like a very odd use of __call__
[17:04] <Laney> indeed
[17:04] <Laney> I wonder if it's made use of anywhere
[17:04] <cjwatson> hard to tell ...
[17:04] <Laney> sadly
[17:05] <Laney> silly dynamic languages :-)
[17:05] <Laney> anyway, back later
[17:28] <tkamppeter> kees, hi
[17:32] <kees> tkamppeter: hello!
[17:34]  * doko hides from the colord fight ...
[17:36] <kenvandine> hey Ursinha
[17:50] <tkamppeter> kees, I have seen your answer. So we must see whether Richard Hughes (or RAOF) can improve the situation, otherwise we need to skip the Blueprint over to P and give Richard six months to improve colord.
[17:58] <tkamppeter> kees, the inserted media case is already covered by one of Richard's patches. RAOF could include it in the package.
[18:00] <ahasenack> hi guys, are there some guidelines somewhere about using dh_python2 in ubuntu? Or should I just follow the debian guides?
[18:02] <micahg> ahasenack: http://wiki.debian.org/Python/TransitionToDHPython2?action=show&redirect=Python%2FPythonSupportToDHPython2, conversion needs an FFe though
[18:02] <ahasenack> micahg: FFe for what, oneiric?
[18:03] <micahg> ahasenack: yeah, the change probably shouldn't happed for anything before
[18:03] <micahg> *happen
[18:03] <ahasenack> micahg: ok, thanks
[18:03] <ahasenack> micahg: I'm playing with a ppa first, and this package isn't in ubuntu
[18:03] <micahg> ah, ok, well have fun then :)
[18:03] <ahasenack> nor debian
[18:04] <ahasenack> micahg: is there a doc for starting from scratch with dh_python2? That one is about converting existing packages
[18:04] <ahasenack> I guess man dh_python2
[18:05] <ahasenack> or the instructions about packaging python apps, let me search for that
[18:07] <slangasek> from scratch:  %:\n\tdh $@ --with=python2\n^D
[18:08] <slangasek> by default, it should all DTRT
[18:08] <ahasenack> I meant a debian/rules file, not /etc/sendmail.cf
[18:08] <ahasenack> :D
[18:08] <slangasek> hah
[18:08] <slangasek> %:
[18:09] <slangasek>    dh $@ --with-python2
[18:09] <slangasek> :P
[18:09] <ahasenack> much nicer :)
[18:09] <ahasenack> ok, I will have to work a bit here, as this package has to build on hardy, lucid and all the rest that is still supported
[18:10] <slangasek> ah
[18:10] <slangasek> well, backporting dh_python2 for lucid is a todo for this cycle still
[18:10] <ahasenack> I have lots of ifneq (,$(findstring $(dist_release),"hardy")) type of things in this rule file
[18:11] <slangasek> but backporting it to hardy isn't in the cards; the python upstream support isn't there that far back
[18:11] <ahasenack> and the other releases
[18:11] <ahasenack> sure
[18:11] <jtaylor> --with python no hyphen
[18:11] <jtaylor> s/python/python2/
[18:15] <dobey> ScottK: do the last few comments on bug #817133 help any? or you need more clarification?
[18:17] <slangasek> jtaylor: er, yes; I meant --with=python2, sorry
[18:18] <slangasek> you know, I would swear flashplugin is eating less CPU now that I've removed ia32-libs
[18:19] <micahg> slangasek: is flashplugin-installer using the multiarch libs now?
[18:19] <slangasek> micahg: all the libs necessary to cross-install flashplugin-installer are multiarched
[18:20] <slangasek> micahg: so you need only run 'apt-get install flashplugin-installer:i386'
[18:21] <micahg> slangasek: can we switch the amd64 version to use the multiarch 32 bit libs?
[18:21] <slangasek> micahg: no; what we can do is drop the amd64 package from the archiv
[18:21] <slangasek> e
[18:22] <micahg> slangasek: why wouldn't we want to have it displayed as an option to install for people? (or does flashplugin-installer:i386 show up in software center)?
[18:22] <slangasek> micahg: i386 packages will show up just fine in software center
[18:23] <slangasek> and "want to have it displayed" is not the issue - the issue is that we don't support specifying "this package of arch x depends on that package of arch y"
[18:23] <slangasek> you can only say "arch needs to match" or "arch doesn't need to match" - so it has to be an i386 package to ensure the correct i386 libs are pulled in
[18:23] <micahg> slangasek: also, don't we still need the nspluginwrapper depends for it?
[18:24] <slangasek> I'm working on that part
[18:24] <micahg> ok
[18:32] <jbicha> Adobe just needs to hurry up and release Flash Player 11 for 64bit
[18:32] <slangasek> they did that once before; it wasn't very good
[18:32] <slangasek> well, not 11
[18:32] <slangasek> other numbers
[18:33] <jbicha> it was never an official release, just an unsupported beta right?
[18:33] <slangasek> yes
[18:33] <micahg> slangasek: does multiarch installation work against partner as well or just the main archive?
[18:33] <jbicha> I'm using Flash 11 64 from sevenmachines' PPA
[18:33] <slangasek> micahg: works fine with partner; I have skype:i386 installed right now, and have tested adobe-flashplugin:i386
[18:34] <micahg> slangasek: very cool, so once you get the nspluginwrapper bits fixed, we can just drop flashplugin-installer entirely
[18:35] <slangasek> hmm, really?
[18:35] <slangasek> I didn't realize that was the only reason it was around
[18:35] <micahg> yeah, flashplugin-installer is just a wrapper to handle the nspluginwrapper bits
[18:37] <ricotz> slangasek, hello, could you get gnome-menus NEWed?
[18:38] <slangasek> ricotz: there are an awful lot of packages in the NEW queue ahead of it; is there some particular reason gnome-menus is needed right now?
[18:40] <ricotz> slangasek, hmm sorry, i would like to update the gnome-shell snapshot which already depends on it
[18:40] <ricotz> slangasek, i was hoping pitti would get to it, but he called it a day already ;)
[18:40] <slangasek> ricotz: I'll have a look at cutting down the NEW queue, but it's first come first serve :)
[18:41] <ricotz> slangasek, no problem, thank you
[18:59] <slangasek> bdmurray: is there a sensible way to write a bug pattern to trap the duplicates listed on https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bugs?field.searchtext=upgrade+134 ?  (The error code is not enough to identify them as duplicates, we should examine the backtrace in the term.log...)
[19:01] <micahg> Laney: did you use th new script to sync mono?
[19:02] <Laney> yap
[19:03] <micahg> so, it's not doing the equivalent of -vUBUNTU_VERSION, I'm just wondering if this is a known issue
[19:03] <Laney> just filed it
[19:04] <slangasek> ScottK: still waiting for Debian feedback on bug #825689?
[19:04] <slangasek> ScottK: provided that no one can see a reason that qdbus is needed in the -dev package, I'm happy to JFDI
[19:07] <cjwatson> Laney: I filed that too ...
[19:07] <Laney> oops
[19:07] <slangasek> mdeslaur: I've just uploaded a multiarchified nspluginwrapper; I have one outstanding doubt, which is that the internal protocol between npwrapper.so and npviewer.bin has changed since natty, which implies there should be a versioned dependency between the i386 and amd64 parts.  Do you have an opinion on what that versioned dep should be?  Should it just be kept in version lockstep?
[19:07] <micahg> heh, glad I asked
[19:07] <Laney> got a number so that I can dupe it?
[19:07] <cjwatson> ha, adjacent bug numbers!  bug 827576 bug 827577
[19:07] <cjwatson> I guess yours wins
[19:08] <Laney> :-)
[19:08] <micahg> cjwatson: I filed a sponsored sync bug earlier, but yours is more verbose, so I duped mine to yours
[19:08] <cjwatson> micahg: I had a sponsored sync bug?
[19:08] <tumbleweed> it looks like "derivation" is the tag to use for copyPackage bugs
[19:08] <cjwatson> it is
[19:08] <cjwatson> per bigjools
[19:08] <micahg> cjwatson: a bug about supporting sponsored syncs
[19:09] <cjwatson> oh, ok
[19:09] <mdeslaur> slangasek: multiarchified? oh, you split the package in half? I'm not quite sure I comprehend
[19:10] <slangasek> mdeslaur: right; so 32-bit npviewer.bin is now in an i386 package, the 64-bit npwrapper.so is in an amd64 package, and the amd64 package depends on 'nspluginviewer' - of which there's only one in the archive, on i386, so the dep gets satisfied via multiarch
[19:10] <cjwatson> micahg: thanks, I hadn't gone through the full list, on the assumption that since I was writing the client tool I'd be encountering most of the problems for the first time :-)
[19:11] <slangasek> mdeslaur: so because they're now in two separate packages, there could be version skew unless we specify otherwise; so I'm wondering what to specify
[19:11] <mdeslaur> slangasek: oh I see...yeah, I'd go with a version lockstep
[19:11] <slangasek> ok
[19:13]  * mdeslaur hugs slangasek for killing ia32-libs
[19:13] <slangasek> trying to kill it
[19:13] <slangasek> I think I've cut through the skin ;)
[19:14] <mdeslaur> slangasek: so the ia32-libs package will be empty and will just have depends for whatever it's contents used to be?
[19:15] <seb128> slangasek, you probable want gtk3 switched to multiarch
[19:15] <seb128> having gtk2 converted is nice but that one is deprecated ;-)
[19:15] <slangasek> YokoZar: hi, speaking of killing ia32-libs, I see that there hasn't been much progress on multiarching the stuff that was recently added for wine's benefit.  Do you think you'll have time to work on that sometime soon?  I'm inclined to kill ia32-libs from the archive as soon as p opens
[19:16] <slangasek> seb128: yes, I would like that... I sighed when I saw it had been added in non-multiarch form :)
[19:16] <slangasek> though I guess the packaging dates back to maverick, so that makes sense
[19:17] <seb128> right ;-)
[19:17] <YokoZar> slangasek: I'll need to see exactly what's missing still
[19:17] <seb128> it's somewhat on my list but desktop world still has lot of things that need to be done for oneiric
[19:17] <YokoZar> slangasek: and the state of how much today's wine depends on it
[19:17] <seb128> so not sure when it will be done, it's rather low on the stack
[19:18] <slangasek> seb128: yes, and it's probably too late to change that for oneiric; best to do the conversion when p opens
[19:18] <slangasek> (it's not a blocker for ia32-libs reduction, anyway)
[19:18] <tumbleweed> cjwatson: hrm I notice debversion isn't validated, and I can file a sync request for a package that launchpad hasn't imported from debian yet
[19:21] <tumbleweed> ah bug 826850 will take care of that
[19:22] <slangasek> mdeslaur: depends for its contents> nothing nearly so gentle; since we have no way for ia32-libs to say "Depends: libcups2:i386" right now, the plan is to simply cull the contents, and users will need to be sure to upgrade to the oneiric i386 version of the package in question
[19:23] <slangasek> mdeslaur: so partial upgrades would be broken, and some local packages might be broken - users would have to track down the corresponding i386 package and install that
[19:23] <slangasek> or resolve the library deps by hand
[19:24] <mdeslaur> slangasek: I see...I'm just thinking of people downloading something like skype from their website
[19:24] <slangasek> well
[19:24] <mdeslaur> slangasek: where they have an amd64 package that pulls in ia32-libs because it actually contains i386 binaries
[19:24] <slangasek> there's a skype package in partner
[19:24] <mdeslaur> slangasek: but...meh...
[19:24] <tkamppeter> I cannot start emacs, I get
[19:24] <tkamppeter> emacs: symbol lookup error: /usr/lib/gio/modules/libgiozeitgeist.so: undefined symbol: g_desktop_app_info_launch_handler_get_type
[19:24] <mdeslaur> slangasek: yes, exactly
[19:24] <tkamppeter> Any workaround?
[19:24] <slangasek> and since they're a *partner*, perhaps we can encourage them to drop the amd64 .deb
[19:25] <slangasek> in general, I expect ISVs will be thrilled to not be providing amd64 .debs anymore :)
[19:32] <slangasek> seb128: btw, I committed a small multiarch fix to gtk+2.0 bzr; should I upload that, or wait until there's another reason to upload?
[19:33] <seb128> slangasek, if you want to upload feel free but I think doko was looking at starting a rebuilds test so maybe check with him if that's a right time to create instalability issues on some archs around gtk
[19:33] <slangasek> seb128: does gtk out-of-dateness cause uninstallability?
[19:34] <doko> well, I don't think so
[19:34] <doko> today's toolchain builds are all in the archive for amd64/i386
[19:34] <slangasek> all dependencies on libgtk2.0-common are unversioned, so it should be safe
[19:35] <seb128> slangasek, it used to, I think it got fixed though
[19:35] <seb128> slangasek, right, feel free to upload then ;-)
[19:35] <slangasek> seb128: cool, going
[19:36] <slangasek> doko: oh, another round of toolchain builds before the test rebuild?
[19:36] <doko> slangasek: they're done
[19:36] <slangasek> ok
[19:37] <slangasek> still thinking to start the test rebuild today?
[19:37] <Laney> interesting, the Debian uploader gets credited with syncs using the API
[19:37] <doko> yes
[19:39] <slangasek> cool... once there are some failure logs I can spend some time hammering on those
[20:11] <bdmurray> slangasek: I'd think so
[20:14] <jml> that is a lot of kept-back packages
[20:30] <jml> upgrade made caps lock stop being a control key :(
[20:30] <cjwatson> tumbleweed: wouldn't hurt to validate it anyway; I'll take care of that
[20:30] <cjwatson> Laney: er, they do?  I thought that was fixed
[20:31] <Laney> credited was probably a bit much, but nobody gets it on +uploaded-packages
[20:31] <ion> jml: This? https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/740214
[20:32] <cjwatson> Laney: do file a derivation bug then ...
[20:32] <Laney> did
[20:32] <cjwatson> ta
[20:33] <SpamapS> hmm.. so gdal is building without finding libxerces .. despite having --with-xerces and libxcerces-28-dev as a build-dep..
[20:33] <SpamapS> http://paste.ubuntu.com/667663/
[20:33] <jml> ion: seems right
[20:33] <SpamapS> There is the failure from config.log ...
[20:33] <jml> ion: definitely same symptoms, but so much was upgraded I couldn't swear to same cause
[20:34] <SpamapS> I notice that -lxerces-c is before conftest.cpp ...
[20:35] <SpamapS> I've seent his problem before.. but not sure how to correct it
[20:36] <SpamapS> if -lxerces-c is moved after conftest.cpp .. it works fine
[20:43] <cjwatson> SpamapS: put -l arguments in LIBS not LDFLAGS during configure
[20:44] <cjwatson> one of the standard failures with ld --as-needed
[20:44] <SpamapS> :q
[20:44] <SpamapS> Heh.. that was me :q'ing the wrong file.. to go try that. :)
[20:44] <broder> haha, i assumed you screwed up the :p smiley
[20:45] <SpamapS> double entendre, vim style
[20:45] <cjwatson> there are pkg-config options that may help IIRC
[20:45] <ion> jml: Look at the dpkg/apt log. Was keyboard-config updated?
[20:46] <SpamapS> cjwatson: so it looks like a new m4 macro is in autoconf archive that does it "right" ..
[20:46] <cjwatson> sounds plausible
[20:47] <jml> ion: yes
[20:47] <cjwatson> we're not the only distro using --as-needed after all
[20:47] <SpamapS> but they changed the name from "with-xerces" to "with-xercesc" .. hrm.
[20:47] <SpamapS>         saved_LDFLAGS="$LDFLAGS"
[20:47] <SpamapS>         LDFLAGS="$LDFLAGS $xerces_lib_flags"
[20:47] <SpamapS> so need to change that to LIBS
[20:48] <cjwatson> yes
[20:48] <cjwatson> if you're unlucky you may need to split them
[20:49] <cjwatson> I did that recently in, er, was it collectd?
[20:49] <SpamapS> yes
[20:50] <SpamapS> this one was never found as it just silently moves on w/o xerces support
[20:53] <cjwatson> nasty
[20:54] <doko> slangasek: https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+builds?build_text=&build_state=failed
[21:01] <jml> ion: heh, I also can't seem to run the keyboard preferences app either. or logout :\
[21:02]  * jml does it the old-fashioned way
[21:46] <slangasek> doko: yay :)
[21:47] <doko> slangasek: well, business as usual, we don't get any buildds :-(
[21:48] <doko> I'll rescore ~300 builds before I get to bed
[21:48] <slangasek> by hand? :/
[21:49] <doko> script
[21:49] <slangasek> ok
[21:49] <doko> currently scoring down all the uninteresting builds
[21:50] <slangasek> would really be nice to get the default queue balancing fixed
[22:40] <ScottK> barry and jtaylor: I'd say that since the author confirmed the file was Free, there's no need to worry about it being there (my comments about removing it were from before that was known (at least to me)).
[22:40] <barry> ScottK: +1
[22:41] <ScottK> dobey: I think it's clear now.  Thanks.
[22:41] <jtaylor> k then I'll add the patch to bzr with a comment?
[22:42] <ScottK> slangasek: I think moving it there for the moment is fine.  I was hoping to get feedback from fabo first though.  Maybe you can ask him?  I don't mind JFDI if he doesn't reply soon.
[22:44] <slangasek> ScottK: as long as it's just a question of where to move it or whether to drop it, it's easy enough to move it again if needed and I'm happy to do that; I'd just like to get the upload done since it blocks me taking an axe to ia32-libs ;)
[22:44] <slangasek> anyway, have pinged fabo
[22:44] <ScottK> slangasek: Let's not block axing ia32-libs.
[22:45] <RAOF> slangasek: Thinking of ia32-libs - are you able to install libgl1-mesa-glx:i386?
[22:46] <slangasek> RAOF: well, I appear to *have* it installed... I think libgl1-mesa-dri isn't coinstallable however, due to libdri2+libpciaccess
[22:46] <slangasek> due to just libpciaccess, rather
[22:46] <RAOF> slangasek: Yeah, for me it works fine once it's already installed.  But trying to install it fails.
[22:46] <slangasek> hmm!
[22:46]  * RAOF should prod #debian-x again on the libpciaccess multiarch branch.
[22:46] <cjwatson> Laney: I happened to notice that that __call__ method is used in the implementation of Archive.getSourcePackage
[22:47] <slangasek> RAOF: pastebin the failure?
[22:47] <cjwatson>                 srcpkg = self.getPublishedSources(source_name=name,
[22:47] <cjwatson>                                                   distro_series=series(),
[22:47] <cjwatson> ...
[22:47] <slangasek> oh, libpciaccess is debian-x, innit?  I should upload that then :P
[22:47] <slangasek> well, no
[22:47] <cjwatson> although that's in lpapicache itself so arguably doesn't count
[22:47] <slangasek> I should fix the xorg copyright file so KiBi doesn't stab me for playing with multiarch ;)
[22:48] <RAOF> slangasek: http://paste2.org/p/1590026
[22:48] <cjwatson> Laney: TBH it would be nice for BaseWrapper objects to automatically JSON-serialise to the right thing so that passing them directly to LP API methods just works
[22:48] <RAOF> slangasek: You're multiarching xorg?
[22:48] <slangasek> RAOF: oh, that error, argh
[22:49] <slangasek> RAOF: well, I have Debian XSF commit access, and have push most of the multiarch patches into unstable
[22:49] <slangasek> RAOF: do you have an up-to-date version of libgl1-mesa-glx installed?
[22:49] <RAOF> slangasek: Were I to guess, I'd guess that it's because libgl1-mesa-glx Provides/Conflicts/Replaces libgl1, and there's already libgl1-mesa-glx:amd64 providing that package.
[22:50] <slangasek> RAOF: IME, that error happens because apt is doing something wrong when trying to calculate how to sort out the implicit conflict between $package:i386 $ver and $package !$ver
[22:50] <RAOF> slangasek: Yes; I've got an up-to-date libgl1-mesa-glx:amd64 installed.
[22:50] <slangasek> oh, interesting
[22:51] <RAOF> slangasek: Ah. So you're not multiarching the Xserver, just all the libs and such.  Yeah.
[22:51] <slangasek> right
[22:51] <slangasek> I don't see the point in a multiarched X server
[22:51] <RAOF> Indeed.
[22:52] <ion> Can one switch an ia32 system to amd64 yet without reinstalling?
[22:52] <slangasek> ion: only if you hack yourself up a multiarch libbz2 locally :)
[22:53] <slangasek> cross-grading is not a goal for this cycle
[22:53] <cjwatson> oh, bah, multiarch libbz2 didn't just happen for us?
[22:53] <slangasek> not yet
[22:53] <ion> Multiarch libbz2 is the *only* thing missing for that?
[22:53] <slangasek> anibal has a few FTBFS bugs in unstable, I guess he's a bit inactive at the moment
[22:54] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528143 poo
[22:54] <slangasek> ion: actually, we ironically have regressed a bit this cycle because libapt-pkg has been split out into a separate package.. and isn't multiarched :D
[22:55] <slangasek> but libapt-pkg and libbz2 should be the only ones needed to switch your system's architecture view
[22:55] <slangasek> once you have apt and dpkg switched, the rest is a simple matter of calculating the upgrade path
[22:56] <cjwatson> and remember to switch the kernel first :)
[22:56] <slangasek> hah, yes
[22:56] <slangasek> well, that's easy enough, won't dpkg fail to configure itself if you don't? :)
[22:56] <barry> slangasek: tell me there's no chance that setting up multiarch as per your email can break your desktop
[22:57] <slangasek> barry: there's no chance :-)
[22:57] <barry> slangasek: okay, back to the drawing board ;)
[22:58] <slangasek> barry: slow down apt-get update and possibly cause extra warnings if you have any single-arch apt sources enabled, yes; but it shouldn't break the desktop :)
[22:58] <barry> slangasek: yeah, i really think my desktop was broken by trying to install fglrx, not by enabling multiarch
[22:59] <barry> slangasek: hopefully the desktop guys will be awake tomorrow, 'cause i'm at a dead end trying to get it working again
[23:00] <RAOF> barry: Ah, you're here!
[23:00] <slangasek> oh poo; libedit is FTBFS in the archive rebuild test, and it uses pmake, which is multiarched... which means I have to *un*multiarch libedit as part of the patch if I don't want to deal with the knock-on effects
[23:00] <slangasek> barry: what's the symptom?
[23:00] <barry> RAOF: yes!  been having system problems since i tried my little experiment
[23:00] <barry> slangasek: no dock, no ubuntu menu, no indicators
[23:00] <barry> slangasek: no app menus
[23:01] <cjwatson> tumbleweed: I've added validation for the Debian version now
[23:01] <barry> slangasek: both unity 3d and 2d are hosed
[23:01] <RAOF> barry: /var/log/Xorg.0.log... and the output of glxinfo would be the price of entry on the debugging train.
[23:01] <cjwatson> *cough* and really now
[23:32] <hallyn> jdstrand: are you around by chance?
[23:32] <hallyn> if so, since you reported it :) would you mind uploading the fix (from debdiff attached) for bug 827279 ?
[23:37] <hallyn> jbernard: ^ that bug should be present in debian and every previous release (and upstream) as well - races in cgclear
[23:38] <hallyn> jbernard: let me know if you want me to file the debian bug
[23:48] <micahg> hallyn: tab complete failure?
[23:49] <micahg> oh, maybe not...
[23:49] <micahg> hallyn: nevermind
[23:53] <hallyn> micahg: heh, surprisingly no :)
[23:53] <hallyn> jbernard: holy shnickities, near as I can tell src/api.c doesn't even pretend to parse '*' for controller, which it is supposed to :)
[23:53] <hallyn> the code just ignores that possibility
[23:53] <hallyn> bbl
[23:54] <jono> hi folks
[23:54] <jono> I just did an upgrade and my X won't start
[23:54] <jono> is anyone getting this issue?
[23:56] <jono> RAOF, are you aware of any uploads that break X?
[23:56] <jono> I tried switching to gdm and gdm could not start either as it was missing a config file
[23:56] <slangasek> barry: so, that sounds to me like the gnome-session issues I'd been seeing lately; I currently have gnome-session on hold, and assumed based on the widespread echoes I was hearing about the symptom that a bug had been filed and was probably in progress.. but I confess not to have checked.
[23:57] <slangasek> barry, jono: do you also find that in the dm menu, the session selector is empty by default?
[23:58] <jono> slangasek, I am not even a dm
[23:58] <bryceh> jono, if X won't start it typically says something as to why in a log file
[23:58] <jono> it looks like X isn't starting for me
[23:58] <slangasek> jono: oh, ok
[23:58] <jono> bryceh, I checked the syslog and dmesg
[23:58] <jono> it doesn't say anything about X
[23:58] <cjwatson> /var/log/Xorg.0.log
[23:58] <bryceh> jono, in an X log ;-)
[23:59] <jono> bryceh, which x log?
[23:59] <jono> I didnt see anything in Xorg.0.log
[23:59] <bryceh>  /var/log/Xorg.0.log* or /var/log/gdm/:0.log or /var/log/lightdm/* or /var/log/kdm/* or....