=== wgrant_ is now known as wgrant
=== Resistance is now known as EvilResistance
=== EvilResistance is now known as Resistance
=== Resistance is now known as EvilResistance
=== EvilResistance is now known as Resistance
=== FlannelKing is now known as Flannel
=== MTecknology is now known as nginx
=== nginx is now known as MTeck
=== MTeck is now known as MTecknology
=== Ng_ is now known as Ng
=== almaisan-away is now known as al-maisan
[09:09] <tbf> hi, anyone knows how to deal with such warnings when building a package?
[09:09] <tbf> dpkg-gencontrol: Warnung: Paket qtgstreamer-plugins: unknown substitutions variable ${gstreamer:URISources}
[09:16] <geser> tbf: try to figure out if something is missing (something should fill that variable with data) or if you can ignore it (the package doesn't really need that variable)
[09:31] <elky> did python-docutils start reporting language with the full language name, eg, spanish rather than shortcode, eg, es, between oneiric (0.7-2) and precise (0.8-1)
=== al-maisan is now known as almaisan-away
[13:02] <aboudreault> guys. how comes a apt-get install libpng12-dev install the libpng.so in /usr/lib/x86_64 ? and nothing in /usr/lib? This will cause a lot of software  configure to fail.. no?
[13:03] <Zhenech> no
[13:03] <Zhenech> unless it is literally looking for /usr/lib/libpng.so
[13:03] <Zhenech> and not for libpath/libpng.so
[13:05] <aboudreault> it is literrally looking for $PREFIX/libpng.so
[13:05] <aboudreault> I suppose I would have to fix that
[13:06] <Zhenech> but prefix is /usr? not /usr/lib, so it wouldnt find it anyways? :)
[13:09] <Resistance> any MOTU or SRU team member available to outline the update procedure for how a bug/program would get updated in Precise *on that bug*?  I'm not SRU or MOTU, so the people on the bug hearing it from one of you guys would probably help a lot for their understanding.
[13:12] <Resistance> that outlining would probably best be put on LP Bug 991179 (since the Debian devs are trying to get this direct to Precise, which is a no-no without an SRU)
[13:12] <ubottu> Launchpad bug 991179 in boinc (Ubuntu) "7.0.24 "computation error" bug" [Medium,Confirmed] https://launchpad.net/bugs/991179
[13:15] <geser> Resistance: not Evil anymore? :) you'll probably have more luck to find a SRU member in #ubuntu-devel (most SRU members are core-devs) once they are back from UDS (next week)
[13:15] <geser> or travel to UDS and discuss it with them in person :)
[13:25] <Resistance> geser:  that's also why I said MOTU
[13:25] <Resistance> MOTUs are aware of the steps in the process about as much as an SRU might
[13:25] <Resistance> (at least as far as i've observed)
[13:25] <Resistance> and my nick isn't evil right now, but it might end up that way later ;P
[13:26] <Resistance> and the package in question is Universe, so... :P
[13:30] <Resistance> geser:  i also spoke to one of the SRU team last night here on IRC, i've only got the summary of what's expected to update/fix that bug, not the entire process, hence the request :)
[13:34] <geser> Resistance: what was the outcome about fixing quantal first? given that boinc doesn't compile there at the moment
[13:39] <Resistance> geser:  that's what i've said, i want a MOTU or an SRU member to corroborate
[13:39]  * Resistance only has summaries, not all the details
[13:40] <Resistance> i'll poke the SRU team, probably this Sunday or Monday, they can outline the entire process
[13:42] <Resistance> (although when I spoke to cjwatson, he outlined what i've said on that bug, so i'm regurgitating informatoin that i have, but not giving the full details since I don't know those)
[13:44] <Resistance> i think the confusion is coming from the Debian side, they assume Precise is like sid, you can just easily get it in, but there's the whole SRU thing that sid doesn't have :P
[13:48] <geser> Resistance: preparing a SRU isn't that difficult (once one has the patch to fix it): it's mostly adding a TEST CASE to the bug description (explaining how to test that the proposed fix really fixes it) and the patch (ideally in debdiff format for easier sponsoring) that someone with upload rights can upload
[13:49] <Resistance> geser:  true, but the program with the fix (in Debian) doesn't build for Quantal.
[13:49] <Resistance> and according to cjwatson, they'd like a working version in Quantal first
[13:49] <Resistance> because if you update precise but not quantal, what's the advantage then
[13:49] <Resistance> (considering the updated version that would fix this doesn't build in Quantal)
[13:51] <Resistance> and since this isn't a critical bug, i dont really see a reason to push for the "Precise but not Quantal" angle of things.
[13:52] <geser> the tricky part is if there isn't a simple patch which needs to get applied (e.g. fixed in a newer upstream version)
[13:52] <Resistance> that is the issue
[13:52] <Resistance> since the intermediary versions between 7.0.24 and the version in Debian don't exist
[13:53] <Resistance> at least not in Debian or Ubuntu
[13:53] <Resistance> as well, there's actually *two* bugs now, from what I've gathered, where pre-7.0.27 doesn't work with graphics cards with > 2GB RAM (For those who use their graphics card as processor memory, i.e. CUDA)
[13:54] <Resistance> the bug that's affecting precise current version is a buggy patch (which can easily be removed), but the second bug (more critical in the Debian maintainers' eyes) is only addressed in a upstream version update (i.e. 7.0.27)
[13:54] <Resistance> if Precise were still in development, I'd have filed a sync request and gotten it FFe'd
[13:54] <Resistance> then this problem wouldnt exist :P
[13:56]  * Resistance yawns
[13:56] <Resistance> y'know, if this existed in Quantal (7.0.27), I'd have just filed a backport request, tested the backport(s) myself, and then if that all worked, everything would be fine and dandy :p
[13:57] <geser> Resistance: I don't if it would be acceptable to sync the fixed package to quantal knowing that it will FTBFS (but at least we'll have the fix once the FTBFS get resolved)
[13:57]  * Resistance forgot what FTBFS means, and goes to look that up
[13:57] <geser> Fails To Build From Source
[13:57] <Resistance> ah, fails to build from source
[13:57] <Resistance> yeah, just looked it up :P
[13:58] <Resistance> well, that's why i've been holding off on filing the sync request
[13:58] <Resistance> the last, oh...
[13:58] <geser> then you could backport it to precise (where it would build)
[13:58] <Resistance> i want to say four requests i had for Precise when it was in dev were initially refused because it failed to build
[13:59] <Resistance> but then i dug around and found that problem was caused by some oddball issue with a build-dep, adn removing that fixed it all
[13:59] <Resistance> (then the sync/backport was accepted with ubuntu-changes)
[13:59] <Resistance> i'm hesitant to act and file a request *given* the FTBFS
[13:59] <geser> new upstream versions are usually backported, it's not easy to get new upstream versions accepted for SRUs
[13:59] <Resistance> mhm
[14:00] <Resistance> i'll probably note that, but I'd ideally like to see this fixed in Quantal
[14:00] <Resistance> but again, given i'm not on SRU, or MOTU, I'm not going to file that sync request :P
[14:00]  * Resistance goes to dig up the bug link again
[14:01] <geser> I'll try to check if it's easy to fix boinc building in quantal or not when I'm home
[14:03] <geser> Resistance: if it's Debian bug #671999 then it should get fixed in Debian in 2 days (uploaded to the 2 days delayed queue in Debian) and you might be able to file a sync request next week :)
[14:03] <ubottu> Debian bug 671999 in src:boinc "boinc: FTBFS: ../tools/process_input_template.cpp:86:23: error: 'unlink' was not declared in this scope" [Serious,Open] http://bugs.debian.org/671999
[14:04] <Resistance> possibly, i'll check with them, but given that my quantal chroot keeps going *pbbt* *fizzle*, i'm not willing to test ;P
[14:10] <Resistance> ohey, didnt realize you were a motu, geser
[14:10]  * Resistance looked up your info on LP
[14:10] <Resistance> question, then: would you support a sync to Quantal of that package, if the FTBFS issue still exists, just for the purposes of backporting that to Precise?
[14:11] <Resistance> if it were up to you
=== almaisan-away is now known as al-maisan
[14:36] <geser> probably yes
=== bigon_ is now known as bigon
=== chris_ is now known as Guest1762
=== al-maisan is now known as almaisan-away
=== roaksoax_ is now known as roaksoax
=== debfx_ is now known as debfx
[17:32] <broder> micahg: i know we talked about killing off maverick backports bugs, but it's more complicated than that. if they want a backport to lucid, do we drop the natty/oneiric backports, too?
[17:32] <micahg> broder: nope, you can backport for any one of natty, oneiric, precise IMHO to lucid
[17:33] <broder> nono, i mean that if you have a precise->lucid backport
[17:33] <broder> we would have opened l/m/n/o tasks
[17:33] <broder> should we drop n and o when we drop m?
[17:33] <micahg> ah, yeah, in that scenario, yes
[17:33] <micahg> broder: well, hold on
[17:33] <broder> i wish we had a better way to convey intent
[17:33] <broder> like, i open bugs where the goal is explicitly "backport to EVERYTHING"
[17:33] <broder> but i think that's often not the case
[17:33] <micahg> broder: ask if the requester wants the natty/oneiric backports still
[17:34] <broder> yeah, sure
[17:34] <micahg> we don't have too many of those, so I'm fine with manual processing once we get a response (set to incomplete so they can expire maybe)
=== almaisan-away is now known as al-maisan
=== nxvl_ is now known as nxvl
=== al-maisan is now known as almaisan-away
=== pawdro_ is now known as pawdro
=== EvilResistance is now known as Resistance
[21:53] <broder> ok. backporters, get your mail filters ready. i'm going to go close out maverick-backports bugs
[22:11] <broder> (done)
[22:11] <broder> will do a followup sweep in a bit to get backports *from* maverick
[22:37] <ajmitch> broder: I got your warning about email too late, now my lp mail is full of backports spam :)
[22:37] <broder> muahaha
[22:38] <Laney> T~N;WN
[22:38] <Laney> :-)
[22:39] <ajmitch> pretty much
[23:13] <asomething> MOTU BoF in #ubuntu-uds-room-202
[23:50] <broder> tumbleweed: you fixed my backportpackage bug! "./gnome-do-precise already exists. Delete it? [y|N]? y"
[23:51] <highvoltage> nʇoɯ ollǝɥ
[23:51] <Laney> gah
[23:53] <crjon> Hello, I am new here and I am trying to get involved with some projects to get coding experience, anyone able to help out
[23:53] <micahg> hi cjwatson
[23:53] <micahg> cjwatson: umping
[23:53] <micahg> hi crjon
[23:54] <highvoltage> hey crjon
[23:54] <micahg> crjon: here's a link to a site where you can find lots of opportunities to fix bugs: http://harvest.ubuntu.com/
[23:54] <Resistance> gah, microflood o.O
[23:55] <crjon> hey everyone thanks for the site, I am checking it out