=== jelmer_ is now known as jelmer
=== jpds_ is now known as jpds
=== jpds is now known as Guest15370
=== Guest15370 is now known as jpds_
[09:33] <jhobbs> Hello - a bug i was trying to edit just disappeared
[09:34] <jhobbs> When I try to use the question feature in launchpad I get an OOPS
[09:34] <jhobbs> the bug is https://bugs.launchpad.net/bugs/1351054
[09:34] <ubot5> Error: ubuntu bug 1351054 not found
[09:34] <jhobbs> mmhmm
[09:44] <wgrant> You can actually wait for more than five minutes before deciding that nobody is responding.
[09:45] <wgrant> Did you try to reassing a private/proprietary bug to Ubuntu?
[09:45] <jhobbs> yes
[09:45] <jhobbs> i was headed there at least, i didn't think i actually hit submit
[09:47] <wgrant> Right, that's not going to go well -- Ubuntu doesn't generally use private bugs except for crash and security reports. It's a community-owned project, so there shouldn't be proprietary information in Ubuntu's bugs.
[09:47] <jhobbs> ok - that makes sense
[09:47] <jhobbs> I suppose it would have been nice to get a warning or error instead of a disappeared bug though
[09:47] <jhobbs> is there a way to get it back?
[09:48] <wgrant> I will recover it soon.
[09:48] <jhobbs> cool
[09:48] <cjwatson> It's unfortunate (as I said in person here) that that kind of reassignment doesn't give you an access grant, the way that making a public bug private does.
=== ndec_ is now known as ndec
[11:34] <dz0ny> hi,anyone around?
[11:35] <dz0ny> this thing called launchpad is broken, beyond
[11:36] <dz0ny> do you guys still develop it or??
[11:36] <cjwatson> It's still actively developed.  I'd suggest being a bit more specific.
[11:38] <dz0ny> then I found a bug. I've used dput to upload package to ppa, however ppa is still empty
[11:39] <cjwatson> Did you get an acknowledgement mail?
[11:40] <dz0ny> no
[11:40] <cjwatson> https://help.launchpad.net/Packaging/UploadErrors#The_upload_appears_to_work_but_I_don.27t_get_any_email_about_it
[11:41] <dz0ny> thx
[11:42] <dz0ny> I didn't import the key...
[11:44] <wgrant> So broken!
[11:46] <davmor2> wgrant: man it must be nice to only have breakages like that right ;)
[11:46] <dpm> wgrant, cjwatson, is there any comment perhaps you guys could add to bug 736005 regarding the hardware upgrades in LP that will potentially mitigate the translation timeouts? Many folks are starting to complain on the translators mailing list
[11:46] <ubot5> bug 736005 in Launchpad itself "POFile:+translate timeouts" [Critical,In progress] https://launchpad.net/bugs/736005
[11:47] <dz0ny> wgrant: well I didn't get the mail
[11:48] <wgrant> dz0ny: We can't tell who to send an email to if we can't work out who uploaded it.
[11:48] <wgrant> dpm: I'm afraid we're still waiting on IS to bring up the database servers. I'll comment in the bug.
[11:49] <dz0ny> wgrant: well .changes file contains mail so ...
[11:49] <wgrant> dz0ny: But anyone could put your address there and cause us to spam you with endless rejection emails.
[11:49] <dz0ny> and if you upload to ppa you also now to which ppa was thing uploaded
[11:49] <cjwatson> dpm: I'll reply.
[11:49] <wgrant> Sure, but it's totally unauthenticated.
[11:49] <cjwatson> Oh, wgrant is doing.
[11:49] <wgrant> I am :)
[11:50] <dz0ny> enforce login for upload?
[11:50] <wgrant> dz0ny: That's not really feasible with FTP, as it's unencrypted.
[11:51] <dz0ny> then enforce sftp :)
[11:52] <dpm> thanks cjwatson, wgrant
[11:59] <dz0ny> bye
[13:31] <jhobbs> wgrant: any idea when you will be able to restore that bug?
[13:40] <wgrant> jhobbs: Done.
[13:48] <jhobbs> wgrant: thanks
[14:20] <shadeslayer_> btw is it possible to get files from this build? https://launchpadlibrarian.net/179759073/buildlog_ubuntu-utopic-powerpc.kimageformats_5.0.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:20] <shadeslayer_> specifically rgb-gimp-2.8.10.psd-expected.data  and rgb-gimp-2.8.10.psd-actual.data
[14:29] <cjwatson> shadeslayer_: It's not possible to recover any files after a build completes.
[14:29] <cjwatson> Successfully or otherwise.
[14:30] <shadeslayer_> cjwatson: what would you recommend? upstream would like to see those files, I reckon I could just cat them
[14:30] <cjwatson> shadeslayer_: IMO packages should generally arrange to cat detailed test suite logs if the test suite fails.
[14:30] <cjwatson> shadeslayer_: dh_auto_test even does that automatically for automake projects nowadays.
[14:30] <cjwatson> So there's certainly precedent.
[14:30] <shadeslayer_> hm
[14:30] <shadeslayer_> needs to be extended to cmake thingumns
[14:31] <cjwatson> Oh, actually, no, that's for config.log on configure failures
[14:31] <cjwatson> Still, same idea
[14:31] <cjwatson> override_dh_auto_test:\n\tdh_auto_test || { cat blah; exit 1; }
[14:31] <cjwatson> or whatever
[14:31] <shadeslayer_> yeah
[14:32] <cjwatson> Or have the upstream cmake code do it.  I think what I'm remembering is that automake itself does it sometimes.
[14:32] <cjwatson> You have to set VERBOSE=1 for that.
[14:32] <shadeslayer_> I don't think cmake knows about any files that a test will write
[14:33] <shadeslayer_> at run time
=== dpm is now known as dpm-afk
=== Ursinha is now known as Ursinha-afk
[18:47] <KNRO> I'm getting Invalid deb-version: {debupstream}+r577.155~ubuntu14.04.1: Invalid version string '{debupstream}+r577.155~ubuntu14.04.1'
[18:47] <KNRO> anyone knows why {debupstream} isn't being evaluated by launchpad thereby resulting in the above error?
=== DarkPlayer_ is now known as DarkPlayer
=== Ursinha-afk is now known as Ursinha
[20:13] <KNRO> _Anyone_ who has daily packages using debupstream that is building OK?
[20:14] <jelmer> KNRO: are you using format version 0.4 ?
[20:15] <KNRO> jemler: I tried 0.3 and 0.4, same result.
[20:16] <KNRO> it's related to this bug: https://bugs.launchpad.net/launchpad-buildd/+bug/1350430
[20:16] <ubot5> Ubuntu bug 1350430 in launchpad-buildd "{debupstream} {debversion} not recognised by format 0.4" [Critical,Fix committed]
[20:17] <KNRO> fix committed, does that mean it's live or not?
[20:23] <tsimpson> live would be fix released
[20:25] <KNRO> is there any workaround now? All my daily packages are failing now
[20:27] <cjwatson> We *think* that {debupstream:packaging} and possibly also {debversion:packaging} will work
[20:27] <cjwatson> We should be able to get that fix rolled out next week though
[20:32] <AShortRedhead> Hi, I am wondering if there is anyone here who can help me with a build problem I have been having
[20:33] <jelmer> KNRO: you need to specify the branch name if the debian/ branch is not in the root branch
[20:33] <jelmer> what cjwatson said :)
[20:34] <AShortRedhead> I currently am doing some trusty builds at https://launchpad.net/~sandyd/+archive/ubuntu/openlitespeed/+packages
[20:34] <AShortRedhead> for some reason, the i386 builds are fine https://launchpadlibrarian.net/181864935/buildlog_ubuntu-trusty-i386.openlitespeed_1.3.3-1ubuntu%2Bsandydnet~trusty_UPLOADING.txt.gz
[20:34] <AShortRedhead> the amd64 builds are failing https://launchpadlibrarian.net/181864921/buildlog_ubuntu-trusty-amd64.openlitespeed_1.3.3-1ubuntu%2Bsandydnet~trusty_FAILEDTOBUILD.txt.gz
[20:34] <KNRO> jelmer: this is what I use now {debversion}+r{revno}.{revno:packaging}, so debversion IS for the root branch, let me try debversion:packaging
[20:34] <wgrant>  /bin/mkdir -p '/usr/modules'
[20:35] <AShortRedhead> for some reason, the amd64 builds are attempting to create files in /usr/modules instead of in
[20:35] <wgrant> AShortRedhead: Your package is trying to write to somewhere that needs root privileges.
[20:35] <AShortRedhead> the correct folder
[20:35] <wgrant> Have you test-built it on amd64 locally?
[20:35] <AShortRedhead> nope
[20:35] <wgrant> You'll see the same problem there, so you can debug it.
[20:35] <AShortRedhead> allright, thanks for the tip!
[20:36] <jelmer> KNRO: in what branch does your packaging live?
[20:38] <KNRO> jemler: you can see the recepie here: https://code.launchpad.net/~mutlaqja/+recipe/libindi-daily
[20:39] <KNRO> bzr: ERROR: Invalid deb-version: {debversion:packaging}+r577.155: Invalid version string '{debversion:packaging}+r577.155'
[20:39] <KNRO> so now {debversion:packaging} is not working as well with 0.4
[20:40] <cjwatson> It's possible it's not fixable until we roll out.  You could run bzr-builder locally and upload the source package directly to the target PPA in the meantime.
[20:42] <AShortRedhead> huh
[20:42] <AShortRedhead> it works locally
[20:42] <wgrant> AShortRedhead: How are you building it?
[20:43] <wgrant> It probably only occurs when building only architecture-specific packages.
[20:43] <wgrant> Build with -B rather than -b
[20:43] <AShortRedhead> wgrant, would it be possible that after using debuild -S for i386, I would have to re-extract before going to amd64?
[20:45] <KNRO> cjwatson: I am using bzr dailydeb command now locally and I'm still getting that error. Should I build the latest bzr and bzr-builder for this to work?
[20:48] <cjwatson> I think so, yes
[20:48] <cjwatson> Not bzr, just bzr-builder
[20:51] <jelmer> KNRO: hmm, I'm not sure if this will work with nest-part
[20:51] <KNRO> jelmer: yeah, I just tried with latest bzr-builder and same error, so I give up
[20:53] <AShortRedhead> hmm
[20:53] <AShortRedhead> still no dice
[20:54] <wgrant> AShortRedhead: You built with -B, not -b, in a clean chroot of the relevant series?
[20:56] <AShortRedhead> nvm I found the issue, missing a slash
[20:56] <AShortRedhead> in the build rules
=== Guest15101 is now known as nesthib