[00:18] <wgrant> lfaraone: You probably want to flip the policies on https://launchpad.net/zulip/+sharing to public and then make that import public.
[00:18] <wgrant> The project as a whole is public now, but bugs/branches/blueprints are all still private.
[06:45] <lool> wgrant: ack; thanks; cjwatson helped me with this yesterday
[11:14] <Odd_Bloke> cjwatson: So a "partition" of 1000M from /dev/urandom causes the hang, but 500M doesn't.  So we're almost certainly hitting some sort of resource problem.
[11:17] <Odd_Bloke> I could try creating the partition and copying the chroot in myself, rather than trying to dd the full partition in.
[11:17] <Odd_Bloke> We do grub stuff after the dd anyway, so I don't think that would produce something too different...
[11:19] <cjwatson> Odd_Bloke: I was going to suggest setting dd bs= to something more reasonable, but the default of 512 bytes might be slow but shouldn't hang
[11:20] <cjwatson> None of this is in tmpfs or anything, is it?
[11:21] <cjwatson> And it's doing the dd in 26 seconds in the latest build, so not even that slow
[11:22] <cjwatson> Odd_Bloke: I have no ideas as to what resource problem could be being triggered, unless we're actually running out of disk (which seems unlikely); your thought seems as good as any.
[11:22] <Odd_Bloke> I was thinking it might be OOM in the mapping code, but that's a total stab in the dark.
[11:23] <Odd_Bloke> I don't _think_ we're running out of disk, because I was able to create two 3GB (when I was seeing if the disk image was too small).
[11:24] <Odd_Bloke> And when I failed at maths and made it 1.05 GB (>.<), the dd explicitly complained about the disk image being too small.
[11:25] <cjwatson> Which mapping code?
[11:27] <Odd_Bloke> As in, whatever is taking writes to /dev/mapper/... and making them end up in a file.
[11:28] <Odd_Bloke> But, actually, that thought was triggered when I was using qemu-nbd for the QCOW2 file, so I'm not sure I'm even holding a weapon for the stab in the dark. :p
[11:44] <cjwatson> Odd_Bloke: That's just device-mapper, it's straight through the kernel
[11:45] <cjwatson> Well, and a loop mount.  But even so, not much to allocate memory there.
[15:28] <dsmythies> I got an odd e-mail about licensing, with only a bounce type return address. It is signed "The Launchpad Team". I have been searching and searching and have not found how to contact "The Launchpad Team". I would like to reply to the e-mail, but do not know how to address it. Does anybody here have a suggestion?
[15:32] <dobey> for what project?
[15:33] <dsmythies> help.ubuntu.com (  https://launchpad.net/help.ubuntu.com  )
[15:34] <dobey> looks like someone selected "I don't know yet" for the license
[15:34] <dobey> which would have resulted in the mail
[15:35] <dsmythies> Sigh, I'll contact gunnar. Are you saying the e-mail was automatic?
[15:36] <dobey> i think so. i'm not 100% certain though, but if it had a noreply address for the reply, then i'd suspect it was automatic, yes
[15:38] <dobey> and as a result of the "i don't know yet" selection
[15:40] <dsmythies> yes, I see now. I'll report back later. Thanks.
[16:30] <dsmythies> Follow up: Yes, the e-mail was automatic and due to gunnar's temporary licencse entry. Now fixed. Thanks again.
[16:58] <teward> any LP admins on?
[16:58] <teward> or people who can influentially say "No, group abc won't ever get the permissions to mess with other projects' settings"
[16:58] <teward> s/influentially/supremely/
[17:04] <dobey> it's up to the project owner/maintainer as to whom gets permissions to mess with that projects settings
[17:05] <teward> dobey: this is a more global concern
[17:05] <teward> and it's on the bugcontrol list
[17:05] <dobey> so only if a project owner/maintainer gives a group permissions to do something with a project, will that group have permissions for that project
[17:06] <teward> dobey: mind reading through https://lists.launchpad.net/ubuntu-bugcontrol/msg04363.html and voicing opinions, perhaps?
[17:06] <teward> hate to involve LP Admins in general but... :/
[17:06] <teward> the problem being the proposal from someone else on bugcontrol would make a cross-project 'global' permissions impact
[17:06] <dobey> no, that request just doesn't make sense
[17:06] <teward> my opinion is -1 for the same reason you said
[17:06] <dobey> ubuntu-bugcontrol is about bugs in ubuntu, not projects
[17:06] <teward> dobey: indeed.
[17:07] <teward> dobey: as i said in https://lists.launchpad.net/ubuntu-bugcontrol/msg04366.html
[17:07] <teward> dobey: i think it needs highest-level smackdown sstatements whether from tech teams or LP administration or otherwise
[17:10] <teward> (or whomever is bug god in charge of bugcontrol)
[17:10] <dobey> eh, i'm not subscribed to the list, and i don't think it's that important. ignoring it will just result in it going away :)
[17:10]  * teward shrugs
[17:11] <dobey> it doesn't matter, because bugcontrol team doesn't have permissions to grant itself more permissions
[17:11] <teward> mhm
[17:11] <teward> in any case, it should be squished, IMO
[17:19] <dobey> well if you want a definitive answer quote, then it's "ubuntu-bugcontrol is for managing bugs in ubuntu, not in upstream projects"
[17:20] <dobey> ie, "no, this request makes no sense"
[17:33] <teward> urgh i hate my internet
[17:33] <teward> dobey: that's what my take had been, thanks.
[17:41] <sergio-br22> hi
[17:43] <dobey> hi
[17:47] <sergio-br22> I need to re-build some packages to willy
[17:47] <sergio-br22> (ppa)
[17:48] <sergio-br22> so I tried to copy vivid packages to willy, rebuilding them
[17:48] <sergio-br22> but it did not work...
[17:48] <sergio-br22> are there any other way?
[17:48] <dobey> it depends on what failed
[17:50] <sergio-br22> https://code.launchpad.net/~random-stuff/+archive/ubuntu/stable/+packages?field.name_filter=&field.status_filter=published&field.series_filter=wily
[17:50] <sergio-br22> it seems launchpad does not change the "~ubuntu15.04.1" to "15.10.1"
[17:51] <teward> sergio-br22: that's a manual step that you have to do yourself - LP doesn't change version strings when yuo copy to another release
[17:51] <teward> (i think)
[17:51] <sergio-br22> if it does not do that, it does not make sense to have an option to copy to another version...
[18:04] <dobey> indeed
[18:05] <dobey> you already had published binaries in the destination archive
[18:06] <sergio-br22> yup, I thought it'll substitute the 15.04.1 to 15.10.1 automatically
[18:06] <sergio-br22> because launchpad put that automatically in the recipes
[18:07] <dobey> if you are using a recipe then yes, the recipe will add it automatically
[18:08] <dobey> that is on the recipe side, not the ppa side
[18:08] <dobey> and if you're using recipes, the right way to add a new series, is to update the recipe to build for the new series
[18:11] <sergio-br22> humm
[18:11] <sergio-br22> my problem is not the recipes exactly
[18:11] <dobey> recipes can build for multiple series
[18:11] <sergio-br22> I know that
[18:11] <sergio-br22> problem is, I want to build with "old" sources
[18:12] <sergio-br22> https://code.launchpad.net/~random-stuff/+recipe/mupen64plus-core
[18:12] <sergio-br22> take a look
[18:12] <sergio-br22> it's already building for willy, but it's for the nightly/testing ppa
[18:13] <sergio-br22> it uses the source from the github import
[18:13] <sergio-br22> but I want to use the source from May
[18:14] <sergio-br22> to publish in the stable ppa
[18:27] <dobey> then you need a different recipe building from a different branch
[18:28] <dobey> or you need to do manual uploads
[18:29] <sergio-br22> too much effort ...
[18:30] <dobey> well, if you want to build different source, then you need to build from a different source. if you don't like the effort, don't do it :)
[18:30] <sergio-br22> :/
[18:52] <sergio-br22> Error parsing time at /usr/lib/x86_64-linux-gnu/perl/5.20/Time/Piece.pm line 469, <$filehandle> line 11.
[18:52] <sergio-br22> what's this
[18:53] <sergio-br22> can't build a package for 15.10, I'm not sure what's happening
[18:53] <sergio-br22> https://launchpadlibrarian.net/219329429/buildlog.txt.gz
[19:03] <dobey> looks like maybe an issue with the builder that got picked, not having the locale set properly
[19:03] <sergio-br22> wrong week day on the changelog, i guess
[19:04] <dobey> unless you have an invalid time in the changelog, i guess that wouldn't be the issue, since the recipe builder generates a changelog entry
[19:05] <dobey> well, maybe having the locale unset caused it to generate an invalid changelog entry wheich dpkg then couldn't parse
[19:06] <sergio-br22> ergghhh
[19:06] <sergio-br22> it was not that...
[19:07] <sergio-br22> https://code.launchpad.net/~dolphin-emu/+recipe/dolphin-emu-stable-5.0
[19:07] <sergio-br22> same issue again
[19:08] <sergio-br22> about the locale unset, it was not an issue on vivid
[19:11] <sergio-br22> have no idea how to fix it
[19:12] <sergio-br22> https://bugs.launchpad.net/ubuntu/+source/dvbcut/+bug/1490332
[19:12] <ubot5`> Ubuntu bug 1490332 in dvbcut (Ubuntu) "Error parsing time at /usr/lib/x86_64-linux-gnu/perl/5.20/Time/Piece.pm line 469, <$filehandle> line 6." [Undecided,New]
[19:13] <sergio-br22> launchpad issue?
[19:16] <sergio-br22> i think i found the issue
[19:16] <sergio-br22> it's Oct instead Out, derp
[19:27] <sergio-br22> ok, it building now
[19:27] <sergio-br22> what a silly bug
[22:16] <DragonPunch> hello :0
[22:27] <dobey> hi
[23:09] <DragonPunch> is this pace for startups
[23:09] <DragonPunch> place
[23:38] <blr> DragonPunch: no launchpad provides code hosting, project management tools, PPAs and build infrastructure for ubuntu.
[23:38] <blr> https://launchpad.net/