[00:13] <darkxst> can we get ddebs enabled for ppa:ubuntu-gnome-packaging/staging
[00:13] <darkxst> moving forward that will become the official bridge between gnome3-staging ppas and the archive, rather than using a mishmash of personal ppa's for that task
[00:13] <darkxst> ^ infinity ?
[00:16] <infinity> darkxst: Add me to the team, and I can make that happen.
[00:16] <infinity> darkxst: Alternately, I can ask someone with superpowers. :P
[00:17] <darkxst> infinity, added you
[00:18] <infinity> darkxst: Should be good to go.  Assuming I got the two options right.
[00:18] <darkxst> infinity, thanks
[00:18] <infinity> darkxst: Bumped up the quota a bit too, hopefully you'll have a bit of room to play.
[00:21] <darkxst> infinity, ok thanks
[00:22] <darkxst> I intend to avoid webkitgtk in there, so quota shouldnt be a huge problem ;)
[00:23] <infinity> darkxst: Well, ddebs have the unforunate habit of being huge.
[00:23] <infinity> darkxst: But avoiding webkit is a good start.
[00:23] <infinity> darkxst: Avoiding webkit is a decent life goal in general, I'd say.
[00:23] <darkxst> ~600MB just for ddebs in webkitgtk
[00:24] <darkxst> infinity, yes, the ppa builders even struggle to build the bloated thing
[00:24] <infinity> darkxst: That shouldn't be true with the new and shinier PPA builders.
[00:24] <infinity> darkxst: If it still is, we'd like to hear about it.
[00:25] <darkxst> infinity, well havent actually tried to build it in a while
[00:27] <darkxst> last build was in October, and that is probably using the --no-keep-memory hack
[00:29] <cjwatson> The new and shinier PPA builders went into production around the end of July.
[00:31] <darkxst> cjwatson, yeh I think my battles building webkitgtk would pre-date that
[00:33] <darkxst> cjwatson, though I have seen the odd build get stuck publishing for hours in recent times
[00:33] <cjwatson> Publishing would be quite different.
[00:33] <cjwatson> If anything is stuck for hours, there's probably some kind of central bug.
[00:34] <wxl> infinity: any good enws on fixing our transition to metapackages?
[00:34] <cjwatson> Or possibly the publishing is OOPSing, which occasionally happens due to races that cause file clashes, but that's rare.
[00:34] <cjwatson> darkxst: Let us know nearer the time if you see that again.
[00:35] <darkxst> cjwatson, sure will do
[00:36] <infinity> wxl: Working on it today.
[00:36] <darkxst> infinity, err what happened to tasks? dependency resolution on ubuntu GNOME is really broken without them
[00:36] <wxl> infinity: thank you, sir!
[00:36] <infinity> darkxst: We can't use tasks in conjunction with the HWE upgrades, because we can't change tasks post-release.  A bit annoying, but such is life.
[00:37] <infinity> s/upgrade/updates/
[00:37] <darkxst> infinity, so we are stuck with the u-c-c stack then? things like "unity-control-center | gnome-control-center" just don't work without tasks
[00:38] <infinity> darkxst: No, you're not stuck with it, I just need to abuse livecd-rootfs a bit more to hint apt to DTRT.
[00:39] <infinity> darkxst: I already fixed several such issues on the unity flavours, I just have to do the inverse for everyone else.  I have notes, and a plan. :P
[00:40] <infinity> Possibly also a man and a canal.
[00:42] <wxl> infinity: if you're messing with livecd-rootfs, will that have an affect on debian-installer? Lubuntu's alternate image uses that and seems to be afflicted with the bug, too
[00:43] <darkxst> infinity, ok good to know
[00:43] <infinity> wxl: The alternate image is a bit stickier.  I'm not entirely convinced we *can* fix it, and am leaning toward perhaps suggesting you drop the alternate for 14.04.2 and above.
[00:43] <wxl> infinity: oh man, that's problematic. with lubuntu focusing on low-spec machines, it's sometimes a requirement.
[00:44] <infinity> wxl: People who really need the alternate image can always use 14.04.1 and, honestly, are probably not the same set of people who really need shiny new kernels and X drivers.
[00:44] <infinity> wxl: In fact, you just confirmed it. :P
[00:44] <wxl> infinity: well, what about 16.04 for example?
[00:44] <infinity> wxl: Low-spec/old machines don't need the HWE stack.
[00:45] <infinity> wxl: Oh, for future full releases, we can still do alternates (though, some day, you may want to re-examine that, and tell people who love alterates to just use d-i netboot/mini.iso instead).
[00:45] <wxl> infinity: so then, these low-spec machines just need to suffer with long update times :)
[00:45] <infinity> wxl: It's specifically for HWE point releases where making alternates work perfectly seems... Curiously difficult.
[00:45] <infinity> wxl: Update times?
[00:45] <wxl> infinity: yeah, it's been a constant point of discussion. if this just affects 14.04, no worries.
[00:46] <wxl> infinity: well the point releases are HWE + collected updates, no?
[00:46] <infinity> wxl: Oh, you mean installing 14.04.1 and then having a long apt-get upgrade.  Sure.
[00:46] <wxl> right right
[00:46] <wxl> that's totally reasonable
[00:46] <wxl> infinity: so i will assume you CANNOT fix alternate this cycle. if you find you can, let me know :)
[00:47] <infinity> We can make them sort of work, I think.  We did make alternate ubuntu images kinda work in precise point releases.  But I'm not sure they were ever perfect.
[00:47] <infinity> It's the last thing I'll look at, though.
[00:47] <wxl> fine with me
[00:47] <wxl> like i said, i'll assume the worst :)
[00:47] <infinity> Desktop/Live CDs being the more commonly-used (especially by people with shiny video cards) option.
[00:49] <infinity> wxl: I think it would be in your (lubuntu's) best interest, though, if we could sort out ways to shave off memory usage in ubiquity enough to make you happy with the desktop CD for all installations.
[00:49] <infinity> wxl: Given that you're the only flavour with an alternate anymore.
[00:49] <wxl> infinity: i know, i know. we're the black sheep of the family. :)
[00:49] <infinity> wxl: For people who need the raw flexibility of d-i, there are always the mini/netboot images, but for a full desktop installer, it would be great to see you ship a single ISO like everyone else does.
[00:50] <infinity> wxl: Anyhow, not worth talking about today.  But something to think about.
[00:50] <wxl> infinity: if you have ideas on how we could shave memory usage, that's typically the problem. i'm always open to new ideas.
[00:51] <infinity> wxl: Well, the most obvious way would be a text-only frontend, and skip X entirely.
[00:51] <infinity> wxl: Or a fun d-i/live mix, like the server CD.
[00:52] <infinity> wxl: Anyhow, another time.
[00:52] <wxl> right
[00:52] <wxl> thanks again and talk later about that :)
[01:40] <darkxst> infinity, ok ddebs worked ;) thanks
[02:51] <tkamppeter_> Hi, can someone reject ghostscript 9.15~rc1~dfsg-1 from vivid-proposed? Both the package and the version number (all synced from Debian) are broken. And I would like to upload a ghostscript 9.15~dfsg package.
[02:58] <infinity> tkamppeter_: And how is this going to be fixed in Debian?
[02:58] <tkamppeter_> infinity, I do not know how they will switch from the RC1 to the final.
[02:59] <infinity> tkamppeter_: Perhaps we should do the same thing they do?
[02:59] <tkamppeter_> infinity, but their RC1 has some things we are not able to sort out before our FF and so I want to stay independent of Debian for Vivid and return to sync after Vivid.
[03:01] <infinity> tkamppeter_: Anyhow, the obvious way out would be to stop using ~ there.
[03:01] <infinity> tkamppeter_: 9.15+dfsg-0ubuntu1 would sort higher.
[03:01] <tkamppeter_> infinity, I also do not expect them to go to final before our FF, once final is out for months and second, working on this GS version is a pet project for the developer as Debian is in freeze )and new stuff is handled in experimental).
[03:02] <infinity> tkamppeter_: And it would still be a good idea for you and OdyX to agree on a single 9.15+dfsg orig tarball, so syncing later isn't a pain in the butt.
[03:02] <tkamppeter_> infinity, I am now building 9.15dfsg-0ubuntu1. Should also sort higher.
[03:03] <infinity> tkamppeter_: +dfsg is the general convention, to keep it clearly demarcated from the upstream version.
[03:03] <tkamppeter_> infinity, I think I will stay independent of Debian for 9.15 and get back to sync from 9.16 on. GS upstream updates every 6 months.
[03:04] <infinity> In case upstream were to ship, say, 9.16a. :P
[03:04] <infinity> Or 9.15a, or whatever.
[03:05] <tkamppeter_> infinity, I think upstream has never done this, even with a small quirk they have bumped their minor by 1.
[03:05] <tkamppeter_> infinity, and such an oops release would also happen very close after the release and not months later as now. So next is for sure 9.16
[03:06] <infinity> tkamppeter_: Sure, maybe they wouldn't, it's still just generally nicer to keep the "dfsg" bit as clearly not part of the upstream version.
[03:07] <infinity> tkamppeter_: I'm not bikeshedding here, just pointing out general Debian convention.  The part where ghostscript used ~dfsg instead of +dfsg is what lead to the hilarity.  May as well not make a slightly different mistake to cover it.
[03:08] <tkamppeter_> infinity, OK, will use +dfsg.
[03:08] <infinity> tkamppeter_: Ta.  I've made the same suggestion to OdyX.  We'll see if he changes his versioning in Debian for his next version. :P
[03:17] <tkamppeter_> infinity, ghostscript at Debian is handled by Jonas Smedegaard, not by OdyX. So probably Jonas has introduced the broken version number.
[03:17] <tkamppeter_> infinity, but thanks anyway for the suggestion od *dfsg.
[03:17] <tkamppeter_> s/*dfsg/+dfsg/
[03:17] <infinity> tkamppeter_: Oh, I saw some uploads from OdyX and assumed he was the culprit.
[03:19] <tkamppeter_> infinity, can it be that Jonas creates the GS packages and OdyX uploads them?
[03:20] <infinity> tkamppeter_: Looks like they both upload, I just picked on one of them.
[03:21] <infinity> tkamppeter_: I've annoyed Jonas too now. :P
[03:21] <tkamppeter_> infinity, the debian/changelog entry of the package which I have synced is "signed" by Jonas.
[03:22] <infinity> tkamppeter_: Yeah, he was probably doing the experimental uploads, while recent unstable uploads were OdyX.
[03:32] <tkamppeter_> infinity, +dfsg is now uploaded to vivid-proposed and accepted by the server. amd64 is already building.
[03:33] <tkamppeter_> infinity, so the version number is correct.
[15:18] <ogra_> infinity, did we drop the precise crontab entries on cdimage on purpose ?
[15:18] <ogra_> (crontab -l output is stunningly short)
[15:19] <infinity> ogra_: Yes, the last precise point release was 12.04.5, there will be no others, so no point in daily images.
[15:19] <ogra_> ah, cool
[15:24] <teward> thanks to whomever accepted nginx into precise-proposed.
[15:51] <teward> any chance anyone can look at the trusty-proposed upload of nginx as well?  Same case as the precise-proposed one, just needs accepted into -proposed.
[16:33] <teward> thanks to whomever accepted nginx to trusty-proposed as well
[16:59] <ogra_> i have switched the system-image importer off for a coordinated device tarball landing
[18:43] <wxl> infinity: the metapackage issue is not affecting vivid daily is it?
[18:50] <cjwatson> wxl: shouldn't expect so, since tasks are updated in development series
[18:51] <wxl> cjwatson: okie dokie. thanks. :)
[19:48] <bdmurray> arges: Could you have a look at this gdb upload in the utopic queue? I'd just like a second opinion.
[19:49] <arges> bdmurray: sure.
[19:51] <arges> bdmurray: hmm why does the gdb changelog add vivid/experiemtal entries? so we're essentially applying a bugfix only stable update to gdb
[19:52] <bdmurray> this bug sort of explains it better https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1394542
[19:52] <arges> bdmurray: any why wasn't a patch against 7.8-1ubuntu4 possible/
[19:52] <arges> bdmurray: ah
[19:53] <arges> bdmurray: yea this is a beast of a diff.
[19:59] <arges> bdmurray: not sure what Binary files /tmp/ata_ZKYx4X/gdb-7.8/gdb/doc/gdb.info-7 and /tmp/AlEUppVBQj/gdb-7.8.1/gdb/doc/gdb.info-7 differ
[19:59] <arges> is
[20:03] <arges> bdmurray: so i think figuring out what that binary change was. the glob looks like we'd expect from a stable update. the 'non-linear' changelog isn't optimal either, but probably doesn't harm anything
[20:05] <bdmurray> arges: okay, thanks for looking
[20:05] <arges> bdmurray: hopefully that helps... reviewing the openstack stuff atm
[20:11] <sil2100> Hey everyone! I re-enabled the image importer on system-image now
[20:50] <tkamppeter> arges, hi
[20:51] <arges> tkamppeter: hi
[20:53] <tkamppeter> arges I tried already cups 1.7.2-0ubuntu1.3, but as this number was already used for the SRU in bug 1386241 which I have withdrawn, my attemt to upload the new SRU with this number got auto-rejected by the upload server. I was told then to use 1.4.
[20:55] <arges> tkamppeter: yea there was another fix for cups that was uploaded for 1.3, will it be a problem to use 1.4?
[20:55] <tkamppeter> arges, no. I have uploaded it as 1.4 and you have rejected it.
[20:56] <arges> tkamppeter: hmm i thought i rejected the other upload.
[20:58] <tkamppeter> I got a reject message for the 1.4 which I have uploaded yesterday (or on Monday).
[20:58] <arges> tkamppeter: hmm. Today I was looking at: bug 1352809
[20:58] <tkamppeter> arges, you have added a comment to that reject that I should use 1.3 instead of 1.4.
[20:59] <arges> tkamppeter: give me one second to review. I'm unsure why your upload was rejected as I was trying to reject the upload for the bug I mentioned above.
[21:00] <tkamppeter> arges, yes, for this bug (bug 1352809) I did the upload this week, with version 1.4, as 1.3 was already used up by the other bug.
[21:00] <tkamppeter> The SRU I want to be done now is the one for bug 1352809.
[21:01] <arges> tkamppeter: ok so right now no cups fixes have been uploaded for either
[21:01] <tkamppeter> arges so I will put that SRU back in as 1.4, then you accept it.
[21:02] <arges> tkamppeter: Yes, I think that may work. Will you also include the fix for 1352809?
[21:02] <arges> (Sorry, you already answered that)
[21:02] <arges> Yes
[21:04] <arges> tkamppeter: there it is. Reviewing it now.
[21:04] <tkamppeter> arges, the other bug (IPP Everywhere) I will do later as the manufacturers need to do more IPP-overUSB testing.
[21:05] <arges> tkamppeter: ok perfect. sorry about the confusion.
[21:05] <tkamppeter> arges, it is a simple patch, same as for Utpic which you have accepted.
[21:06] <arges> Yes, looks identical
[21:06] <arges> tkamppeter: thanks
[21:06] <tkamppeter> thanks for accepting.
[22:25] <ari-tczew> can someone move cmdtest to main?
[22:25] <ari-tczew> it's needed to build current xauth