[05:27] <Noskcaj> there's a lot of builds that failed to upload at http://qa.ubuntuwire.org/ftbfs/ , can someone take a look?
[08:59] <cjwatson> Noskcaj: hmm
[09:00] <cjwatson>   Module lp.archiveuploader.uploadprocessor, line 667, in process
[09:00] <cjwatson>     [changes_file] = self.locateChangesFiles()
[09:00] <cjwatson> ValueError: need more than 0 values to unpack
[09:00] <cjwatson> WTF
[09:01] <cjwatson> Noskcaj: Oh, OK, this is a consequence of a recent launchpad-buildd regression (my fault), bug 1235038
[09:02] <cjwatson> Noskcaj: Just ignore them and treat them as if they were "Package is waiting on another package" for now
[09:02] <Noskcaj> ok, so they should all be ready by release?
[09:03] <cjwatson> Noskcaj: You misunderstand; those packages won't build either way, it's just the wrong error
[09:03] <cjwatson> Noskcaj: They're stuck on something else that's unavailable on the architectures in question
[09:03] <Noskcaj> oh, ok
[09:03] <smartboyhw> cjwatson, ew, now ardour3 sync causes i386 to FTBFS:(
[09:03] <cjwatson> (For the most part)
[09:04] <cjwatson> smartboyhw: Well, you wanted to ram this in late in the cycle ;-)
[09:04] <smartboyhw> cjwatson, well, I didn't expect that sync which fixes armhf and powerpc FTBFS i386 (only)
[09:04] <smartboyhw> Should have reverted:(
[09:04] <smartboyhw> I didn't request it myself
[09:05] <cjwatson> No need to revert, it's not problematically broken in the release pocket
[09:05] <smartboyhw> cjwatson, ah yeah:)
[09:05] <cjwatson> You have time to figure it out properly
[09:06] <cjwatson> Noskcaj: This will be fixed well before release in time to get all the build states into the correct kind of failure, though
[09:06] <cjwatson> I expect we'll roll out the fix next week (thereby annoying sysadmins even more, but there)
[11:12] <Laney> smartboyhw: seems possibly fixed in git, checking
[11:12] <smartboyhw> Laney, it is possibly fixed
[11:13] <smartboyhw> I'm just waiting for an actual release from Debian...
[11:15] <Laney> takes ages to build
[11:28] <smartboyhw> Laney, :(
[11:32] <lenios> how would you remove the executable-not-elf-or-script lintian warning on a package? i have a lot of png and js files and a few php files with this and i'm not sure of the best way to clean this up
[11:40] <jtaylor> chmod u-x file
[11:42] <cjwatson> just -x, u-x is unnecessarily specific
[11:42] <jtaylor> right
[11:42] <cjwatson> except in the rather unlikely event that *only* the owner has exec permissions
[11:43] <jtaylor> muscle memory from chmod u+x :)
[11:43] <Laney> smartboyhw: it built
[11:44] <Laney> shall I upload it?
[11:44] <smartboyhw> Laney, \o/
[11:44] <smartboyhw> Yes please
[11:44] <Laney> Build needed 00:44:16, 1345940k disc space
[11:44] <Laney> come on laptop refresh
[11:44] <lenios> question would be where to do the -x
[11:46] <cjwatson> probably immediately after the upstream make install
[11:46] <cjwatson> e.g. perhaps in a dh_auto_install override
[11:46] <cjwatson> (in debian/rules)
[11:46] <lenios> what about overriding dh_fixperms?
[11:47] <cjwatson> I wouldn't; it's probably not the thing that's wrong
[11:47] <cjwatson> alternative: add a patch to the upstream build system to fix their foolish code installing it with exec perms
[11:47] <smartboyhw> Laney, you're uploading it through Debian or Ubuntu?
[11:47] <Laney> U
[11:47] <lenios> i can't control the upstream build system, but i can try to submit them a patch
[11:47] <Laney> I'm guessing the maintainer will upload it to Debian soon enough
[11:48] <smartboyhw> Laney, agreed
[11:48] <cjwatson> I mean, you obviously *can* override dh_fixperms for it, I just think it's no more sensible a place than e.g. overriding dh_installman
[11:48] <cjwatson> lenios: eh, you can surely patch it in your package
[11:48] <cjwatson> it might not be the easiest way, depending on the situation, but I've done that in the past
[11:49] <lenios> oh yes, i can patch it
[11:49] <lenios> that will need to be redone on each new package, but still
[11:49] <cjwatson> rebasing patches isn't normally that hard
[11:50] <cjwatson> like I say, not necessarily the best way depending on your situation, but it's an option.  if you do it in debian/rules I would recommend it be somewhere immediately after and clearly associated with the buggy upstream installation code (if indeed that's where the bug is)
[13:21] <smartboyhw> Laney, thank you, now all architectures build and is now in -release.
[13:22] <Laney> happy days
[13:22] <smartboyhw> Laney, I need a FFe for the ardour3 inclusion in ubuntustudio-meta right?
[13:23] <Laney> Not sure
[13:23] <Laney> probably OK if the flavour developers want it
[13:24] <Laney> Got to go now
[13:24] <smartboyhw> Laney, ouch
[13:24] <smartboyhw> Just want you to ack the bug-.-
[13:30] <lenios> i asked upstream about the executable-not-elf-or-script warning, and they fixed it with a commit and now no more warnings :)
[13:31] <lenios> https://mentors.debian.net/package/phabricator if someone is interested in sponsoring it
[13:34] <smartboyhw> lenios, ask in #debian-mentors on OFTC:P
[13:34] <lenios> that would be a good idea :p
[18:23] <jokerdino> any sponsors around? need to upload a bug fix for unity-tweak-tool
[21:03] <chilicuil> hello, I'm interested in getting a new package for ubuntu saucy (probably by now too late?), I've gone through debian (mentors) and created the package, now I think is ready, however a week has gone and no one with permition to debian have look at it, I wonder if some one here can do it, and approve it or reject it, http://mentors.debian.net/package/youtube-cli / http://lists.debian.org/debian-mentors/2013/09/msg00299.html
[22:24] <solirc> Hi!
[22:25] <solirc> I'm just getting started with PPAs and UDD.
[22:25] <solirc> And I manage to upload a custom version of ghc.
[22:26] <solirc> Not I'd like to do the same thing for cabal-install, but `bzr branch ubuntu:cabal-install` fails with
[22:26] <solirc> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/cabal-install/".
[22:26] <solirc> s/Not/Now
[22:28] <solirc> Ah, it is `bzr branch ubuntu:haskell-cabal-install`
[22:29] <solirc> even though the package is named `cabal-install`
[22:29]  * solirc looks entirely puzzled