[00:25] <cjwatson> arayaq: That's similar to bug 1273487 - not the same symptom, but more or less the same cause.  I believe I've fixed this in launchpad-buildd now, so it should be sorted out at the next rollout, which I'm planning to organise later this week.
[00:25] <cjwatson> Thanks for the report.
[00:26] <arayaq> cjwatson: Thank you, so I cant build until the fix is rolled or is something I can do on my side to make it build?
[00:26] <cjwatson> arayaq: If it's urgent to work around it, then temporarily removing the diacritic from your display name on Launchpad (https://launchpad.net/~/+edit) should sort it out, though I fully understand if that's an unpalatable answer.
[00:27] <cjwatson> i.e. "Angel Araya" rather than "Ángel Araya"
[00:27] <cjwatson> Obviously it's unacceptable for us to restrict to ASCII-only displaynames though.
[00:27] <arayaq> cjwatson: I see! I'll go with the work around for now and revert back when the fix is out
[00:27] <arayaq> cjwatson: Thanks a lot!
[00:28] <cjwatson> You can subscribe to the bug above to be notified when it's fixed (it'll flip to Fix Released)
[00:35] <wgrant> Hm, I think that's rather a separate bzr-builder bug.
[00:35] <wgrant> aOh no
[00:35] <wgrant> Missed the enc arg, cjwatson's right.
[00:36] <cjwatson> Yeah, I tried out the failing bits of code in both environment-with-no-locale and environment-with-LANG=C.UTF-8
[00:36] <cjwatson> It goes back to the question of whether we should just set LANG=C.UTF-8 across the board, but this will do for now
[07:41] <jtaylor> is recipe building broken? I get an bzr error about quilt not being installed
[07:41] <jtaylor> https://launchpadlibrarian.net/180940457/buildlog.txt.gz
[07:48] <wgrant> jtaylor: Not all recipes, just those that are forced by bzr-builder from 3.0 (quilt) to 3.0 (native).
[07:48] <wgrant> But yes, it seems our new virtual builders don't have quilt installed. I'll get that fixed in a few hours, hopefully.
[08:53] <arun_> hi guys !!!
[08:53] <arun_> I needed a help in Launchpad.net please help me out
[08:57] <ersi> I might not be able to help at all, but what is the problem you're having? (It's usually better to ask the question you came to ask about, instead of asking if anyone can help)
[08:59] <mapreri> !ask
[08:59] <mapreri> :)
[09:01] <arun_> ersi: I was wanting to get bugtracker enabled in launchpad
[13:53] <mark06> can anyone help with https://answers.launchpad.net/launchpad/+question/249542 ? it simply can't be done? not even rm, or sql delete, or whatever?
[13:54] <mark06> look at what kind of thing it forces me to write: http://bazaar.launchpad.net/~renatosilva/pidgin++/trunk/view/head:/build/translations.sh :(
[14:01] <dobey> i really don't understand what you're complaining about
[14:02] <dobey> the filenames are not wrong
[14:20] <mark06> it's not the original po file
[14:21] <mark06> thus, the program doesn't know about this new translation, since it relies on the language code for some things
[14:21] <dobey> well, the original po files are allowed to be wrong
[14:21] <mark06> I need to run the script above on every merge
[14:21] <mark06> why allowed?
[14:22] <dobey> because you seem to be assserting that they are correct as if they are not allowed to be wrong, because they are pre-existing
[14:22] <mark06> hmm the Language: header?
[14:22] <dobey> why do you have ms_MY.po instead of ms.po?
[14:23] <mark06> I have no idea, only pidgin developers know
[14:23] <mark06> btw the Language header is ms for ms_MY but not my for my_MM, still LP exports to my.po, so that won't fix it
[14:25] <dobey> launchpad does not use the region specifier for po files unless it's absolutely necessary to do so
[14:25] <dobey> iow, there's no good reason to have ms_MY instead of just ms
[14:25] <dobey> and same with my_MM instead of my
[14:25] <mark06> ok so you're still into 'everything is just ok'?
[14:26] <mark06> I'm not asking tyo rename default name, if that thing ever exists, that would just move the problem to someone else
[14:26] <dobey> i'm saying that because pidgin is doing it wrong, and you're forking pidgin, blaming launchpad for being not pidgin isn't exactly a helpful solution
[14:26] <mark06> I'm asking to export foo.po to foo.po not bar.po, why ignore foo.po's name and use bar.po instead?
[14:29] <beaumanvienna> I've uploaded software to my launchpad PPA, but it doesn't show up on my profile. How can I see a build log?
[14:30] <cjohnston> beaumanvienna: how long ago did you upload? Did you get an accepted email?
[14:30] <beaumanvienna> I did check my mail. wait
[14:30] <mark06> beaumanvienna: "View package details" on the top right corner of your ppa page
[14:31] <cjohnston> beaumanvienna: depending on how long ago, it may be either pending or building..
[14:32] <cjwatson> beaumanvienna: Make sure you signed the upload.  Launchpad only sends any kind of reply to signed uploads, so if you forgot to sign it with a key that you have registered in Launchpad, you won't hear anything back.
[14:33] <beaumanvienna> I do have message from launchpad. It says Rejected: Unable to find distroseries: experimental
[14:34] <beaumanvienna> I signed it
[14:35] <dobey> you can only build for ubuntu distro series
[14:36] <mark06> beaumanvienna: where's your code?
[14:36] <dobey> so you need to specify utopic, trusty, etc… not the debian series names
[14:38] <beaumanvienna> Ahh, I get it. So http://slexy.org/view/s2Qk44cWD6 ?
[14:39] <mark06> beaumanvienna: yay :)
[14:39] <beaumanvienna> I have uploaded my code with dpit
[14:39] <beaumanvienna> I have uploaded my code with dput
[14:50] <beaumanvienna> I changed the entry in changelog to trusty, now it says: Package has already been uploaded to ppa on ppa.launchpad.net
[14:50] <cjohnston> probably need to bump the version number IIRC
[14:51] <beaumanvienna> I give it a try..
[15:00] <beaumanvienna> Upload successful, but in the mail: Rejected File mednafen_0.9.36.2.orig.tar.bz2 already exists in Primary Archive for Ubuntu, but uploaded version has different contents.
[15:03] <cjwatson> You aren't allowed to change a file with a given filename once it's been uploaded to a given archive.
[15:03] <cjwatson> Why did you change it?
[15:03] <mark06> beaumanvienna: can you simply delete the ppa? that would fix it
[15:03] <cjwatson> No
[15:03] <cjwatson> It's complaining about a mismatch with the version in the primary archive
[15:03] <mark06> cjwatson: he changed because of the above, the series
[15:04] <cjwatson> So rather than constructing that file however you did it, grab the version from the primary archive and build your source package against that
[15:04] <cjwatson> mark06: That doesn't require changing the .orig, and in any case this warning is about a mismatch with the primary archive, so deleting the PPA won't help
[15:04] <beaumanvienna> You mean by patching it?
[15:04] <cjwatson> No, I mean by fetching that file from the source package in Ubuntu
[15:05] <cjwatson> http://archive.ubuntu.com/ubuntu/pool/universe/m/mednafen/mednafen_0.9.36.2.orig.tar.bz2
[15:05] <beaumanvienna> I think so too, but where can I find the original? The latest version in Ubuntu is in Utopia with 0.9.33, not 0.9.36.2
[15:05] <mark06> cjwatson: why does it complain that the "Primary Archive" already has that version, no idea what's that
[15:05] <cjwatson> Launchpad won't allow you to build a PPA for Ubuntu with file names that conflict with Ubuntu proper
[15:05] <cjwatson> beaumanvienna: I just gave you the URL, which is in utopic-proposed at the moment.
[15:06] <mark06> cjwatson: I thought when you changed origs... it didn't try to overwrite them in the upstream repos???
[15:06] <cjwatson> mark06: Because it does, as I pointed to above.
[15:06] <beaumanvienna> Thanks!! So I can patch my version against it?
[15:06] <cjwatson> beaumanvienna: Just replace the version of that file in the parent directory of your unpacked source package with the one from Ubuntu, and rebuild the source package.
[15:07] <cjwatson> mark06: It won't try to overwrite the version in Ubuntu, but nevertheless having conflicting files of the very same name in an Ubuntu PPA and in Ubuntu itself would be very confusing, and possibly break some specialised use cases, so it's not allowed.
[15:07] <mark06> cjwatson: ah I see... it's odd that it didn't grab the latest version though
[15:07] <cjwatson> "it"?
[15:08] <mark06> it, when it fetched the source package then patched it for creating this new patched package
[15:08] <mark06> *when they
[15:08] <cjwatson> mark06: beaumanvienna constructed the source package
[15:08] <cjwatson> There's nothing automatic going on there
[15:08] <mark06> this is not from scratch
[15:09] <cjwatson> http://slexy.org/view/s2Qk44cWD6 implies it's from scratch
[15:09] <cjwatson> That
[15:09] <mark06> source (orig) has been fetched and only the diff is being uploaded, no?
[15:09] <cjwatson> 's not a changelog that would suggest that it's a modification of an existing package.
[15:09] <beaumanvienna> actualy it's not. It's just my first src code so I tried to keep things simple, sorry
[15:10] <cjwatson> mark06: All previous uploads were rejected for other reasons.
[15:10] <cjwatson> There was no need to bump the version number to avoid the "Package has already been uploaded" warning.  dput -f or removing the .upload file locally would have taken care of that, since Launchpad rejected the upload.
[15:10] <mark06> beaumanvienna: are you creating the package from scratch or did you download the source package then changed it?
[15:10] <beaumanvienna> OK guys, thanks for the moment, I will think about all this and figure it out!! Bye
[15:10] <cjwatson> As such, Launchpad didn't keep a record of the files there.  This new upload is effectively an attempt to upload it from scratch.
[15:11] <mark06> cjwatson: I'd assume that's just the top of the changelog
[15:11] <cjwatson> mark06: I wouldn't, given how it says "Initial release"!
[15:11] <cjwatson> Normally it's very badly misguided to repackage something from scratch, but lots of people do it.
[15:12] <beaumanvienna> My bad, I was going to include a complete changelog, but I tried to keep things simple
[15:12] <cjwatson> What would be simplest would be copying the perfectly good package that already exists :)
[15:13] <cjwatson> And not reusing a version number that's already been used in Debian
[15:14] <beaumanvienna> Ok, wait guys. The actual number I made my changes on is 0.9.36.2. So how do call my package with my changes then?
[15:15] <cjwatson> That's an upstream version number.  Surely you reused the existing packaging rather than doing it from scratch?
[15:17] <cjwatson> In which case you'd want to base on the version number of that packaging, and then follow https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
[15:22] <beaumanvienna> Got it. I must name it 'mednafen_0.9.36.2-ppa1', right?
[15:22] <beaumanvienna> I'll give this a try.
[15:30] <cjwatson> beaumanvienna: No, that doesn't look right.  What version of the existing packaging are you basing your work on?
[15:34] <beaumanvienna> It is based on version 0.9.36.2, I forked it on github, see https://github.com/beaumanvienna/mednafen-git
[15:35] <cjwatson> That's upstream, not packaging.
[15:35] <mark06> then you created the debian dir from scratch?
[15:35] <cjwatson> You shouldn't do your packaging from scratch - you should base it on the existing packaging in Ubuntu
[15:35] <cjwatson> Otherwise it's a total waste of time
[15:35] <cjwatson> "pull-lp-source mednafen" will fetch the latest
[15:35] <cjwatson> (but note, that will probably overwrite your current one, so do that in a scratch directory)
[15:36] <beaumanvienna> ok got your meaning. I'll try it. I took the latest version I found in Ubuntu, which is 0.9.33 in Utopic and changed it to my needs.
[15:36] <cjwatson> That's not the latest version in Ubuntu.
[15:37] <cjwatson> The latest version in Ubuntu is 0.9.36.2-2, as reported by rmadison / visible on Launchpad.
[15:37] <cjwatson> (It hasn't built yet, but that's due to an incompatibility with the latest libtrio, I think.)
[15:38] <mark06> https://launchpad.net/ubuntu/+source/mednafen
[15:38] <mark06> 36 is under proposed, 33 under release
[15:39] <mark06> that's the 'channel' and proposed is for testing, right?
[15:39] <cjwatson> Right, that's because 0.9.36.2-2 hasn't been able to build in utopic yet; but given that it's an incompatibility with the latest libtrio packaging, probably caused by libtrio converting to multiarch in utopic, it should build fine in trusty.
[15:39] <cjwatson> channel> misleading
[15:40] <cjwatson> -proposed is part of our continuous integration system, essentially, so we don't put things into utopic until they've built and passed certain tests
[15:40] <cjwatson> https://wiki.ubuntu.com/ProposedMigration
[15:40] <mark06> beaumanvienna: whenever you want to patch something that already exists in ubuntu, it's *highly recommended* (not exactly required) that you patch the ubuntu package, instead of trying to re-package from scratch
[15:40] <cjwatson> however, if you just want the latest source code, fetch the latest rather than worrying about whether it's in -proposed or not
[15:40] <cjwatson> especially if the alternative is doing it from scratch!
[15:40] <cjwatson> if you then need to modify it further, then 0.9.36.2-2ppa1 would normally be a sensible version number to use
[15:40] <beaumanvienna> Wait, wait.
[15:41] <mark06> beaumanvienna: this is because someone else already did all the hard work for integrating that piece of software into ubuntu (the patches), and already has applied important security fixes and is going to maintain these *for you*
[15:42] <mark06> hmm channel is universe, multiverse, main etc right?
[15:43] <mark06> dobey: I've reported bug 1349885, but thanks anyway :)
[15:44] <beaumanvienna> I would like to branch from version 0.9.36.2. Why do I have to branch from the latest version?
[15:44] <beaumanvienna> In the project I work with we have my custom made version for some weeks in deployment, it's perfect, no need to take the latest source
[15:45] <mark06> beaumanvienna: because of what I said above, you have to choose between that (which is currently available only for 33) or doing that *yourself*....
[15:46] <beaumanvienna> OK, I'll do it by myself! Thanks!
[15:47] <mark06> omg!
[15:47] <mark06> will they guess http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/mednafen/utopic/files/head:/debian/patches/
[15:53] <bennabiy> Is anyone else suddenly experiencing failed builds, as of yesterday?
[15:53] <bennabiy> because of missing quilt dependency?
[15:56] <cjohnston> bennabiy: it should be either already fixed or inprogress. cjwatson ^
[15:57] <bennabiy> thank you
[15:58] <cjwatson> Right, William was working on that with IS
[15:58] <cjwatson> This is just for a subset of recipe builds
[15:58] <cjwatson> bennabiy: Do you have a recent failed build?
[15:58] <bennabiy> let me check
[15:58] <bennabiy> I did as of last night
[15:58] <cjwatson> Recent> last couple of hours
[16:00] <bennabiy> let me try again
[16:02] <bennabiy> failed.. https://launchpadlibrarian.net/180992994/buildlog.txt.gz
[16:16] <cjwatson> bennabiy: OK, so we've landed the patch to fix this, I think we're just waiting for a cronned update of the base image now
[16:17] <bennabiy> ok
[16:17] <cjwatson> bennabiy: this system is so brand new I don't know the frequency yet
[16:18] <cjwatson> literally a complete replacement of the virtual builder infrastructure
[16:38] <bennabiy> Can you let me know when to try again?
[16:41] <cjwatson> bennabiy: Yep, hang around here
[17:04] <bennabiy> will do
[17:09] <shadeslayer> idk what you guys did, but Launchad now builds firefox in ~2 hours, and I'm extremely happy about that :D
[17:18] <cjwatson> shadeslayer: is that in a virtual PPA?
[17:19] <cjwatson> Yep, looks like it
[17:19] <cjwatson> That'll be scalingstack :)
[17:23] <shadeslayer> cjwatson: virtual PPA?
[17:24] <shadeslayer> I'm assuming all PPA's are Virtual
[17:24] <shadeslayer> https://launchpad.net/~rohangarg/+archive/ubuntu/firefox is the one I was talking about
[17:24] <cjwatson> shadeslayer: no, some special ones are "devirtualised" and build on the distro farm, but anyway, yeah, I found it, this is virtualised
[17:24] <shadeslayer> but quite happy that I don't have to wait 8 hours for a build :D
[17:24] <cjwatson> and I mostly meant PPA rather than an upload to Ubuntu
[17:24] <shadeslayer> right
[17:25] <cjwatson> right, so we (i.e. mostly not me) finally deployed the new replacement for the virtualised builder infrastructure that's been in development for a year or two
[17:25] <cjwatson> openstack-based, trusty base system, possibly more disk/ram per guest into the bargain
[17:26] <cjwatson> appears to not have guests fall over every five minutes
[17:26] <cjwatson> which is nice
[17:26] <shadeslayer> so the builders aren't running warty anymore? :D
[17:26] <cjwatson> hardy, but yeah
[17:26] <shadeslayer> ah, heh :P
[17:26] <shadeslayer> sweet
[17:29] <cjwatson> shadeslayer: in your case I suspect it's just extra RAM or something making a difference; don't know the exact specs involved ...
[17:29] <cjwatson> bennabiy: can you retry now?
[17:29] <shadeslayer> ok, whatever it was, it was awesome ^_^
[17:29] <bennabiy> sure.
[17:30] <bennabiy> running...
[17:30] <cjwatson> yep, I see it
[17:30] <bennabiy> Seems like my build is starting quicker, but is that just because of the switchover?
[17:30] <cjwatson> Pretty much, we have better capacity now it seems
[17:31] <cjwatson> Roughly the same number of builders, but they fail less often and apparently they're quicker in some cases, so I haven't seen any backlog since we switched
[17:31] <bennabiy> failed https://launchpadlibrarian.net/181000140/buildlog.txt.gz
[17:31] <cjwatson> hm, I'll get back to the sysadmin who was helping me
[17:31] <bennabiy> ok thank you :)
[17:32] <bennabiy> I will stick around to try again
[17:32] <bennabiy> just alert me by name :)
[17:32] <cjwatson> yeah, just don't want to push you over your daily recipe build limit unnecessarily
[17:38] <sergio-br2> hey
[17:39] <sergio-br2> can i use # bzr-builder format 0.3 deb-version {debupstream}-0~{revdate} ?
[17:41] <dobey> sergio-br2: i don't see why not, though personally i've started avoiding having - in the version string in recipes
[17:42] <sergio-br2> dobey, why?
[17:43] <cjwatson> bennabiy: try now
[17:43] <bennabiy> ok
[17:43] <cjwatson> (glitch in the upgrade procedure)
[17:43] <dobey> sergio-br2: for a while lp was more strict because newer dpkg was being more strict, and since recipe builds amount to being native packages in the eyes of dpkg, it made sense to not have -
[17:44] <bennabiy> one thing that would be nice to have is an auto refreshed page so I do not need to keep refreshing the page to see my build progress
[17:44] <dobey> sergio-br2: so i just use {debupstream}+r{revno} generally, for actually native packages, and tack on a ~{revno:packaging} if it's something i have to nest a separate packaging branch into
[17:45] <sergio-br2> this revno gets the bzr commits?
[17:46] <cjwatson> bennabiy: yeah, I'd like to hook that up for builds, but enotime, and the auto-refresh mechanism in LP has some limits at the moment anyway ...
[17:46] <dobey> sergio-br2: yes, it's the value of "bzr revno" against the branch
[17:46] <bennabiy> fair enough
[17:46] <cjwatson> bennabiy: there you go, success
[17:46] <bennabiy> yes
[17:46] <bennabiy> thank you
[17:47] <bennabiy> I have thought about building my own launchpad / builder just for local stuff, but have yet to do it
[17:48] <dobey> setting up sbuild to build locally is pretty easy
[17:48] <bennabiy> I need something local, as I have projects that are not public domain, which I would not want to host on launchpad
[17:50] <cjwatson> sbuild is local
[17:50] <cjwatson> https://wiki.ubuntu.com/SimpleSbuild
[17:53] <sergio-br2> dobey, so it's not good to use revdate to iterate the version? I remember that i got an error with this thing
[17:54] <dobey> sergio-br2: you can use a date if you want, but i don't know what error you got or what revdate means exactly
[17:54] <dobey> sergio-br2: i prefer the revno, because it's a more accurate description of what you're building
[17:55] <dobey> sergio-br2: the date doesn't really tell you which revision the build was from, as more revisions could have landed after the build, on that date
[17:55] <sergio-br2> the thing is that i imported a code from github, then i don't know if it make sense using the bzr number to iterate
[17:55] <sergio-br2> humm, right
[17:56] <sergio-br2> it makes sense
[17:56] <dobey> sergio-br2: the bzr revno still makes sense, because you can track it to the specific revision in bzr, and then track that to the specific revision in git
[17:56] <dobey> it only breaks if upstraem does something stupid and deletes existing revisions in the master branch
[17:56] <dobey> (which, sadly, some people actually do quite often)
[17:57] <sergio-br2> ok
[17:57] <sergio-br2> so deb-version {debupstream}-0~{revno} is good
[17:58] <dobey> i would do {debupstream}+r{revno}
[17:58] <sergio-br2> why in the end the package got a .1 in the name? like 0.9.9.git.20140727.1~ubuntu14.10.1
[17:59] <cjwatson> hardcoded in launchpad-buildd for some reason I meant to track down but was sort of scared of changing in case it broke things
[17:59] <sergio-br2> this .1 is not used for iterate
[17:59] <dobey> the -0 doesn't tell you anything useful, and if the debupstream is the same version as already in ubuntu, the package will appear older than what's in ubuntu, even if it's newer
[17:59] <cjwatson> I think it's a bug, but it doesn't really matter
[17:59] <dobey> yeah i wouldn't worry about that. lp appends the series to all recipe builds automatically
[17:59] <sergio-br2> it's annoying me :p
[18:00] <dobey> find a new annoyance :)
[18:00] <dobey> or just build it for trusty, then the .1 will "mean" something ;)
[18:01] <sergio-br2> rsrs
[18:04] <yofel> Big thanks to everyone that worked on the build buildds, they're amazing! :D
[18:04] <yofel> *new buildds
[18:05] <cjwatson> I've passed it on :)
[18:25] <sergio-br2> i got this error: http://pastebin.com/6BxQqQbQ
[18:27] <cjwatson> Please always link to the build on LP rather than pastebinning its log
[18:28] <cjwatson> https://code.launchpad.net/~libretro/+archive/ubuntu/testing/+recipebuild/763395 apparently
[18:28] <cjwatson> sergio-br2: Your recipe doesn't include any branch that contains any packaging.
[18:33] <sergio-br2> {debupstream}+r{revno:Genesis-Plus-GX}  ?
[18:33] <sergio-br2> the code is https://code.launchpad.net/~libretro/libretro/Genesis-Plus-GX
[18:35] <sergio-br2> "Replaced by the revision number of the branch you specify, using the short name specified elsewhere in the recipe."
[18:35] <sergio-br2> so id is Genesis-Plus-GX?
[18:37] <sergio-br2> cjwatson, why i need to specific branch? This is in the recipe too:  lp:~libretro/libretro/Genesis-Plus-GX
[18:38] <dobey> sergio-br2: what you need is a debian/ directory
[18:39] <dobey> sergio-br2: it can either be in the upstream branch, or you can create a new branch with its contents, and nest it in the recipe
[18:40] <sergio-br2> ahh, i completely forgot that debian/ is inside libretro/
[18:41] <sergio-br2> stupid me
[18:54] <sergio-br2> what's the difference between nest and merge?
[18:56] <dobey> nest grabs the branch in a subdir, merge is a merge (same as bzr merge otherbranch)
[18:57] <dobey> i find just having the contents of debian/ in a branch and nesting it is easier to deal with, for recipes that are building upstream branches which don't have a debian/ dir
[19:00] <sergio-br2> so, i need to have only the debian/ folder in a branch?
[19:02] <dobey> sergio-br2: can you see https://code.launchpad.net/~dobey/+recipe/ardour-dailies ?
[19:04] <dobey> https://bazaar.launchpad.net/~dobey/ardour/packaging-dailies/files for example, is nested with "nest packaging lp:~dobey/ardour/packaging-dailies debian" in the recipe
[19:05] <sergio-br2> great
[19:05] <sergio-br2> good example
[19:07] <sergio-br2> in "nest packaging ..." , this packaging is a reference to {revno:packaging} ?
[19:08] <sergio-br2> ah, it's a a short name
[19:09] <dobey> it's the symbolic name, which is referenced in the veresion string variable, yes :)
[19:10] <sergio-br2> but i need to use this?
[19:10] <sergio-br2> hum, it's good to know what revision in the package, right?
[19:16] <dobey> yes, it's good to know what revision of the packaging you are using, if it is a separate branch from the upstream branch
[19:17] <sergio-br2> in my case
[19:17] <sergio-br2> # bzr-builder format 0.3 deb-version {debupstream}+r{revno}.{revno:packaging}
[19:17] <sergio-br2> lp:~libretro/libretro/Genesis-Plus-GX
[19:17] <sergio-br2> nest packaging lp:~libretro/libretro/Genesis-Plus-GX-debian debian
[19:17] <dobey> if someone complains about a packaging issue, you can use the version number of the package they have installed to cross reference it with the branch and see what changed or needs changing
[19:17] <sergio-br2> this should work?
[19:17] <dobey> it will work, but i would use ~ instead of . there
[19:18] <sergio-br2> {debupstream}+r{revno}~{revno:packaging}
[19:18] <dobey> right, that's what i use in my recipes
[19:19] <sergio-br2> great
[19:20] <sergio-br2> ok, it will be good to automate retroarch and core builds
[19:31] <sergio-br2> i'm having problem with quilt patch: https://launchpadlibrarian.net/181006003/buildlog.txt.gz
[19:32] <cjohnston> sergio-br2: that's an old build correct? (more than an hour or two)
[19:33] <cjohnston> sorry.. now I see what I think is the proper timestamp
[19:33] <sergio-br2> it's other package
[19:33] <sergio-br2> it's the last build
[19:34] <sergio-br2> funny, this quilt patch works here, even with debian/ folder inside retroarch code
[19:34] <sergio-br2> *here in my machine
[19:34] <cjohnston> cjwatson: ^
[19:35] <sergio-br2> forget
[19:35] <sergio-br2> i think there are some files missing yet, in the repo
[19:37] <bennabiy> what is with this...     You have exceeded today&#x27;s quota for ubuntu utopic, ubuntu trusty, ubuntu precise. ?
[19:37] <bennabiy> I have never had a limit on being able to build my package
[19:38] <bennabiy> is this new?
[19:38] <sergio-br2> me?
[19:41] <bennabiy> cjwatson: Is there now a limit on how many builds can be done in a day?
[19:43] <sergio-br2> 5 builds each ubuntu version
[19:43] <sergio-br2> yeah, I already had this problem
[19:47] <bennabiy> bah, can someone reset it? I used up my builds troubleshooting the issue with launchpad!
[19:48] <dobey> bennabiy: the quota exists because people keep wasiting resources trying to constantly rebuild broken packages as they try to learn how to package things. you should test builds locally with sbuild before uploading a package to a PPA
[19:49] <bennabiy> dobey: my package was fine. It was launchpad which was broken
[19:49] <bennabiy> and I kept rebuilding to help cjwatson track down the issue with quilt
[19:49] <dobey> how so?
[19:49] <bennabiy> and now I cannot actually rebuild it when I need to.
[19:51] <dobey> bennabiy: i think you'll need to ask cjwatson about that if/when he returns then (it's getting late over on that side of the atlantic)
[19:51] <dobey> or if wgrant appears soon, he might be able to help with that
[19:51]  * bennabiy sighs
[19:51] <dobey> i can't do anything about the quota, sorry
[19:52] <bennabiy> thank you dobey
[19:52] <cjohnston> cprov: any thoughts ^
[19:53] <cprov> cjohnston: no, sorry, you need an lp-admin for that
[19:54] <cjohnston> ack
[19:55] <bennabiy> Well, if one shows up. I would appreciate it. Otherwise, is there a way to patch the files on my machine, and then upload the revisions?
[19:59] <cjwatson> the quota is hardcoded in LP code
[19:59] <cjwatson> but you can build again tomorrow
[19:59] <cjwatson> this is why I test-built myself after the first time ...
[20:00] <cjwatson> sorry for the inconvenience, but it should just be for today
[20:00] <cjwatson> it's only recipes.  Ordinary PPA uploads have no quota
[20:00] <cjwatson> so you can certainly grab the source package from the recipe-target PPA, modify, reupload
[20:05] <LiamW> how can I sort bugs by importance, then by age?
[20:06] <LiamW> I want to have "Triaged" bugs appear first, ordered by their age
[20:06] <LiamW> then "Confirmed," etc
[20:07] <LiamW> can I do this by just browsing on the website or will I need to use something like launchpadlib to do that?
[20:07] <dobey> isn't that just how it works on the web site?
[20:09] <dobey> oh, i guess you can't explicitly say "triaged first" on the web site
[20:09] <dobey> it will show fix committed and in progress bugs above triaged bugs
[20:09] <LiamW> you can probably hide fixcommitted bugs from the listing
[20:09] <dobey> yes, with an advanced search
[20:17] <bennabiy> cjohnston, cjwatson : thank you