=== wedgwood is now known as wedgwood_away
=== jbicha is now known as Guest32183
=== Guest32183 is now known as jbicha_
[02:02] <arges> smoser: I didn't see qemu-kvm in http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/ when I checked
=== jbicha_ is now known as jbicha
=== negronjl` is now known as negronjl
[03:04] <infinity> doko_: Fixed binutils uploaded (for libiberty, and restoring the lost changes from vorlon and pitti), so you don't have to worry about it.
=== jbicha is now known as Guest48606
=== Guest48606 is now known as jbicha_
[05:17] <OdyX> tkamppeter_: I'll prepare a 1.7 branch for you today and keep you posted.
[06:27] <dholbach> good morning
[06:35] <pitti> Good morning
[06:35] <pitti> infinity: cheers
[06:44] <Noskcaj> jbicha__, ping
=== tkamppeter_ is now known as tkamppeter
[07:00] <tkamppeter> OdyX, OK.
[07:22] <tvoss> didrocks, ping
[07:23] <didrocks> tvoss: pong
=== oSoMoN_ is now known as oSoMoN
=== oSoMoN is now known as oSoMoN|afk
=== ckpringle_ is now known as ckpringle
=== gusch_ is now known as gusch
=== Nigel_ is now known as G
[10:07] <sil2100> Wellark: ping
=== doko_ is now known as doko
[10:40] <zyga> pitti: ping
[10:40] <pitti> zyga: pong
[10:41] <zyga> pitti: my google foo and memory are failing me, could you please point me to some place that explains the changes to dbus session bus, I recall reading that some kind of new bus type is coming (user bus?)
[10:41] <pitti> zyga: that hasn't landed yet; I'm not sure when that's being planned upstream (or whether it's systemd specific)
[10:41] <pitti> maybe it also got obsoleted with logind, I'm not sure; in any way it's been a long time since I've heard about it
=== oSoMoN|afk is now known as oSoMoN
[10:42]  * pitti asks desrt
[10:42] <zyga> pitti: so it's not something super defined yet, ok
[10:42] <zyga> thank you
[10:43] <pitti> zyga: I asked Ryan, but probably he's asleep
[11:09] <didrocks> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
[11:09]  * dholbach hugs didrocks
[11:10]  * didrocks hugs dholbach back, couldn't do my shift the other day with unity7/touch apps and so on :)
[11:10] <dholbach> no worries :)
[11:14] <infinity> doko: Does the binutils shlibs need to be so painfully restrictive?  We're going to have to reupload every kernel that builds a tools package for every new binutils snapshot...
[11:14] <doko> infinity, there is no abi
=== MacSlow is now known as MacSlow|lunch
[11:15] <doko> sometimes even if I keep it, and add a patch, it doesn't build anymore. maybe you do remember ...
[11:15] <infinity> doko: Yeah, I get that.  I guess this is something we get to suffer with if we use snapshots.  I hope you don't plan to upload a bunch of them before 2.24
[11:16] <infinity> Not that I mind a bunch of mini-transitions, it's just a bunch of mini-transitions involving rebuilding a bunch of kernels could get annoying. :)
[11:17] <doko> too late, just uploaded. but yes, trying to keep this soversion as stable as possible
[11:17] <pitti> infinity, doko: any chance that the "Depends: build-essential" fix can get committed to Debian as well, to avoid losing it again? (also, it's necessary for Debian, too)
[11:17] <doko> so why did the kernel needs this?
[11:17] <doko> I thought that was just for libiberty?
[11:17] <infinity> doko: "too late, just uploaded", as in you uploadd a new snapshot again? :/
[11:18] <doko> yes
[11:18] <doko> pitti, debian binutils never had the autopkg tests
[11:18] <pitti> doko: ah, ok; I thought it was a victim of merging; so, nevermind
[11:19] <infinity> doko: britney claims that linux and linux-grouper, at least, depend on binutils.  I'd have to look at why.  My assumption would have been libbfd.
[11:20] <doko> is this gperf?
[11:21] <infinity> (saucy-amd64)root@cthulhu:~# ldd /usr/bin/perf_3.9.0-5 | grep bfd
[11:21] <infinity> 	libbfd-2.23.52-system.20130611.so => /usr/lib/libbfd-2.23.52-system.20130611.so (0x00007fbaa6cea000)
[11:24] <infinity> doko: Oh, bah.  This is a direct result of the libiberty-gone-missing oops.
[11:25] <infinity> doko: I'll get it fixed up with the kernel team.
[11:25] <infinity> doko: perf only needs bfd in the alternate linkage case rtg forced because iberty was gone.
[11:26] <seb128> infinity, just curious, what's the status of the unity SRU for raring?
[11:26] <doko> infinity, I asked wookey to build a libiberty-dev package from a separate source
[11:29] <infinity> seb128: I was waiting for someone to figure out how to upload a package with a fixed changelog, but I've given up on that.  I'll re-review today, and reject the one(s) I don't like.
[11:29] <seb128> infinity, thanks
[11:31] <doko> infinity, there is still libiberty_pic.a
[11:32] <didrocks> infinity: AFAIK, Mirv is preparing/have a bamf with a fixed changelog (it's the only one I know about)
[11:33] <infinity> doko: Well, there's both now.
[11:34] <Mirv> didrocks: I put it into the google doc, https://launchpad.net/~unity-team/+archive/sru/+files/bamf_0.4.0daily13.05.31%7E13.04-0ubuntu2%7Etest1.dsc
[11:34] <didrocks> Mirv: ah, good! so infinity: bamf fix on the way :)
[11:34] <didrocks> (in this patch pilot shift)
[11:34] <Mirv> so it could be uploaded, although I'm not sure with which version since the ubuntu1 sync request is in the queue
[11:35] <didrocks> Mirv: reuse the same version, I'm going to reject the one in the queue
[11:35]  * soren realises that pxe-kexec can be used to trigger d-i in the cloud and falls out of his chair
[11:35] <Mirv> didrocks: ok, well take that ubuntu2~test1 and upload as ubuntu1 instead.. since it's a dget from a superseded daily-build PPA content, I don't have any bzr or such anyhow
[11:35] <didrocks> Mirv: ok, will do!
[11:35]  * infinity gets soren a seatbelt for his extreme computing.
[11:35] <Mirv> thanks
[11:36] <didrocks> thanks to you :)
[11:43] <stokachu> whats the best way to get a BuildID from a kernel image?
[11:46] <stokachu> for example i can get it from a binary with file
[11:46] <stokachu> /bin/zsh4: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x336c8162902093067f2186b7e6ac233b74d7ce77, stripped
[11:50] <stokachu> if i do a eu-readelf there is a section in .notes about a GNU_BUILD_ID though not sure if that is the same thing
[11:52] <cjwatson> stokachu: use scripts/extract-vmlinux from the kernel source tree to extract the uncompressed vmlinux (scripts/extract-vmlinux /path/to/vmlinuz >vmlinux)
[11:52] <stokachu> cjwatson: ah nice ill check that out
[11:53] <cjwatson> It doesn't have a .note.gnu.build-id section though; I wonder where file gets it from
[11:54] <stokachu> cjwatson: should i use the eu-readelf instead?
[11:54] <stokachu> there is a build id in the .notes section but nothing about .note.gnu.build-id like the others
[11:55] <infinity> I'm vaguely confused by file's output there anyway...
[11:56] <infinity> (base)adconrad@cthulhu:~$ file /bin/mv
[11:56] <infinity> /bin/mv: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xe438743eb3051f02aff0dd6e051e7ad7d035c286, stripped
[11:56] <infinity> (base)adconrad@cthulhu:~$ readelf -a /bin/mv | grep Build
[11:56] <infinity>     Build ID: 3e7438e4021f05b36eddf0afd77a1e0586c235d0
[11:56] <stokachu> exactly!
[11:56] <cjwatson> well, just readelf would do
[11:57] <stokachu> i think ill stick to readelfs build id
[11:57] <stokachu> eu-readelf -n /boot/vmlinuz-3.2.0-45-generic
[11:57] <stokachu> that gives me a build id
[11:57] <cjwatson> like I say, readelf will do and is more widely installed
[11:58] <stokachu> sounds good to me
[11:58] <cjwatson> the build IDs printed by readelf and file are the same, just byte-swapped
[11:58] <stokachu> ok
[11:58] <cjwatson> (flip four-byte chunks, you'll get the same answer)
[12:08] <didrocks> pitti: mind marking https://code.launchpad.net/~darkxst/ubuntu/raring/gnome-shell/lp1064584/+merge/165828 as merged?
=== MacSlow|lunch is now known as MacSlow
[12:25] <OdyX> tkamppeter: pushed the master-experimental branch to cups.git, feel free to push nicely isolated commits on there; no need to include paths for all commits, remember ;) .
[12:25] <OdyX> tkamppeter: beware, the master-experimental branch is based off master, which has the staged changes for jessie/unstable.
[12:45] <pitti> didrocks: done
[12:45] <didrocks> pitti: thanks :)
=== _salem is now known as salem_
[13:03] <pitti> where would I file a bug against the kernel that is running on the phablet image? the chroot doesn't have a kernel package
[13:03] <pitti> 3.1.10-3-grouper
[13:03] <ogra_> pitti, linux-grouper for nx7, linux-maguro for galaxy nexus, manta for n4 and mako for n10
[13:04] <ogra_> they are all in the archive
[13:04] <pitti> https://launchpad.net/ubuntu/+source/linux-grouper/+bugs
[13:04] <pitti> "no open bugs"
[13:04] <pitti> wow :)
[13:04]  * pitti is going to add the first one then
[13:04] <ogra_> well, its pretty new
[13:05] <pitti> I stumbled over a reboot command without any confirmation or security checks :)
[13:05] <pitti> cat /sys/devices/platform/tegra-i2c.4/i2c-4/4-006a/reg_status
[13:05] <pitti> (as user)
[13:05] <ogra_> note that HW bugs you might experience can be android bugs ... :)
[13:06] <ogra_> ah, well, sysfs cat reboot sounds actually like kernel, yeah
[13:07] <pitti> filed, thanks
=== tgall_foo is now known as Dr_Who
[13:48] <RoyK> hi all. any clue about bug 1189567?
[13:48] <ubottu> bug 1189567 in xfsprogs (Ubuntu) "xfs_repair fails to repair filesystem" [Undecided,New] https://launchpad.net/bugs/1189567
=== wedgwood_away is now known as wedgwood
[13:56] <roadmr> hello folks! I used to be able to rsync rsync://old-releases.ubuntu.com/old-releases/ but as of this morning I can't (@ERROR: Unknown module 'old-releases'). Does anybody know what changed, or who should I ask about this?
[13:58] <Laney> roadmr: IS might be a good first port of call
[13:58] <roadmr> Laney: thanks, I'll ask over there
[14:04] <xnox> smoser: did you get a chance to test cloud-init in saucy with updated upstart? are there saucy daily or weekly cloud-init images available somewhere for me to try?
[14:10] <didrocks>  pitti: and to be marked as merged: https://code.launchpad.net/~timo-jyrinki/ubuntu/precise/compiz-plugins-main/fix_755842/+merge/162934 that will be the last for today, I can handle the other ones :)
[14:10] <pitti> didrocks: done
[14:15] <didrocks> thanks :)
[14:38] <didrocks> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[14:48] <smoser> xnox, still around ?
[14:48] <xnox> smoser: yeap.
[14:49] <smoser> we had issues yesterday.. it seems that the upgrade isn't working as i had desired.
[14:49] <smoser> did you see that info ?
[14:49] <xnox> smoser: no, i didn't see that. Where, what?
[14:50] <smoser> http://irclogs.ubuntu.com/2013/06/11/%23ubuntu-devel.html#t19:10
[14:50] <smoser> it seems to me that the problem is that during the upgrade, upstart thought it *was* at runlevel 2.
[14:50] <smoser> as i understood it, the idea was to only restart upstart if runlevel 2 had been reached (or suitable older version found)
[14:52] <xnox> smoser: correct, so it must have been at runlevel 2 already. It performed stateful re-exec, and rightfully did not preserve "pending" / "blocked" events if old upstart was still running as pid 1.
[14:53] <xnox> smoser: is there a way for me to execute cloud-init image in an lxc container with upgrade to see how it behaves and what's wrong?
[14:54] <smoser> probably.
[14:54] <stgraber> xnox: yes, that's how I've been doing testing of those
[14:54] <xnox> smoser: do cloud-init jobs actually block runlevel 2 event? reaching runlevel 2?
[14:54] <smoser> you can probably recreate with 'lxc-create -t ubuntu-cloud'
[14:54] <xnox> right, ack.
[14:54] <smoser> xnox, they dont' block runlevel 2
[14:54] <smoser> that is what i noticed.
[14:54] <xnox> hm. but I need to use some old image.
[14:55] <xnox> smoser: =(((((( we assumed that cloud-init does all of it's stuff before runlevel 2 is emitted.
[14:55] <xnox> well reached.
[14:55] <smoser> $*%#ing parallelism !
[14:55] <smoser> rc-sysinit.conf is : start on (filesystem and static-network-up) or failsafe-boot
[14:56] <smoser> and cloud-config.conf is: start on (filesystem and started rsyslog)
[14:56] <stgraber> xnox: IIRC what I did was create a new cloud container (lxc-create -t ubuntu-cloud -n p1 -- -r raring), then chroot into the container, downgrade some stuff, then make sure /var/lib/cloud is empty except for /var/lib/cloud/seed, then start the container.
[14:57] <stgraber> xnox: oh, and you need a userdata file (or whatever it's called) to set the update flag, otherwise cloud-utils won't apply updates at boot time
[14:57] <smoser> right.
[14:57] <smoser> but basically, nothing is going to stop rc-sysinit from running.
[14:58] <smoser> i'm not sure if its a bug or not that rc possibly runs parallel to cloud-config.conf. its not ever been a problem itself.
[14:58] <stgraber> xnox: unfortunately I didn't really take much notes about this, I mostly did that based on directions from jibel and smoser and removed the container from my machine a week ago (otherwise I'd just have given you a compressed version of it)
[14:59] <xnox> smoser: so which of the jobs runs dist-upgrade, cause that's the one that should be either running after everything else cloud-initish is done? or it should run whilest runlevel 2 has not been reached.
[14:59] <smoser> xnox, kvm recreate is at https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1103881
[14:59] <ubottu> Launchpad bug 1124384 in cloud-init (Ubuntu Saucy) "duplicate for #1103881 Configuration reload clears event that others jobs may be waiting on" [High,Confirmed]
[14:59] <xnox> smoser: k, thanks.
[14:59] <smoser> you cnan just download a few-day-old saucy
[15:00] <smoser> xnox, i'm not sure how to do this well.
[15:01] <smoser> well... one way (possibly hackish)
[15:01] <smoser> is to say "if cloud-config is running, do not upgrade"
[15:01] <smoser> er... do not re-exec
[15:01] <smoser> that'd solve this specific problem
[15:01] <xnox> smoser: http://cloud-images.ubuntu.com/saucy/ only has back to 20130609.
[15:02] <smoser> xnox, that has upstart 1.8-0ubuntu4
[15:02] <smoser> is that not old enough ? otherwise you'll have to downgrade
[15:02] <smoser> i can show you how i'd do that if you needed.
[15:02] <xnox> smoser: nah, that has full serialisation already.
[15:03] <xnox> smoser: must downgrade. or start raring container and dist-upgrade =)))))
[15:03] <smoser> yeah. so you should be able to reproduce this in lxc or in kvm. but either way will require you to downgrade.
[15:03] <smoser> i use: http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/revision/15#mount-callback-umount
[15:03] <smoser> to "mount - run some code - umount" of a qcow image.
[15:04] <smoser> better link: http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/mount-callback-umount
=== Sweetsha1k is now known as Sweeshark
[15:12] <xnox> k, thanks. I'll try that and get back with better fix.
=== mzanetti is now known as mzanetti|food
[15:26] <hallyn> infinity: would you mind kicking the libcgroup precise-proposed upload for version 0.37.1-1ubuntu11 ?
[15:26]  * hallyn lost the version number choosing game again
[15:27] <infinity> hallyn: "kicking" as in rejecting from the queue?
[15:27] <hallyn> infinity: yes
[15:27] <infinity> hallyn: Done.
[15:27] <hallyn> infinity: thanks
=== mzanetti|food is now known as mzanetti
=== mmrazik is now known as mmrazik|afk
[15:59] <tvoss> cjwatson, ping
[15:59] <cjwatson> tvoss: hi
[15:59] <tvoss> cjwatson, can you join us on https://plus.google.com/hangouts/_/a0a4f88494fc4074198be533bd959ae80e43303a
[15:59] <cjwatson> tvoss: what's the topic?
[16:00] <tvoss> cjohnston, an app centric world
[16:00] <cjwatson> um, ok, that sounds like marketing ... ;-)
[16:01] <Laney> O_O
=== jbicha is now known as Guest15484
=== Guest15484 is now known as jbicha_
=== james_ is now known as Guest33807
[16:36] <cjwatson> stgraber,xnox: is there anything preventing us cherry-picking the apparmor patches to upstart into saucy?
[16:37] <xnox> cjwatson: well it was aimed to be part of upstart 1.9 release for saucy once jodh comes back.
[16:38] <xnox> cjwatson: it could be uploaded to saucy soonish. But I was hoping to fully resolve "full-serialisation & cloud-init bug" in saucy & SRU into raring first.
[16:38] <cjwatson> hm, ok
[16:38] <cjwatson> jdstrand: ^-
=== ckpringle_ is now known as ckpringle
[16:38] <cjwatson> the serialisation thing is indeed best to sort out before the next upload
[16:38] <xnox> (if i will have luck with lxc/cloud-init containers tomorrow, and sru goes through quickly, we can look into getting apparmor into saucy friday going on next week)
[16:45] <jdstrand> waiting til jodh comes back is ok with me
[16:45] <jdstrand> we can work with ppas/etc in the meantime
[16:46] <cjwatson> ok
[16:49] <slangasek> jdstrand: in that case, you can probably take the upstart upstream daily-build ppa?
[16:49] <jdstrand> slangasek: does that have armhf enabled?
[16:49] <slangasek> I believe so
[16:49] <jdstrand> slangasek: thanks, I'll look into it
[16:49] <slangasek> https://launchpad.net/~upstart-devel/+archive/upstart-daily-build
[16:50] <slangasek> hmmm nope, not that one
[16:50] <slangasek> at least, there's no armhf there
[16:50] <jdstrand> and no saucy
[16:50] <jdstrand> np
[16:51] <slangasek> jdstrand: ah, here we go. https://launchpad.net/~canonical-foundations/+archive/upstart-daily
[16:52] <jdstrand> slangasek: nice. would you be able to enable saucy build there too?
[16:52] <slangasek> jdstrand: it seems to be built for raring, but it's still the right code and should be installable on saucy.  Moving it to build for saucy means changing the recipe build, I guess
[16:52] <slangasek> I'm not sure I know where that lives
[16:52] <jdstrand> I thought it was just a checkbox
[16:53] <slangasek> stgraber: ^^ do you know where the upstart daily recipe build is?
[16:53] <jdstrand> let me see if I can conjure up a url
[16:54] <stgraber> slangasek: https://code.launchpad.net/~canonical-foundations/+recipe/upstart-daily-nonvirt
[16:54]  * jdstrand was >< close to giving that :)
[16:55] <jdstrand> slangasek: under Distribution series, you should have a way to enable saucy and any other releases you want
[16:55] <slangasek> hmmm, so it's under code.launchpad.net, but is not a branch, ok
[16:55] <slangasek> changed to saucy going forward
[16:56] <slangasek> stgraber: does this recipe pull in the Ubuntu packaging delta?
[16:56] <slangasek> ah, it does
[16:56] <stgraber> slangasek: right, the recipe is owned by ~canonical-foundations but we're using the ~upstart-dev branch as the source. We had to move the recipe to ~canonical-foundations so it could use the non-virt PPA
[16:56] <slangasek> but it uses the raring packaging :)
[16:56]  * slangasek moves this to lp:ubuntu/upstart
[16:57] <stgraber> slangasek: I'm pretty sure I had that set to lp:ubuntu/upstart back in raring, I suspect LP is very good at changing all references when we create the new series and so we'll have to keep on updating it every time a new series open
[16:58] <slangasek> ah, fiddlesticks
[16:58] <slangasek> ok
=== TheLordO- is now known as TheLordOfTime|EC
=== TheLordOfTime|EC is now known as LordOfTime|EC2
[17:56] <geser> does somebody know if/when we get apache 2.4 into saucy? there is a bunch of packages waiting on dh-apache2 from apache2-dev
[17:57] <mterry> @pilot on
[17:57] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[17:57] <mterry> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
[17:57] <cjwatson> It was waiting for the libgd2/net-snmp transition to clear, but that's done now.  However, I'd request that if you're doing this you try to work out *first* whether enough of the transition is done in Debian that we could clear it through -proposed in Ubuntu within a week or so
[17:57] <cjwatson> Otherwise it gets even harder to land changes
[17:58] <cjwatson> Some of these transitions are started in Debian and then not pursued as aggressively as would be ideal (I had to fix a fair bit of libgd2 myself)
[17:59] <RoyK> bug 1189567 seems to be easy to fix - anyone into xfs here?
[17:59] <ubottu> bug 1189567 in xfsprogs (Ubuntu) "xfs_repair fails to repair filesystem" [Undecided,New] https://launchpad.net/bugs/1189567
[18:01] <geser> considering that there is RC-bug on apache2 to prevent it from migrating to testing, it seems more modules need to transition first before it gets cleared
[18:03] <geser> lets hope it gets done soon before we (the ubuntu release team?) decides to stay with 2.2 and we need a solution for those build-depending packages on dh-apache2
[18:12] <infinity> geser: Feature Freeze is a looong way out, I think we'll be alright holding off a little bit.
[18:12] <ogra_> heh, feature freeze
[18:13] <geser> infinity: yeah, just noticed it too, that FF is end of August
[18:13] <cjwatson> geser: well, *a* solution is to leave them in -proposed
[18:14] <cjwatson> obviously not necessarily ideal if we need to change them
[18:17] <geser> would it be possible to SRU a package if a newer version it stuck in -proposed till after release?
[18:17] <cjwatson> Well, we'd move it to <next>-proposed after release
[18:17] <infinity> geser: We'd remove it from -proposed if it never migrated (as we did last release)
[18:17] <infinity> Well, s/remove/move/, as Colin says.
[18:17] <cjwatson> But I'm not sure whether LP will forbid -proposed from going backwards
[18:18] <infinity> Hrm.  It probably does.
[18:18] <infinity> That could be fixed, though.
[18:19] <cjwatson> Looks like the relevant ancestry check only looks for PUBLISHED and PENDING.
[18:19] <cjwatson> So it should work.
[18:19] <cjwatson> You just don't get to *reuse* a version.
[18:20] <geser> so it's still nice to resolve all those FTBFS and DEPWAIT in -proposed till release but as important as in last releases (before the introduction of -proposed migration) for SRUs and security updates?
[18:21] <infinity> I feel like that sentence might have been missing some words.
[18:21] <cjwatson> We have a bit more flexibility, at least.
[18:21] <cjwatson> Once I get round to fixing a bug in the LP copier, I plan to start demoting stuff from release to -proposed when it's sufficiently broken.
[18:23] <geser> infinity: ... but not as important ... (I hope I didn't miss any more words)
[18:23] <infinity> cjwatson: I'm still trying to sort out when that would be a good idea.
[18:23] <infinity> cjwatson: We can't force users to downgrade afterall, so removing a package from the release pocket doesn't really remove it from the wild in any meaningful way.
[18:24] <cjwatson> We remove packages in other cases ...
[18:24] <infinity> We remove because we're removing things completely, sure.
[18:24] <infinity> But that's a bit different from a "temporary demotion" that should usually just be someone fixing it.
[18:24] <cjwatson> Also, there's still a handful of sources with no binaries for one reason or another that got into release pre-proposed-migration, but where I'd rather not remove the source entirely because they still ought to get fixed.
[18:24] <infinity> The exception to that being the group of packages with only source in the release pocket, but that's a one-time fix.
[18:24] <cjwatson> And of course there's a chunk of uninstallables in the release pocket.
[18:25] <cjwatson> Each of those has the effect of making proposed-migration a bit less reliable (because it only checks for lower uninstallable count, not a strict subset)
[18:25] <cjwatson> Anyway, I do expect it to be rare-ish, but I'd like to have the option
[18:26] <infinity> cjwatson: Do we have britney output for the full archive somewhere readable?
=== jbicha is now known as Guest12501
[18:26] <cjwatson> I don't think so.  It's years since I tried, but I gave up after six hours
[18:26] <infinity> cjwatson: saucy_probs being main-only is a bit unhelpful for clearing up the remaining uninstallables.
[18:26] <cjwatson> Maybe it'd be faster now, dunno
[18:27] <cjwatson> Feel free to have a go and see if it completes in finite time nowadays
=== Guest12501 is now known as jbicha_
[18:27] <infinity> Heh.
[18:27] <infinity> I'd probably be happy to manually run it a few times over a few months while we fix and/or demote what's still broken.
[18:27] <infinity> Cause after that, other than people forcing things in (ugh), we should be able to stay clean.
[18:39] <geser> ubuntuwire has a debcheck page but it isn't updated anymore since Nov 2012
[19:08] <smoser> hey..
[19:08] <smoser> i'm looking at http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/current/images/SHA256SUMS
[19:08] <smoser> what is "gtk" there?
[19:08] <smoser> in things like 'cdrom/gtk/initrd.gz'
[19:08] <smoser> what does that indicate ?
[19:13] <psusi> hrm... debian seems to have added a new X/gtk frontend to d-i... I wonder if that's it
[19:15] <jpds> smoser: Well, booting its mini.iso brings up a little GTK installer.
[19:16] <psusi> I've been wondering why we haven't adopted that in our cds yet
[19:16] <psusi> last time I set up a debian vm with it, it was quite nice
[19:16] <jpds> smoser: wget http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/current/images/netboot/gtk/mini.iso
[19:18] <infinity> arges: \o/
[19:18] <infinity> arges: Yay for a simple patch for that instead of backporting madness.
[19:18] <infinity> arges: (re: qemu qcow2 issues)
[19:26] <qengho> Hi all.  I am trying to use pbuilder-dist to build some package for armhf.  It complains that it can't satisfy "cdbs" build dependency, even though I see it as installable if I "pbuilder-precise login" and "apt-cache policy cdbs".  I can install it manually, too. My debian/control has no version specified for cdbs. I think I need help debugging it.
[19:34] <arges> infinity: thanks! yea i was happy about it too
=== alexbligh1 is now known as alexbligh1_away
=== alexbligh1_away is now known as alexbligh_away
=== alexbligh_away is now known as alexbligh1
=== alexbligh1 is now known as alexbligh1_away
=== alexbligh1_away is now known as alexbligh1
=== alexbligh1 is now known as alexbligh1_away
=== alexbligh1_away is now known as alexbligh1
=== alexbligh1 is now known as alexbligh1_away
=== alexbligh1_away is now known as alexbligh1
[20:33] <slangasek> psusi: hi, if you're going to do triage work on acpi-support bugs, it would be more useful to assign them somewhere else entirely :)
[20:34] <slangasek> psusi: because the acpi-support package is legacy and contains only a handful of event handlers in saucy, all of which we want to see moved elsewhere as we find places to land them
[21:03] <alesage> fginther, ted had a question about where he should assign his new project
[21:03] <alesage> sorry tedg :) ^^
[21:04] <alesage> where tedg's new proj probably belongs in a couple of stacks--how should one choose, fginther?
[21:04] <fginther> alesage, tedg, you mean which stack should it go into?
[21:04] <alesage> fginther, yes
[21:04] <tedg> fginther, Yes, it needs to get into the phablet PPAs but I'd rather do the standard distro targets.
[21:05] <fginther> alesage, it comes down to if it has any dependencies that need to build first and if it needs to be built with anything...
[21:05] <tedg> fginther, No, none of those.
[21:06] <tedg> fginther, Eventually Unity 7 and 8 will dep on it, but not yet.
[21:06] <fginther> tedg, the phablet stack files are really just a crutch until things are in distro. So if we can put it under 'head' all the beter
[21:07] <tedg> fginther, Sounds fine to me
[21:07] <tedg> fginther, It's the phablet guys that don't like hearing that their builds are a demoware ;-)
[21:07] <alesage> tedg stop rattling cages jeez ;)
[21:08] <alesage> can't we all just get along
[21:08] <alesage> thx fginther for your advice
[21:08] <tedg> alesage, That's no fun!
[21:08] <tedg> :-)
[21:08] <fginther> tedg, I'm looking at the stack dependencies. Right now unity.cfg might be the best answer.
[21:09] <tedg> fginther, I put it in misc for now.
[21:09] <fginther> tedg, the integration team will need to review, they may have a better answer
[21:09] <tedg> fginther, I figured that was easier to get started.
[21:09] <anon^_^> is there a preferred method of contact to reach the admin of packages.ubuntu.com
[21:09] <fginther> tedg, works for me
[21:09] <tedg> fginther, alesage, thanks guys!
[21:09] <alesage> tedg np!
[21:10] <anon^_^> it doesn't appear that the website is reflecting updates/security updates over the past month to multiple Ubuntu releases
[21:12] <sarnold> anon^_^: indeed, at least libx11 is missing raring's security update
[21:12] <anon^_^> yeah the entire package db looks like it hasn't been updating since late april
[21:13] <sarnold> anon^_^: ah, at the bottom there's an "email rhonda@ubuntu.com". can't hurt as a place to start. :)
[21:13] <anon^_^> i'd prefer irc
[21:13] <anon^_^> lol
[21:13] <anon^_^> maybe i'll just wait for cjwatson to appear
[21:17] <cjwatson> qengho: If you mean building armhf packages on an x86 host, I doubt you'll get far using pbuilder for cross-building - as far as I know it hasn't been taught how to do it.  Use a recent version of sbuild instead, as per https://wiki.ubuntu.com/CrossBuilding
[21:17] <cjwatson> anon^_^: I have no control over packages.ubuntu.com
[21:17] <cjwatson> anon^_^: Try #canonical-sysadmin
[21:17] <anon^_^> rhonda's online just not in chan
[21:18] <anon^_^> sending her a pm
[21:18] <sarnold> don't forget that freenode isn't only ubuntu..
[21:20] <qengho> cjwatson: I figured it out. eatmydata works for native, but for qemu-emulated architectures, it fails, in a weird, weird way:  Can't satisfy cdbs build-dep. Obviously.
[21:34] <chiluk> smoser mterry can you guys look at https://bugs.launchpad.net/compiz/+bug/1083186  ?
[21:34] <ubottu> Launchpad bug 1083186 in unity (Ubuntu Quantal) "icaclient windows "dancing" when decorated" [Undecided,New]
[21:34]  * mterry looks
[21:34] <chiluk> the sru is seriously stalled.
[21:34] <chiluk> and I'm not sure how else to push on it .
[21:36] <slangasek> chiluk: unity and compiz packages were uploaded to precise-proposed just today; you can reasonably expect them to be accepted into precise-proposed sometime this week
[21:37] <chiluk> thanks slangasek
=== alexbligh1 is now known as alexbligh1_away
=== alexbligh1_away is now known as alexbligh1
=== alexbligh1 is now known as alexbligh1_away
=== alexbligh1_away is now known as alexbligh1
=== kentb is now known as kentb-out
=== salem_ is now known as _salem
=== alexbligh1 is now known as alexbligh1_away
=== alexbligh1_away is now known as alexbligh1
=== alesage is now known as alesage|afk
=== Logan_ is now known as Eating
[22:49] <mterry> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== wedgwood is now known as wedgwood_away
=== Nisstyre-laptop is now known as Nisstyre
=== Eating is now known as Logan_