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