[00:55] <wcchandler> Just so I have this clear, Every time a new release is about to come about, like 11.10.  You guys take a snapshot of the current debian unstable?  And then from there you do all the magic?
[00:56] <lifeless> o
[00:56] <lifeless> no
[00:56] <lifeless> right *after* a release comes out, we grab everything in unstable
[00:57] <lifeless> then we spend 6 months fixing the result + doing the things we're trying to do that layer on top of it
[00:59] <wcchandler> Then as updates roll out on debian unstable, are they set aside until everything is polished on the snapshot and then slowly added when they reach the same level as everything else?  Are they added after an initial release (i.e. Alpha, Beta?)  Or are they never touched until the release officially comes out?
[01:01] <lifeless> we start with everything coming across and then as we get closer to release gradually turn the pipe off
[01:01] <lifeless> first from automatic to manual, then manual to needing approval, and finally no updates at all
[01:03]  * wcchandler gets to the section on seeds, germinate and bazaar  :$
[01:13] <wcchandler> On this page: https://wiki.ubuntu.com/SeedManagement under Supported there are two links "Arch" and "Soyuz" that do not link to an actual page.
[01:19] <lifeless> oh wow
[01:19] <lifeless> thats -very- old
[01:19] <wcchandler> :(  please tell me it's still relavent?
[01:19] <wcchandler> And I noticed most of the links pointed to Gutsy...  I just assumed as an example?
[01:20] <lifeless> no, thats when they were written
[01:21] <wcchandler> Is this page still relevant: https://wiki.ubuntu.com/UbuntuArchitecture
[01:22] <lifeless> last edited 2010-06-06
[01:22] <lifeless> so yes, I think so
[06:22] <cjwatson> broder: oh well
[06:22] <cjwatson> andersk: thanks, merging
[06:38] <alkisg> Will there a linux-image-generic-lts-backport-natty package become available in lucid-updates? Now only -maverick is there... http://packages.ubuntu.com/search?keywords=linux-image-generic-lts-backport
[08:03] <highvoltage> akgraner: hi! do you happen to be close to kazincsky? would like to talk about UWN
[08:14] <ohsix> hm can the card types available to a card reader generally be read from the device? one of my pet peeves is rolling a udev rule to set the types for the ui & it'd be cool to write a helper for it
[08:40] <smoser> someone able to help me with http://uec-images.ubuntu.com/server/oneiric/20110510/log.stdout.stderr
[08:41] <smoser> The following packages have unmet dependencies:
[08:41] <smoser>  libhttp-daemon-perl : Breaks: libwww-perl (< 6.00) but 5.837-1 is to be installed
[08:41] <smoser>  libhttp-date-perl : Breaks: libwww-perl (< 6.00) but 5.837-1 is to be installed
[08:41] <broder> there's a massive perl transition happening
[08:41] <broder> i'd try again in a few days
[08:41] <smoser> well its been broken for over a week
[08:41] <broder> massive>
[08:41] <smoser> but, fair enough
[08:43] <slangasek> smoser: yes, it's a deep transition
[08:43] <Laney> if it rebuilds you can reupload it
[08:43] <slangasek> and progress is slow during UDS of course
[08:43] <Laney> that looks like a new package this cycle, so the transition monitor may be missing it ...
[08:44] <micahg> looks like a dependency loop
[08:44] <micahg> *circular dependency
[08:51] <ogra_> cjwatson, ping
[08:51] <ogra_> cjwatson, https://blueprints.launchpad.net/ubuntu/+spec/other-o-arm-preventing-archive-skew might intrest you
[10:14] <cjwatson> smoser: I'll look and sort it out
[10:14] <cjwatson> ogra_: sure, when's it scheduled?
[10:17] <smoser> cjwatson, regarding pv-grub2, would it be useful to you if you had access to xen at this point?
[10:18] <smoser> i can probably get you access to something.
[10:19] <cjwatson> smoser: hm, I think on the whole I probably just need to sort it out on my laptop or something
[10:19] <cjwatson> but hold that in reserve :)
[10:19] <cjwatson> smoser: libwww-perl> actually, can I make this your problem again?  the problem is that several MIRs need to be written for the new libwww-perl
[10:20] <cjwatson> smoser: you can find them by looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt and searching for libwww-perl
[10:21] <cjwatson> smoser: you might need to search recursively to make sure you've got them all
[10:21] <smoser> cjwatson, so you're asking me to do some MIRs?
[10:21] <smoser> pff... i can [reluctantly] do that.
[10:21] <cjwatson> yup, if you could :)
[10:21] <cjwatson> well, somebody who cares needs to own MIRs, generally
[10:21] <cjwatson> and you seem to care :)
[10:22] <smoser> yeah, no probably. i understand.
[10:22] <smoser> thanks cjwatson
[10:22] <cjwatson> if it still fails to build after all that, I'm happy to attempt to sort it out from a perl-transition point of view
[10:22] <cjwatson> but this doesn't look like intrinsically part of the perl 5.12 transition - it's just new deps from an autosync
[10:24] <Chipzz> hrrrrm, I see libwww-perl has several -perl reverese build-deps.. but is that actually needed (as opposed to reverse deps)?
[10:24] <Chipzz> does parrot byte code get compiled at build time?
[10:24] <cjwatson> I expect that it needs them to run its test suite
[10:25] <cjwatson> parrot> irrelevant
[10:25] <Chipzz> ah k tests make sense
[10:53] <lifeless> slangasek: if you need a concordence of all the paths in the archives, the conflict checker sqlite db has that
[10:53] <lifeless> slangasek: I don't know if thats less work.
[10:54] <lifeless> slangasek: but I'm sure it would be less than unpacking everything. :P
[10:54]  * lifeless is gone
[10:56] <slangasek> lifeless: ta, notated
[10:56] <cjwatson> I also mentioned ravel.debian.org:~cjwatson/docscanner/
[10:59] <ogra_> cjwatson, i think it is about to be scheduled, it was only created yesterday afaik ... NCommander works on getting it on the schedule atm
[11:01] <NCommander> ogra_: ok, i just poked robbie on that spec to get scheluded
[11:02] <ogra_> NCommander, make sure colin is subscribed so we dont cause conflicts ;)
[11:02] <NCommander> ogra_: k
[11:10] <tbf> appmenu for gtk3 apps - someone having time to review that minor patch and merge it? https://code.launchpad.net/~hasselmm/appmenu-gtk/gtk3/+merge/60326
[11:10] <tbf> also have the required packaging changes in my ppa
[11:11] <tbf> fixes this bug: https://bugs.launchpad.net/appmenu-gtk/+bug/701295
[11:22] <dpm> pitti, if you've got a minute during UDS, may I ask you to copy the PPA langpacks to natty-proposed, and then I'll do a call for testing?
[11:35] <Q-FUNK> cjwatson: are you still on the perl transition?
[11:38] <cjwatson> Q-FUNK: yes
[11:38] <Q-FUNK> cjwatson:  these seem to be giving me problems: libany-moose-perl libgnupg-interface-perl libmouse-perl
[11:39] <cjwatson> yes
[11:39] <cjwatson> I'm working on them
[11:39] <cjwatson> that lot will be fixed later today
[11:39] <Q-FUNK> cjwatson: ah, ok. thanks!  I was trying myself at libmouse-perl, but the builder barfed on the perl version installed
[11:40] <cjwatson> libmoose-perl was blocked on a newer libpackage-stash-perl, which is now rebuilt
[11:41] <Q-FUNK> ah, that would explain it.
[11:41] <cjwatson> so should be retriable shortly
[11:49] <cjwatson> Q-FUNK: libmoose-perl retried, and a while after that I'll be able to do the bits of the stack that depend on that
[11:49] <cjwatson> Q-FUNK: you can rest assured I am very actively tracking all this, anyway :)
[11:53] <Q-FUNK> cjwatson: cheers! :)
[12:44] <bigon> https://bugs.launchpad.net/ubuntu/+source/cdbs/+bug/745828 could somebody have a look at this
[12:44] <bigon> ?
[13:05] <geser> bigon: have you checked where the difference is? does Debian's dh_python2 support this option or does Debian cdbs' call it without that option?
[13:05] <tumbleweed> geser: no debian doesn't support it (that I know of) looks bug-ish
[13:07] <bigon> debian cdbs doesn't include this --prefix thinh
[13:07] <bigon> thing
[13:08] <tumbleweed> oh, duh
[13:08] <tumbleweed> +    - 1/class/python-distutils.mk.in, 1/class/python-module.mk.in: Add
[13:08] <tumbleweed> +      --prefix support for pysupport by DEB_PYTHON_PREFIX_ARG (LP #625581)
[13:21] <geser> the test suite for this change forgot to check if other python packaging systems didn't break with this change (it only checks if pysupport works)
[13:28] <tumbleweed> the equivalent of --prefix in dh_python2 is just to specify the full path to the private directory. Don't know why they didn't use dh_python2 for this in the first place...
[14:19] <micahg> I just saw bug 780479, but don't have an answer for it, I'm guessing this was space related?
[15:01] <real_ate_> hi guys! quick question ... our company had to patch a deb package that comes with ubuntu and want to keep an eye on when that package updates so that we can reapply our patch
[15:02] <real_ate_> is there any sort of automated mailing list that can notify you of a change of a particular package in ubuntu?
[15:02] <micahg> real_ate_: lists.ubuntu.com, there should be a $RELEASE-changes list
[15:02] <real_ate_> i.e. when libxyz is updated you get an email with a subject "Package libxyz has been updated" etc ....
[15:02] <micahg> real_ate_: also, if it's appropriate for others as well, you could try to get it into Ubuntu and/or upstream
[15:03] <micahg> real_ate_: no, the list shows almost all changes to the release except for mass auto-sync from Debian
[15:03] <micahg> real_ate_: but that doesn't happen in a stable release anyways
[15:04] <real_ate_> micahg: its not realy apropriate... it for LTS and it is choosing to configure with libxml for axis2c because of a bug in the built in xml parser... too big of a change for a SUR (or whatever the achronym is )
[15:04] <micahg> real_ate_: ok, you could get the fix in for the next LTS though if appropriate :)
[15:05] <Chipzz> real_ate_: you could install apticron; that will send out a mail whenever new packages are available
[15:05] <cjwatson> real_ate_: you can also subscribe to the 'derivatives' keyword for a package on packages.qa.debian.org - IIRC that gets all Ubuntu uploads
[15:06] <cjwatson> (I don't recall how much else it gets though)
[15:06] <Chipzz> real_ate_: if you pipe the mail through a script you could grep for the package name
[15:06] <Chipzz> (I'm doing sth similar, but not for watching a specific package; I rather put all available updates in a db)
[15:06] <real_ate_> Chipzz: cool i will have to look into this
[15:07] <micahg> you could filter by subject if you have the changes list set to individual mails as well
[15:09] <Chipzz> real_ate_:
[15:09] <Chipzz> # grep apticron /etc/aliases
[15:09] <Chipzz> apticron: |/usr/local/bin/wf-apticron-parse
[15:09] <Chipzz> that's with postfix
[15:09] <Chipzz> don't even have to install procmail or anything
[15:10] <real_ate_> Chipzz: i will have to look into that solution but for now i will go with the list... it means that we can have a single setup not dependant on a particular machine being up
[15:10]  * real_ate_ is working on a cloud system
[15:16] <real_ate> thanks for all your help
[15:45] <saimanoj> hi
[15:52] <smoser> cjwatson, http://paste.ubuntu.com/605732/
[15:52] <smoser> that includes the majority of the new perl libraries that we'll need.
[16:24] <Laney> which package creates sources.list?
[16:24] <Laney> ubiquity, debootstrap, …?
[16:25] <broder> Laney: not debootstrap. i think it would be one of the d-i components that ubiquity pulls in
[16:26] <Laney> broder: debootstrap does, otherwise how do chroots get their sources.list?
[16:26] <Laney> debootstrap/functions:879
[16:26] <broder> yeah, but that's a dummy that's not actually used by anything
[16:27] <Laney> apt in a chroot?
[16:35] <maxb> Laney: apt-setup udeb?
[16:36] <Laney> maxb: yeah, looks good. Does that affect both d-i and ubiquity installs?
[16:37] <maxb> Uh. Unsure. I only every use d-i
[16:37] <maxb> *ever
[16:38] <tumbleweed> didrocks: I see you broke cdbs :) I was just about to start looking at it
[16:39] <didrocks> tumbleweed: hum, really? I didn't touch it for month
[16:39] <tumbleweed> maybe it was a merge after it. bug 745828
[16:40] <didrocks> tumbleweed: yeah, seems an incorrect merge from someone then
[16:40] <didrocks> I think I ignored dh_python on purpose
[16:40] <seb128> iz pitti fault
[16:41] <tumbleweed> I didn't see anything that checked fro dh_python2, but I wa sreading the patch during a session...
[16:41] <broder> Laney: ubiquity takes snapshots of a bunch of udebs and then uses them. apt-setup appears to be one of those
[16:41] <Laney> good
[16:41] <Laney> :-)
[16:44] <didrocks> seb128: always pitti ;)
[16:52] <Laney> http://paste.ubuntu.com/605754/ is this enough?
[16:53] <Laney> cjwatson: ^
[16:53] <Laney> (sorry, you weren't in the session — we decided to have this enabled in the default sources.list now that NotAutomatic should make apt DTRT)
[16:56] <cjwatson> Laney: I think so, could you please post a merge proposal against lp:~ubuntu-core-dev/apt-setup/ubuntu though?
[16:56] <Laney> cjwatson: yes, I am doing. Didn't want to post a wrong diff.
[16:59] <cjwatson> smoser: all promoted, thanks
[17:11] <broder> ScottK: does the backports process currently use the triaged bug state? it seems like that would be good for "someone has looked at this and determined someone needs to do testing" if not
[17:12] <ScottK> broder: Not everyone can set Triaged.
[17:12] <broder> oh, hmph. well...can *i* start using it for that? :-P
[17:13] <ScottK> Currently "Confirmed" means ready for ubuntu-backporters review.  It seems a bit backwards to use Triaged for needs testing.
[17:16] <hallyn> regarding bug 780479 - hardy is still support on servers iiuc, so shouldn't ddebs.ubuntu.com still show hardy?
[17:19] <hallyn> pitti: ^
[17:20] <hallyn> (just bc i see you posting in the past about ddebs :)
[17:23] <hallyn> (nm, i suppose -dbg should work)
[18:03] <saimanoj> hello.
[19:26] <jhunt_> Hi Scott - got time for a gtalk chat?
[19:47] <lamont> ScottK: postfix 2.8.3-1 uploaded to debian, you wanna do the no-changes-needed sync sometime?
[23:23] <hallyn> if a particular library's makefile wants to install into /usr/lib64, is the right thing to do to force those into /usr/lib?
[23:23] <hallyn> (for the debian package)
[23:24] <hallyn> I can't *just* put it into /usr/lib64, bc then a package using it ends up using /usr/lib/libfoo, and then I get dpkg-shlibdeps: error: no dependency information found for /usr/lib/libfoo
[23:28] <infinity> hallyn: It should be in /usr/lib, yes.
[23:29] <hallyn> infinity: ok, thanks
[23:30] <hallyn> is that to be found in the debian guide?
[23:31] <hallyn> (probably;  reading)
[23:33] <infinity> hallyn: Perhaps somewhere in some library packaging guide or some such.  It's been a long time since I've paid attention to what lives in which policy.
[23:34] <infinity> hallyn: But, basically, our 64-bit architectures are treated as "first-class citizens" and given the same file layout as 32-bit arches.  Which puts us (Debian and Ubuntu) at odds with LSB and most other distributions.  With any luck, multiarch will gain widespread adoption and no one will care anymore. :P
[23:36] <hallyn> i'll need to read up more on multiarch
[23:36] <hallyn> didn't pay enough attention to theannounce