[00:00] <Resistance> its pending builds in a PPA (I confirmed a build in pbuilder)
[00:00] <Resistance> before I can test
[00:00]  * Resistance grumbles something about nobody caring to read things in depth
[00:00] <micahg> Resistance: bug fixes really should be cherry picked (yes we can backport the new feature release, but then not everyone benefits)
[00:01] <Resistance> micahg:  this was cherry-picked initially, geser discussed this one with me, and the bug fix was fixed in Quantal, but an SRU wasnt likely to be supported (according to cjwatson) and geser stated he'd support a backport from Quantal if the fix is in Quantal
[00:01] <Resistance> if it were up to him
[00:01] <Resistance> so the problem is whether or not this is going to be fixed
[00:01] <micahg> Resistance: is there an actual patch?
[00:01] <Resistance> negative, the fix was only able to be applied in an upstream version
[00:01]  * micahg sees discussions of new versions, but no evidence of a patch
[00:01] <Resistance> hence why cjwatson stated an SRU wasn't viable
[00:02] <Resistance> micahg:  read changelogs on the source package
[00:02] <Resistance> and the sync request
[00:02] <Resistance> (which i filed)
[00:02] <Resistance> https://bugs.launchpad.net/ubuntu/+source/boinc/+bug/998195
[00:03] <Resistance> that was fixed within Quantal, but i also don't have the patch (since it seems that this was fixed upstream, with a new version, with no real patch)
[00:03] <Resistance> i could emial the debian maintainer, but cjwatson looked at the bug at my request and said it'd unlikely be SRU'd (because of version change)
[00:04] <Resistance> like the znc package, they dont release patches to fix things
[00:04] <Resistance> (one of the reasons i hate that package, really)
[00:07] <micahg> Resistance: hmm, if I throw up a build disabling a patch in the precise version, can you try it?
[00:07] <Resistance> micahg:  if i can finish beating this system out of segving, sure
[00:08] <Resistance> (its segving in Perl, and i cant figure out whether its the program/script or perl itself)
[00:09] <Resistance> meh,s crew it
[00:09] <Resistance> micahg:  which repository would it end up in
[00:09] <Resistance> main / universe, or proposed?
[00:09] <micahg> Resistance: -updates after SRU verification
[00:10]  * micahg is uploading to a PPA ATM though
[00:11] <Resistance> actually...
[00:11] <Resistance> it seems something went screwy...
[00:11]  * Resistance cant access his Seti@Home account to test
[00:11] <micahg> meh, how did this build in the first place
[00:11] <Resistance> micahg:  they did change it so it builds with gcc 4.7 (a different debian bug, that was also fixed)
[00:11] <Resistance> and tbh, idk
[00:12] <micahg> no, I mean the patches don't apply
[00:12] <Resistance> wait, really?
[00:12] <Resistance> they applied on my end here :/
[00:12] <Resistance> last i checked anyways
[00:12] <Resistance> hmm
[00:12] <Resistance> you know what, i hate PPAs
[00:12] <Resistance> there's a 5 hour wait on my ppa builds
[00:12] <Resistance> :/
[00:13] <micahg> Resistance: you get what you pay for :P
[00:14] <Resistance> micahg:  i may as well just set up a debian repository locally :/
[00:14] <micahg> Resistance: apt-cacher-ng + sbuild FTW
[00:14] <micahg> ah, the patch is stacked, let me refresh it
[00:16]  * Resistance yawns
[00:16] <Resistance> well, i guess its time for another coffee run
[00:17] <Resistance> oh, micahg, i've got to poke you about bugsquad bug policies on Importance, a potential definition for "core" vs. "non-core" seems to have surfaced (but only two or three people have weighed in)
[00:18] <micahg> yeah, I"ll respond at some point as well
[00:19] <Resistance> well including my weighing in, the potential option we have on the table is define "core" as part of one of the default flavor packages, i.e. ubuntu-desktop, kubuntu-desktop, etc.
[00:19] <Resistance> but that's only one potential definition
[00:19] <micahg> backportpackage is being funny: 7.0.24+dfsg-1ubuntu0.1~ubuntu12.04.1~ppa1
[00:19] <Resistance> lool...
[00:19] <Resistance> lol*
[00:19] <micahg> Resistance: should hopefully build in ppa:micahg/sru-test at some point
[00:19] <Resistance> that is funny xD
[00:20] <Resistance> what did you set the urgency to, "low"?
[00:20] <Resistance> if so, my PPA's'll build long before yours
[00:20]  * micahg doesn't bother setting the urgency, let the queue do its thing
[00:21] <Resistance> yeah, mine'll build first then, unless somehow you got higher priority
[02:29] <bregma> do package updates in Debian get automatically synced to Ubuntu (assuming no changes) or is a sync request required?
[02:29] <LordOfTime> bregma:  syncs happen periodically on the dev release, but sometimes a sync request is needed.
[02:30] <micahg> bregma: with no Ubuntu changes, a sync request isn't needed until after Debian Import Freeze unless there's a reason
[02:30] <LordOfTime> ah, right
[02:30] <LordOfTime> :P
[02:30]  * LordOfTime forgot about freezes
[02:30] <LordOfTime> micahg:  check -bugs, please
[04:15] <bkerensa> micahg: do we/can we update packages that we sync from debian?
[04:15] <bkerensa> instead of waiting for debian to update the package?
[04:16] <micahg> bkerensa: yes, but if possible, better to work with the Debian maintainer to accomplish that goal if you care about it saying up to date
[04:16] <micahg> s/saying/staying/
[04:17] <bkerensa> kk
[12:17] <geser> has someone an idea what went wrong here? https://launchpadlibrarian.net/105319564/buildlog_ubuntu-quantal-i386.sift_4.0.3b-2ubuntu1_FAILEDTOBUILD.txt.gz
[12:44] <geser> argh, found the issue: the package compiles binaries, but replaced them later with pre-compiled once :(
[12:44] <jtaylor> lol
[12:44] <Laney> wtf
[12:51] <geser> and of course those binaries were x86-64 and me building on amd64 so I didn't catch this (the DD uploaded an amd64 deb too)
[17:00] <LordOfTime> hey micahg, that sru-test you asked me to do, apt-get is 404ing, did you build it for Precise? (for boinc)
[17:00] <LordOfTime> (in your PPA)
[17:02] <micahg> LordOfTime: yep
[17:02] <LordOfTime> that's odd
[17:02] <LordOfTime> because apt is 404ing on it then
[17:03] <LordOfTime> lemme remove it from my sources, and re-add
[17:03] <LordOfTime> this isnt the first time add-apt-repository's gone wonky for me
[17:04] <LordOfTime> ... woah......
[17:04] <LordOfTime> micahg:  i'm going to retract the backport / sru request, given that it wants to install a crapload of i386 stuff
[17:05] <micahg> huh?
[17:05] <LordOfTime> micahg:  it wants to install...
[17:05] <LordOfTime> 246 32bit packages
[17:05] <LordOfTime> just to install boinc
[17:05]  * LordOfTime thinks that that's somewhat overkill
[17:05] <LordOfTime> most of these are packages that already exist for the GNOME runtime
[17:05] <micahg> something seems not right
[17:05] <LordOfTime> indeed
[17:06] <LordOfTime> micahg:  https://pastebin.com/0A3ZyHf8
[17:06] <LordOfTime> EVIL HTTPS
[17:06] <LordOfTime> use it without https
[17:06] <LordOfTime> take a look at all it wants installede
[17:08] <micahg> LordOfTime: oh, right, we were discussing this yesterday in -devel :), boinc-client recommends ia32-libs
[17:09] <LordOfTime> *recommends*
[17:09] <LordOfTime> then why is this listing as dependencies
[17:09] <micahg> it's not
[17:09] <micahg> we install recommends by default
[17:09] <LordOfTime> ...
[17:09] <LordOfTime> bleh
[17:10] <LordOfTime> no offense, but IMO that's a bit rubbish... recommended packages arent necessarily dependencies, so what if someone didnt want the recommended packages
[17:10] <LordOfTime> (just to put that out there)
[17:11] <micahg> --no-install-recommends :)
[17:11] <micahg> The Recommends field should list packages that would be found together with this one in all but unusual installations.
[17:11] <Laney> or uninstall them, or apt-get install mycoolpackage myuncoolrecommendedpacakge-
[17:13] <LordOfTime> micahg:  the program installs and runs, but i'm running into more internet problems today, so i'm not going to be able to fully test this to see if that bug is gone
[17:13] <micahg> LordOfTime: ok, let me know when you can and I'll upload the SRU
[17:15] <LordOfTime> something's... not right... its not letting me set up my boinc user to here ...
[17:16] <LordOfTime> huh, you know what
[17:17] <LordOfTime> that explains it
[17:17] <LordOfTime> it segv'd in memory :/
[17:20] <LordOfTime> micahg:  i'm going to poke one of the people who had volunteered to test the backport, perhaps they can test the SRU, and they/I will get back to you
[17:20] <LordOfTime> because boinc refuses to work on my system (SIGSEGV in memory)
[17:21] <micahg> thanks
[17:25] <geser> Laney: should we update the section about handling of sync request in https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue (page linked from https://wiki.ubuntu.com/SponsorshipProcess)
[17:25]  * Laney sees something for the first time
[17:25] <LordOfTime> o.O
[17:26] <Laney> geser: looks like it could be updated and simplified indeed
[17:27] <Laney> and it probably doesn't want to be MOTU specific
[18:15] <highvoltage> broder: familiar with gimp at all? I have people at work and google+ who wants 2.8 on precise. I'm not sure how big it is or if it's to brave to take it on for a backport
[18:15] <highvoltage> (I guess I'll try it in a ppa and if it doesn't seem that complicated I'll try getting it in backports)
[18:15] <micahg> highvoltage: has quite a few rdeps
[18:15] <micahg> highvoltage: it should be in quantal by early next week
[18:16] <highvoltage> micahg: ok
[18:16] <broder> highvoltage: no familiarity. recruit the people who want it to do the rdep testing :-P
[18:16] <broder> oh my, that's quite a lot of rdeps
[18:16] <micahg> highvoltage: having said that, if we can get people to test the rdeps we can approve a backport (but the thing is, we'd want someone willing to smoke test the rdeps when we have security updates)
[18:17] <broder> eh, i still disagree with that
[18:17] <broder> (a) does gimp even have that many security updates?
[18:17] <broder> (b) i still think for security updates that we should only smoke the package itself, not the rdeops
[18:17] <micahg> 3 in the last year
[18:17] <broder> ugh
[18:17] <micahg> err 13 months
[18:18] <highvoltage> oh well, perhaps a ppa would suffice then
[18:18] <broder> in any case, i argue that the likelihood that a minimal security patch breaks an rdep is infinitesimal compared to the likelihood that a backport of a major release will
[18:18] <micahg> I'd be ok for partial rdep testing on the security backports (without major version changes)
[18:19] <broder> i've been talking about this for a while and not actually doing anything, so i guess i will send mail to the list and try to get it officialized'
[18:21] <micahg> we'll also need to backport from the next LTS when the time comes to get security updates for the life of precise
[18:22] <broder> no, we don't. security support for backports is best effort
[18:23] <micahg> I think that's for stuff we don't know more than stuff we do know
[18:24] <micahg> it is best effort, but to backport a package that's known to be CVE prone seems wrong (without some type of ongoing commitment from people)
[18:47] <highvoltage> gimp 2.8 also depends on a bunch of newer build dependences (libatk, libcairo2, libgdk-pixbuf2.0-dev, libwebkitgtk, python-dev...), I guess it was a bit optimistic to think that it would be easy :)
[18:49] <micahg> highvoltage: newer than precise?
[18:50]  * micahg is just aware of gegl being an issue
[19:24] <highvoltage> micahg: yep, the source package I have is from debian experimental
[21:49] <bobweaver> Hello there is there going to be a fix-it-Friday tomorrow ? IF so where is it located and what time. Thanks a ton !
[22:06] <geser> bobweaver: here and the whole friday and you don't need to wait on a fix-it-friday to fix bugs on a friday (or any other day of the week)
[22:09] <bobweaver> thanks a ton geser
[22:26] <pfifo> Hi, not sure whats up with the gnomebaker package for i386 precise... "This may mean that the package is missing, has been obsoleted, or is only available from another source" I hope its not being obsoleted, I need that package!
[22:48] <LordOfTime> micahg:  still around?