[00:07] can someone de binary new python3-wsme please? [02:03] bloody hell, cdparanoia is complicated and poorly documented === Guest15447 is now known as Logan_ === Logan_ is now known as Guest38927 [05:14] ev: when you are free please have a look at LP # 1192777 [05:14] I have sent you a mail with more details [05:38] Good morning === pitti_ is now known as pitti [05:41] infinity: eek! added now, but I'm afraid it'll only start collecting them from now on [05:41] or rather, from a month ago on [05:42] pitti: Oh, was it actually not collecting either? I thought I saw ports stuff in pool, but maybe I was seeing things from previous releases, I didn't look too closely at versions. :/ [05:42] infinity: collecting yes, but they time out after 30 days [05:42] If not referenced. Right. Ugh. [05:42] as there hasn't been any index to refer to them [05:43] I wonder just how much of the archive will be rebuilt by 14.04. Probably all of main, at least. [05:43] I'd really like our ports dbgsym story to be mostly fixed by then. [05:45] infinity: indeed; what's the current status of that, OOI? [05:45] pitti: Which "that"? [05:45] "that" == ddebs in librarian [05:46] Hah. [05:46] We're pretty much ready to roll, just need to be sure the SAN won't explode. Which I think it might, from last I heard. [05:47] pitti: But from our (soyuz) side, we're ready to flip the switch as soon as we have a green light. [05:48] pitti: It should already be working on dogfood (and maybe staging; wgrant?), so you can prototype new and improved ddeb-retriever behaviour, perhaps. [05:48] Yeah, librarian disk space is the issue now [05:48] It might be a while until that's resolved [05:48] We're sorta bursting at the seams atm [05:49] wgrant: Does dogfood actually have some ddebs published in the primary archive somewhere, so pitti can play with what that looks like? [05:49] infinity: hey, is there any code to detect some potential arch publication mismatch causing FTBFS and retrying for us? [05:49] It's enabled on the DF primary archive, and can be on the stagings, but staging has no Soyuz [05:49] infinity: since I enabled -proposed in the daily releases, we keep getting failures due to that [05:49] I think DF's primary archive should still have some ddebs [05:49] Whether you can actually get them out of it without timeouts is another question entirely. [05:49] didrocks: As in, arch all/any skew causing build-dep failures? [05:50] didrocks: If there was code that detected that, it would be awfully mean of me to not let your PPA use it, right? :) [05:50] infinity: exactly (libgtk3-dev this night for instance) [05:51] infinity: heh, that's my guess, but it can be as well hackish code that you won't want launchpad to have :p [05:51] (I actually had something in the works to turn those into proper dep-waits, cause that's what they should be, but never finished it up) [05:51] agreed, they should be treated as dep-waits [05:51] Anyhow, your best option right now is just to retry. [05:51] I guess the case to reliably detect that is not that easy :) [05:51] didrocks: Well, the thing is you need to drill down to find out WHAT to dep-wait ON. [05:52] infinity: yeah, it's failing all my stacks though, so monkey work in the morning to relaunch everything [05:52] * didrocks wonders if he shouldn't turn proposed off, and only turn on when we have a desired transition [05:52] for the time being [05:52] didrocks: Which isn't too terribly hard, wouter wrote a resolver-reduction algorithm that drills down to first causes of apt failures, but I never got around to tying it into sbuild. [05:52] (and have otto supporting turning otto on and off on demand) [05:53] didrocks: It shouldn't fail everything all that often... If skew was that huge a problem, the whole archive would be FTBFS constantly. [05:53] didrocks: Perhaps you just turned this on at a particularly tumultuous time. [05:53] infinity: yeah, maybe we are just unlucky since we turned in -proposed… but for the past 3 days, it's not fun, I can tell you :) [05:55] Anyhow, your call. The arch skew dep-wait bug has been on my TODO for something like six years, so I imagine I won't be fixing it tomorrow. [05:55] Maybe I'll put it on the project hacking agenda for our release engineering sprint. [05:56] infinity: yeah, I'll give it a chance for still some days and see if it's better to turn on and off (but I need to ack the testing to ensure we can have it on and off conditionnally) [05:56] infinity: that would be great! But I'll try to base my decision as if this doesn't exist :) === smb` is now known as smb [07:08] good morning [07:14] infinity: if that's your wish i can do full-wipe-resync for lp:ubuntu/*/eglibc branches. [07:16] bdmurray: if gtk fails to initialise and we have a terminal, do-release-upgrade interface should be invoked instead?! [07:17] cjwatson, r202 fixes virtual packages and rdeps checking when a request file is specified. [07:24] cjwatson, I need to improve virtual package support and not expand it to the list of providing packages when a direct dependency also provides this virtual package. [07:25] otherwise results are sometimes odd, for example sbuild test is triggered when citadel is uploaded because it provides mail-transport-agent [08:07] manish: yeah, that's not intended to work yet. It should be greyed out though. I'll fix that much :) [08:15] cjwatson, didrocks: so, jdstrand gave a security team +1 to qtwebkit-opensource-src as a temporary solution until we have our own bindings [08:15] (https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/1) [08:15] Launchpad bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New] [08:15] yeah, saw that, nice! ;) [08:15] but we probably need MIR review still before promoting [08:16] I remember to have cleanswap/reviewed the package before NEWing [08:16] so it's good to me, but as I participated to it, not sure of the conflict of interests I'm usually trying to avoid [08:16] but not sure as well we should wait for mterry to be up [08:16] who else can help here? doko? [08:16] yeah, I guess === doko_ is now known as doko [08:28] how? [08:31] doko, can you help reviewing bug #1192567 [08:31] bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New] https://launchpad.net/bugs/1192567 [08:32] doko, that's currently blocking saucy CD builds since the qt5 version of signon-ui made it to the archive [08:32] doko, we don't want to revert because it would be non trivial and would break touch images (qt4 doesn't work on there) [08:33] ok, will look at it today [08:35] doko, thanks [08:36] doko, didrocks did a first review at upload time and was ok with them, but since he's one of those who worked on the package and got it uploaded he said he would prefer having a second review (to avoid acking his own package) [08:44] @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: henrix === mmrazik is now known as mmrazik|afk [08:55] didrocks: For something outside Launchpad, perhaps edos-distcheck would do the job for you [08:57] jibel: Deployed r202, thanks! Yeah, I can see that glitch being confusing but it isn't too horrible [09:00] ev: I have been working on https://bugs.launchpad.net/activity-log-manager/+bug/1192778 but all I am getting is segfaults, since you know your way around the code, can you have a look at it too [09:00] Launchpad bug 1192778 in Activity Log Manager "Diagnostics tab doesn't show in standalone mode" [Medium,Confirmed] [09:02] sure, I'll have a look today [09:02] thanks a lot === mmrazik|afk is now known as mmrazik [09:24] jibel: wrt. the current nova adt failure, do we actually mail these notifications to the actual uploaders? [09:24] jibel: (I don't think we do) [09:25] pitti, I made the modification but it is not deployed. [09:26] pitti, now it is [09:26] jibel: ah, thanks [09:26] * pitti bounces the notification to zul then [09:26] Riddell,ScottK: Is anyone working on the way that plasma-widget-networkmanagement Breaks the version of kde-workspace-data currently in saucy? It looks like it's been making all your images unbuildable for a few days. [09:27] Urgh, gtk+3.0/3.8.2-0ubuntu5/armhf isn't happy, is it [09:27] Threading tests or something? [09:27] cjwatson: no don't think I've seen that, I'll take a look in a bit [09:28] Riddell: ta [09:28] Riddell: I thought you were auto-mailed on image build failures - is that not working? [09:28] cjwatson, I'm doing a build on a porter box to try figuring the gtk issue out [09:28] (That isn't meant as a passive-aggressive "why aren't you reading your build failure mail" thing, btw) [09:28] cjwatson: yesterday's e-mail only says kubuntu/dvd: precise-dvd-amd64.iso oversized by 2436018176 bytes (3509760000) [09:29] Riddell: Not the health checks [09:29] 15187 T Jun 20 CD Image LiveFS kubuntu/saucy/amd64 failed to build on 20130620 [09:29] cjwatson: gtk+3.0 still building only started 40 minutes ago... so another 2h to go or so. [09:29] xnox: this time round, yes; it's been tried several times [09:29] seb128: *nod* [09:29] ah [09:29] i see.... [09:29] cjwatson, it seems to be tests failing on "Cannot animate property 'background-image'" [09:29] cjwatson: I don't think I get any other e-mail about the images [09:30] cjwatson, xnox: well, maybe there is a real problem, but we had flacky test issues before so I retried a build while debugging, in case that make it work this time [09:30] Riddell: /msged you the relevant headers. Mail filter problems maybe? It should be using the same address for both health checks and image build failures [09:31] cjwatson: plasma-widget-networkmanagement needs kde-workspace >= 4.10.80, that will be uploaded in the next days (today or tomorrow I guess) [09:31] * yofel thought that britney would've held that back... [09:32] proposed-migration doesn't check arbitrary combinations of coinstallability [09:32] In this case plasma-widget-networkmanagement doesn't depend on kde-workspace-data so there's nothing to cause it to enforce them to be coinstallable [09:32] ah ok, I guess that makes sense then as it doesn't really need kde-workspace [09:32] ok, thanks [09:32] If in doubt you can feel free to ask the release team for preemptive blocks (though too late now for this one) [09:34] win 67 [09:54] hum, I can't reproduce the gtk test issue on porter-armhf :/ === MacSlow is now known as MacSlow|lunch [12:01] http://paste.ubuntu.com/5783426/ the tftp error log [12:05] who can help me ? === gusch is now known as gusch|lunch === Sweetsha1k is now known as Sweetshark === MacSlow|lunch is now known as MacSlow === mmrazik is now known as mmrazik|afk === gusch|lunch is now known as gusch [12:55] pitti: so perhaps part of the questions are not strictly SRU-related. One question is if we should keep branching lp:ubuntu// when preparing a new SRU (or any upload in fact). Afair the idea was that one would then merge back into lp:ubuntu//, and upload would be automatically triggered. Not sure if this is accurate, or the plan has been dropped. Thoughts? [12:56] cjwatson: ^^^ you might know too [13:04] free: there are no automatic uploads [13:04] free: if you have an existing lp:ubuntu/release-updates/pkg branch, you are welcome to use it for MPs [13:04] free: generally speaking, you should pull from lp:ubuntu/-proposed/ or lp:ubuntu/-updates/, and lp:ubuntu// as a last case, for doing an SRU. [13:05] free: if you are doing the first SRU for a package, then the -proposed/-updates branch doesn't exist yet, and you better don't push it to LP and leave it to the auto-importer [13:05] and uploads go into -proposed first, and for stable releases, lp:ubuntu// will basically never change again [13:05] @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: henrix, Laney [13:10] pitti: is there any preference re LP branches vs. debdiffs? (as details in the SRU bug) to me branches are superior to debdiffs, but not sure if there's some recommendation [13:11] free: most sponsors get along with both these days; personally I prefer debdiffs, but you shouldn't worry too much about that [13:12] pitti: okay, I guess they have both pros and cons. Now, one last question.. [13:12] free: also, if you run into a package which has an outdated UDD branch (in my last sponsoring shift this applied to about a third of the packages I've touched), you better use apt-get source and debediffs [13:12] pitti: oh [13:12] pitti: that's unfortunate [13:12] but "bzr branch ubuntu:foo" will tell you [13:12] CURRENT vs OBSOLETE [13:12] or "OUTDATED", I think [13:14] pitti: has the number of out-of-date UUD branches increased in recent time? if so, it almost feel folks do not care about this workflow/feature anymore? Asking just to understand the situation here [13:15] free: could be; I don't think there's anyone actively working on them [13:15] pitti: I see [13:15] free: but as I said, as long as the UDD branch works, feel free to use it [13:16] pitti: yeah, apparently they've been broken for landscape-client, but still looking at it [13:17] pitti: the last thing is about bugs, https://wiki.ubuntu.com/StableReleaseUpdates#Fixing_several_bugs_in_one_upload recommends to avoid "Please SRU this"-type of bugs. But in case of landscape-client (which has an SRU exception that allows to add new features) I think it actually makes sense to have a "meta" bug. We've been doing that since ever, e.g. https://bugs.launchpad.net/landscape-client/+bug/1004678. Are we good in keeping doing [13:17] that? [13:17] Launchpad bug 1004678 in Landscape Client "Please update landscape-client to 12.05" [High,Fix released] [13:19] free: unless you don't want to use an actual bug report, I think it's still ok (but that's more a question for the current SRU team) [13:19] cjwatson: edos-distcheck is maybe the solution, right! It's a little bit convoluted to need that to detect the FTBFS in the ppa for that component is due to archive skew and it should just relaunch later on (with a timeout), but that can work. Just not as easy to integrate when we have multiple releases and so on :) [13:20] * didrocks just did some trials locally [13:21] pitti: thanks [13:23] free: I rarely find it worth bothering with branches for SRUs since there are too many weirdnesses (e.g. if there's been no upload to -proposed yet) [13:24] cjwatson: I see, then we probably want to update our procedure to use debdiffs [13:24] didrocks: or you could scan the PPA build log for "The following packages have unmet dependencies:" and flag those for "somebody needs to work out what the dep-wait here is" [13:24] Debian's archive/buildd system is better at this :-/ [13:25] cjwatson: any take on the "Please SRU this"-type of bug for landscape-client? (see just above) [13:26] cjwatson: yeah, I think that's a viable option, knowing that the other case will be dep-wait (like no Qt5 on powerpc), so will do that scanning, and maybe can retry after an hour, after 2 retrials, will abort. [13:27] free: it's not too unreasonable if there's something complex about the SRU itself, indeed [13:28] cjwatson: typically we address many bugs in every SRU, since we're introducing new features [13:29] @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: Laney [13:29] cjwatson: kind of unrelated, but in light of these discussion is it fair to conclude that the Ubuntu Distributed Development project is kind of paused/abandoned? === _salem is now known as salem_ [13:31] free: maintenance mode [13:31] cjwatson: I see, thanks [13:32] free: there are some people responding to issues but it's not being actively development [13:32] *developed === mmrazik|afk is now known as mmrazik [13:39] * Laney pokes bdmurray about bug #1142947 at the top of the queue ;-) [13:39] bug 1142947 in webkit (Ubuntu Raring) "webkit--epiphany-browser crashed with SIGSEGV in Decoder()" [High,Triaged] https://launchpad.net/bugs/1142947 [13:51] does anyone *not* see this bug on saucy [13:51] https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1191951 [13:51] Launchpad bug 1191951 in unity (Ubuntu) "clicking on entry in 'Run a command' (alt-f2) menu shows "No image available"" [Undecided,New] [13:51] to test, just hit 'alt-f2' and try to launch something by clicking [13:52] Damn this heat, I need a fan! [13:54] didrocks: the CI test failure in https://code.launchpad.net/~pitti/autopilot-gtk/testsuite/+merge/170607 gave me an invalid rebuild link; what's the real URL? [13:54] didrocks: ("http://s-jenkins:8080") [13:54] didrocks: or will it re-try automatically after my followup commit? [13:54] pitti: I think that's more a question for mmrazik, they make you configuring the "s-jenkins" host in /etc/hosts AFAIK [13:54] pitti: yes [13:55] ah, good; so I just need to wait? [13:55] if you pushed something else, it will be retriggered [13:55] pitti: yes. you just need to wait [13:55] pitti: re s-jenkins -- I checked with IS and they don't want us to unnecessarily publish our private IPs [13:55] (even though they most likely leaked here couple of times) [13:56] so yes, we modified our /etc/hosts [13:56] any reason for latex2rtf to be incredibly outdated? [13:56] mmrazik: ah, so perhaps this shouldn't say "click here", but "tests will be retried on new commits"? [13:56] (other than it being ported from Debian) [13:56] (...I guess I should just ask debian) [13:57] pitti: the "click here" is mostly there is there is some jenkins/launchpad/bzr hiccup and you want to re-trigger the build without adding a new revision [13:57] but most people don't even have permissions to do that [13:57] pitti: but yes. Let me add a note that if you push a new revision a new build will be performed [13:57] cousteau: saucy is up to date with upstream === seiflotfy_ is now known as seiflotfy [13:57] mmrazik: thanks [13:58] cousteau: it was updated in Debian (and hence in saucy) by way of non-maintainer uploads, suggesting that the maintainer isn't terribly active [13:58] well, the progression I saw was lucid: 1.9.19 precise 1.9 [13:58] https://launchpad.net/ubuntu/+source/latex2rtf [13:58] http://packages.qa.debian.org/l/latex2rtf.html [13:58] I think raring was behind because nobody noticed the pending merge [13:58] .1.9.19 quantal 1.9.19 raring 1.9.19 so I assumed s* wouldn't reach 2.3.3 [13:58] oh, actually because 2.3.1/2.3.3 initially went to experimental due to the Debian freeze [13:59] anyway, saucy's up to date now [13:59] would it be possible to request a backport? [14:00] (I installed it from source, it was easy to compile; but maybe such an old software should be avoided) [14:01] cousteau: I'm not on the backports team, but I guess so ... [14:04] cousteau: https://wiki.ubuntu.com/UbuntuBackports [14:11] cjwatson: I get the emails about the failed images. I just haven't had time to look into it the last few days. === wedgwood_away is now known as wedgwood [14:17] mmrazik, didrocks: indeed, passed now \o/ [14:17] pitti: sweet! Time for ice-cream then? :) [14:18] didrocks: my wife should get home in 30 minutes; then, for sure! [14:19] Oh, hey, it's Debian import freeze today isn't it [14:19] I'll turn off auto-sync tonight [14:19] huh, that crept up [14:20] Didn't it just [14:21] Unnecessarily early nowadays in my opinion, but [14:21] pitti: is this better? [14:21] https://code.launchpad.net/~mrazik/jenkins-launchpad-plugin/rebuild-note/+merge/170632 [14:24] mmrazik: thanks! [14:25] hm, that's the second autopkgtest that fails to install its dependencies in -proposed in two hours === salem_ is now known as _salem === _salem is now known as salem_ [14:26] perhaps the pending gtk [14:29] pitti, I disabled tests for gtk on armhf, it just finished to build [14:29] does anyone know if there is a way to downgrade packages on porter's chroots? [14:29] that shouldn't affect i386/amd64 installability in -proposed, though [14:29] pitti, it does [14:29] oh, no [14:29] not those arch, only armhf [14:29] anyway, I'll retry them in a couple of hours [14:30] hate gtk [14:30] quotes page :) [14:30] I can reproduce the test issue on a porter box [14:30] it doesn't like the css it gets from a gresource [14:30] I think you have to ask IS for downgrades [14:30] but extracting that same css with the gresource shows it's not corrupted [14:30] seb128: try it on the n7? [14:31] pitti, I guess I'm good to do that, I was trying to avoid messing up my touch image [14:31] gtk didn't change [14:31] glib didn't change [14:31] what changed is gcc and binutils [14:31] so I wonder if that's a toolchain issue [14:31] heh, mess up even more? I got a daily build from Friday, that has a black screen [14:32] pitti, mine has a week old working image I use to test system settings [14:32] so I'm trying to keep it working until daily is back to be working [14:32] otherwise if I screw it I'm without a test device [14:32] oh well, let's see [14:33] pitti, brave people use flipped :P [14:33] you should still be able to install sbuild [14:33] without risking the rest of the system [14:33] yeah, let me try [14:34] does it have overlayfs now? [14:35] nope [14:35] aufs? [14:35] nexus7 sure did have overlayfs for a while now..... [14:35] oh, maybe it was aufs it didn't have [14:35] whatever mk-sbuild sets it up to use by default [14:35] * xnox needs to reflash to check in a second. [14:36] * Laney is still using the trusty panda [14:36] I gave my panda to chrisccoulson [14:36] I should get him to debug gtk for me :p [14:37] seb128: i'm not sure how the two correlate, surely he will simply give the panda back to you :P [14:37] xnox, that's not worth the trip to France :p [14:38] cjwatson, no, and it wont get it (per discussion) [14:38] chrisccoulson: FYI, i can always take a quick eurostar trip to knock on seb128 door with a pandaboard [14:38] xnox: what about do-release-upgrade? [14:39] bdmurray: i might be wrong, was the fails to initialise gtk bug in update or upgrade manager? [14:39] xnox, nexus7 only has overlayfs on the desktop kernel, which is bitrotting in universe [14:39] ogra_: *sigh* [14:40] xnox: update-manager is the command I ran [14:40] and there are no pans to add any union fs capabilities to the touch kernels [14:40] ogra_: so which kernel are we using on touch/phablet images then? [14:40] *plans [14:40] xnox, linux-grouper [14:40] (desktop is linux-nexus7) [14:40] bdmurray: ah, then ignore me. executing do-release-upgrade over ssh is no replacement for update-manager. === Zic is now known as Guest50309 === Guest50309 is now known as Zic === mmrazik is now known as mmrazik|afk [14:52] ogra_: bitrotting in universe> ah, let me see about correcting that then [14:52] Why is the systemd package kind of useless? [14:52] ogra_: we're no longer building the n7 desktop images, right? [14:52] * Quintasan can't find /lib/systemd/systemd binary anywhere [14:53] Quintasan: Ubuntu does not support systemd as init. [14:53] slangasek: not since 2nd of May. [14:53] slangasek: Is that a proper reason for crippling the package? [14:53] xnox: righty-o [14:53] Quintasan: yes [14:53] slangasek, community people do though ... as long as it does no harm i thought we can just keep it around [14:53] * Quintasan grabs Debian package then [14:54] since the alternative to "crippling the package" is "having users make their machines unbootable" [14:54] ogra_: community people do what? [14:54] Quintasan: only certain parts of the systemd package were carefully prepared and integrated, e.g. logind. and not _all_ of it. [14:54] slangasek: That actually kind of implies that everyone will install it when it's in the repositories even if you tell them not to [14:54] slangasek, roll home brewed nexus7 images [14:55] using that kernel package [14:55] ogra_: you specifically said "bitrot"; we have a sunsetting policy on no-longer-maintained kernels in the archive to avoid precisely this [14:55] so unless someone else in the community is taking ownership of the package, it should go away [14:55] Quintasan: no, not everyone, just a non-zero number of them who will then be upset with us [14:56] slangasek, well, then be it ... we'll see who screams ... i think shadeslayer was building plasma-active images with ti though [14:56] slangasek: And now you have non-zero number of people who are upset because they can't break their system if they really want to :P [14:56] *it [14:57] ogra_: the issue is not the image [14:57] but things like X11 [14:57] ogra_: maybe shadeslayer would be happier with the -grouper kernel anyway? [14:57] which I'll try and work on next week [14:58] slangasek, nope, you wont like that kernel with a desktop install and without any android userspace (and all the hacked in groups and GIDs in the rootfs etc) [14:58] well, ok [14:58] shadeslayer: so, linux-nexus7 is not maintained by the kernel team - do you want it? :) [14:59] Quintasan: logind is in the default installs of most desktopy variants in saucy and is part of standard task. So at the moment, the number of people who want to continue be able to boot their machines is far larger than people who experiment with systemd. [14:59] Quintasan: *systemd-init that is. [14:59] slangasek: probably [14:59] slangasek: but I'm no kernel dev [14:59] xnox: That kind of makes me wonder why are we still using upstart [15:01] Quintasan: because upstart does its job, in spite of systemd upstream's attempts to embrace and extend init [15:02] slangasek: feel free to drop it from the archive though, but would be nice to have the git repo still up so that I have something to stand upon [15:02] Quintasan: i don't understand why logind was ever added to "systemd collection of daemons", since well most of them have nothing to do with "systemd init" daemon. [15:02] xnox: "embrace and extend" :) [15:03] ogasawara, apw: ^^ hi, do you have any opinion on the above discussion wrt keeping the linux-nexus7 git tree around for community use? [15:03] You had to carefully prepare and integrate parts of systemd into upstart booting process where apparently upstart does it's job? [15:04] * Quintasan kind of does not follow that [15:04] Is logind kind of mandatory with newer kernels or something? [15:05] slangasek, desktop is not using -mako, but using -nexus7 still? why ? [15:05] apw: see ogra for $reasons :) [15:05] apw: desktop does not exist in saucy, though. so raring, yes still is same since release. [15:05] apw: (grouper not mako, fwiw) [15:05] slangasek, point indeed [15:06] apw, there are community people that do home brewed images using this kernel ... [15:06] ogra_, well we won't be changing it ... ever i shouldn't think [15:06] but i'm not sure thats a reason to keep it .. i mean they can use the raring one [15:06] linux-nexus7 probabally is the raring one, and has nothing for saucy in it [15:06] right [15:07] Quintasan: gnome project decided to mandatory depend on logind instead of consolekit, among with a few other projects. [15:07] really that should move to a nexus7 branch in the raring repo to be consistant [15:07] though we have no intent to like update it or anything [15:07] Quintasan: which is unrelated to systemd-the-init. [15:07] dont we have a raring branch for it already ? [15:07] the one it was built from [15:07] just freeze that [15:08] xnox: So what's the exact problem of shipping systemd binaries and saying "Don't install, if you do - no support" and let people toy around? [15:09] ogra_, yeah it is already in the raring repo as 'grouper' like in saucy, so i think there is nothing in the linux-nexus7 which is worth keeping; it is duplicative [15:09] Quintasan: what's the problem with people who want to shoot themselves in the foot having to do so from source? :) [15:10] "carefully prepare and integrate" - you make this sound like an ordeal. Integrating logind with upstart was not particularly difficult [15:10] ogra_, and the same applied to linux-nexus4 [15:10] slangasek: I'd rather use Ubuntu than Gentoo if you know what I mean [15:10] slangasek, i think linnux-nexus7 and nexus4 are both redundant copies of the branchs in raring [15:10] Quintasan: no, you'd rather use systemd, and Ubuntu does not support systemd [15:11] apw: right, probably true [15:11] slangasek: btw did anyone experiement with X11 + Nexus 10 like they did with the Nexus 7? [15:11] apw, wait, raring grouper is not the same as nexus7 [15:11] slangasek: Neither does Debian I believe and they didn't cripple the package. [15:11] slangasek: integrating logind across the rest of packages was more work =) but yeah, just uploading logind was not particularly difficult. [15:11] apw, i think -nexus7 could evan be from quantal [15:11] ogra_, are you sure ? [15:12] Quintasan: debian's systemd is not as up to date as ubuntu one though. [15:12] apw, -nexus7 has definitely all android bits disabled and carries some ubuntu patches [15:12] along with a config thats synced up with panda [15:12] Ubuntu-3.1.10-10.28 and Ubuntu-3.1.10-10.28 [15:12] Quintasan: is there a specific reason you want to use systemd? [15:12] they are from the same base [15:13] ogra_, linux-nexus7/master and raring/grouper have the exact same version number [15:13] but i think -nexus7 had overlayfs, it definitely has all android bits disabled [15:13] ogra_, and the exact same sha1 [15:13] mdeslaur: I have a device which boots off a kernel that has this in init and I'd rather not tamper with that. But that's not my point here [15:13] apw, hmm, then we lost the original n7 tree [15:13] apw, the binaries are massively different [15:14] Quintasan: ok, sounds like a very specific use case [15:14] and you wont be able to run a desktop on the grouper kernel [15:14] which version are you comparing with [15:14] the linux-nexus7 package [15:14] ogra_, right and you are coping that forward from quantal right? we don't build it [15:14] it is a desktop kernel [15:14] well, it got copied forward, i didnt do anything :) [15:15] linux-nexus7 | 3.1.10-10.28 | raring/universe | source [15:15] right [15:15] the _only_ version of linux-nexus7 in the archive is that one, and that has the tag on that raring branch [15:15] so that really is the one [15:15] ok [15:15] i am sure we dropped the config when we move to saucy repos [15:15] i remember we had it in a PPA for a few months before ... might be that this is what i remember [15:16] you may have been pulling those into raring images of course, but they are saucy kernels [15:16] oh, if it doesnt have the desktop config it is useless [15:16] shadeslayer: not that I'm aware of, the N10 hardware has been less prevalent within the team [15:16] oh :( [15:16] ogra_, i am saying i think this raring one is the desktop one, the one you had in raring on the touch images was the saucy source codebase built in android land [15:17] and we have been keeping that in our saucy repo, not raring [15:17] what we had in saucy images was always called -grouper [15:17] ogra_, right but what about all those raring-* images we had until like this week [15:18] ogra_, those were raring yes? but using the -grouper kernel, which is saucy regardless of the prefix [15:18] apw, not sure what kernel they used, it might have even come from the android tree [15:18] so we stoped using the raring/grouper branch long before you moved to saucy- base for your system [15:18] ogra_, then if it iwasn't in our tree we don't have it, but the raring/grouper is the linux-nexus7 source regardless of the name [15:18] ok [15:29] several autopkgtest failed because python3-pykde4 is not installable. The version of the sip api in pykde4 must be bumped from sip-py3api-9.2 to sip-py3api-10.0 I guess. [15:30] jibel: known issue, rebuilds are in progress to migrate sip4. [15:31] jibel: transition is happening in -proposed and eventually they should all be able to run. [15:31] xnox, ok, thanks [15:43] cjwatson: hello! I uploaded the checkbox 0.16.2 source package yesterday, it made it into the archive, we were expecting lp:ubuntu/checkbox to show some change but there's been none. Maybe we misunderstood something about the auto-importer? [15:45] roadmr: failed, due to tags missmatch: http://package-import.ubuntu.com/status/checkbox.html#2013-05-15 21:45:35.640192 [15:45] xnox: oh great, let's see [15:45] roadmr: would like to wipe & replace lp:ubuntu/checkbox afresh. Or keep it forever out-of-date in current state? [15:46] jibel: I'll be upload a pykde4 rebuild in ~an hour to fix that. [15:47] xnox: I think we'd be OK with replacing it altogether. Better than keeping the old out-of-date branch there for all eternity.. [15:48] ScottK, np, we deployed a new interface between britney and autopkgtest this week, and wanted to make sure the problem was not on this side. Thanks! [15:49] Daviey, jamespage: seeing "The information on this page is private." on https://launchpad.net/builders is still not nice. can you avoid that kind of copying? [15:50] doko, ah - yeah - sorry [15:50] I've not got to that yet [15:52] xnox: is that something I can do somehow? [15:53] doko: we should really just fix that LP bug rather than regarding it as the uploader's problem [15:54] mehh, yes ... [15:55] roadmr, xnox: I'm eagerly interested in how that importer works [15:58] zyga: an instance of lp:udd is running that tries to work out package ancestry and correct bzr import-dsc them in the right order and right history. [15:58] doko: (it's probably bug 760303, although if you know of a different condition that triggers it, do mention it ... fancy some LP hacking?) [15:58] bug 760303 in Launchpad itself "builders page inaccessible if a private recipe build is building" [High,Triaged] https://launchpad.net/bugs/760303 [15:58]