[01:57] <cjwatson> sergio-br2: yes, that's the bug I referred to earlier, still trying to get it sorted out.
[04:14] <cjwatson> sergio-br2: fixed now
[04:14] <sergio-br2> yay
[04:17] <sergio-br2> oh my
[04:17] <sergio-br2> it's building
[04:18] <sergio-br2> https://code.launchpad.net/~dolphin-emu/+recipe/dolphin-daily-trusty
[04:18] <sergio-br2> exciting
[04:37] <sergio-br2> nice, it build
[04:37] <sergio-br2> I should move to git then
[04:37] <sergio-br2> because dolphin users often asks about the fancy git hash and the revision
[04:46] <sergio-br2> eh, I'm not getting the revision number...
[04:47] <sergio-br2> cjwatson, there's no .git/ at the source? Even using git repo?
[04:47] <sergio-br2> does launchpad just get the tarball from the master branch?
[06:38] <alkisg> Hi, the edubuntu live CD currently fails to build because it has a program of mine called epoptes preinstalled, and epoptes.postinst runs this commands, which fails on the live cd build environment:
[06:38] <alkisg> faketime '1970-01-01 00:00:00 UTC' openssl req -batch -x509 -nodes -newkey rsa:1024 -days $(($(date --utc +%s) / 86400 + 3652)) -keyout /tmp/epoptes.key -out /tmp/epoptes.crt
[06:38] <alkisg> The error is: "sem_open: Function not implemented"
[06:39] <alkisg> My problem is that I can't reproduce the error anywhere, in chroots, with or without /dev bind-mounted etc
[06:39] <alkisg> So I was thinking to ask, if someone here can tell me how is /dev mounted in the live cd build environment, so that I could reproduce the problem locally,
[06:40] <alkisg> or, if someone has ssh access to such an environment, to run that ^ command above and tell me that this is indeed the part that fails...
[06:56] <Peng> "rsa:1024"!?
[07:09] <wgrant> alkisg: faketime requires /run/shm to be mounted. Why do you need faketime?
[07:10] <Peng> "rsa:1024"?!
[07:10] <alkisg> Hi wgrant, first, I can't make faketime fail in a chroot, with or without mounting /dev etc. Could you give me a way to reproduce the issue?
[07:10] <wgrant> alkisg: Is it a chroot of the right Ubuntu series?
[07:11] <alkisg> highvoltage, the edubuntu maintainer, told me that it's happenning now on 16.04 edubuntu builds
[07:11] <wgrant> That would make sense.
[07:11] <wgrant> Are you testing in a 16.04 chroot?
[07:11] <alkisg> I don't have access to the logs, but he mailed me a big log (1 mb or so), I could put it somewhere if needed
[07:11] <alkisg> Yes
[07:11] <alkisg> And I can't make it fail no matter what I try
[07:11] <wgrant> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778462 is probably relevant
[07:12] <alkisg> About why I need it. epoptes.postinst creates a certificate. This by default is valid from today to +10 years. But some clients have failed CMOS batteries, and dates of e.g. 01-01-2000, and the certificate is invalid then. So I need faketime to force openssl to create a certificate valid since the Epoch.
[07:12] <alkisg> I've seen that bug report, but I can't reproduce it on 16.04
[07:12] <alkisg> Meh
[07:12] <wgrant> (in addition to Peng's point, is it save to have a certificate shared by all installations from that image...?)
[07:13] <alkisg> Sorry, no, I'm not trying on a 16.04 chroot. I was trying from 16.04 server to a wheezy chroot that I had handy. Trying on 16.04 chroot now...
[07:13] <wgrant> That's hopefully it.
[07:13]  * alkisg didn't realize Peng's point, sorry...
[07:13] <wgrant> 1024-bit RSA is pretty much obsolete at this point.
[07:14] <wgrant> It's within the realm of easy crackability.
[07:14] <Mikaela> the minimum considered as secure is currently 2048, and I think 4096 is recommended
[07:14] <wgrant> alkisg: So we should probably tell launchpad-buildd to mount /run/shm in the chroot if it exists, but this also raises the other crypto issues with the image build process.
[07:14] <wgrant> 4096 should be used for long-term keys, indeed.
[07:16] <alkisg> Thank you guys, I was able to reproduce it on a 16.04 chroot, and I'll increase 1024 to 4096.
[07:16] <alkisg> I'll work around it in epoptes.postinst, falling back to not using faketime there, it's up to you to do whatever's needed for /run/shm, epoptes.postinst won't fail though if it's not there
[07:17] <wgrant> alkisg: Does it make sense to generate the cert as part of the image build at all?
[07:18] <alkisg> Even if the certificate is public knowledge (it being on a live cd), I think it still offers encryption when there's no man in the middle
[07:18] <alkisg> It would be nice if edubuntu regenerated it dynamically, but it doesn't hurt to already have it there in the live cd
[15:27] <voldyman> how can i add a webhook from the web UI? it is mentioned in the webhook docs but can't find the link anywhere
[15:32] <cjwatson> voldyman: "Manage webhooks" on the branch or repository index page.
[15:33] <voldyman> cjwatson: i can't create say a webhook for all merge requests in a project?
[15:34] <voldyman> i am right now polling that information once per hour
[15:35] <cjwatson> voldyman: Only per target branch (Bazaar) or repository (Git) at the moment.  But even for a whole project, I would expect most of the merge requests to be targeted at the development focus.
[15:37] <voldyman> cjwatson: hmm, my use cases is that all the merge requests that are created in the projects under http://launchpad.net/elementary are posted in our slack. creating webhooks for each repo would be too much also i'll have to manually go and create the webhook for any new project
[15:40] <cjwatson> voldyman: Ah, you mean a project group then
[15:40] <voldyman> yup
[15:40] <cjwatson> voldyman: Do file a bug, it's probably not ridiculously hard to do
[15:40] <cjwatson> To some extent we've been waiting for real use cases before filling things out
[15:41] <voldyman> :) filing a bug now.
[15:41] <voldyman> you guys are awesome
[15:43] <voldyman> cjwatson: https://bugs.launchpad.net/launchpad/+bug/1538613
[15:49] <cjwatson> thanks
[15:50] <sergio-br2> hey cjwatson
 does launchpad just get the tarball from the master branch?
[15:51] <sergio-br2> I expected it had .git/ directory in the source, because the dolphin-emu build use some hash from there
[15:54] <cjwatson> no, it doesn't just get the tarball.  the problem you're hitting is that launchpad-buildd calls dpkg-buildpackage with -i -I, thereby stripping .git etc. (as is usual for source packages, they aren't normally expected to contain .git)
[15:54] <cjwatson> it's usually a mistake for a package's build process to rely on having the git tree there; if I were you I would find some way to patch around that
[15:55] <cjwatson> depends what it's trying to do with it
[15:58] <sergio-br2> it's not important, it's just some revision numbers
[15:59] <sergio-br2> there's no way to workaround the dpkg-buildpackage setting right?
[15:59] <cjwatson> No
[15:59] <cjwatson> If you write the recipe such that the relevant information is in the version number (if that's sensible), then you can use dpkg-parsechangelog in debian/rules to parse it out
[16:00] <cjwatson> That may not be appropriate, I don't know
[21:23] <ubuntiste-msakni> Hey! Anyone around?
[21:23] <cjwatson> ubuntiste-msakni: What's the problem?  (Usually best to just ask straight out.)
[21:25] <ubuntiste-msakni> cjwatson: I'm trying to use API to get all the informations in here https://launchpad.net/ubuntu/+mirror/ubuntu.mirror.tn-archive2 using https://api.launchpad.net/devel.html#distribution_mirror
[21:25] <ubuntiste-msakni> But I'm not able to do that.. :/ :(
[21:26]  * ubuntiste-msakni is a n00b who couldn't understand the API documentation :(
[21:26] <cjwatson> ubuntiste-msakni: It might not all be exported.  What in particular can't you get?
[21:26] <dobey> it doesn't seem to be all exported. sync status for series/arch doesn't seem to be in the api
[21:27] <dobey> (same question was asked the other day, and i poked at the docs a bit to see what was missing)
[21:27] <ubuntiste-msakni> First of all I couldn't find the way to get any information from that exact mirror.. It always return info about distros  like ubuntu, centos, kiwilinux, etc :/
[21:28] <ubuntiste-msakni> dobey: That was me who asked it..
[21:28] <cjwatson> the archive_mirrors attribute of a distribution has a collection of its mirrors
[21:28] <cjwatson> (or cdimage_mirrors, depending which you want)
[21:29] <cjwatson> and you can use distribution.getMirrorByName(name="whatever") to get a specific one
[21:29] <dobey> the URL for the distribution_mirror docs seems wrong too
[21:29] <cjwatson> http://paste.ubuntu.com/14682682/
[21:30] <cjwatson> it is, yes
[21:30] <cjwatson> probably needs a manual hack in the wadl-to-html stuff
[21:30] <cjwatson> bug please
[21:31] <cjwatson> and and if you need series/arch freshness status, I agree that isn't currently exported; file a bug with rationale for why you need it (we do need a reason to export things, because it can affect performance - would have to look at how expensive this in particular is to return)
[21:31] <ubuntiste-msakni> I'm not used to work with LP API, but don't you find that help.launchpad.net  need more detailled doc? :(
[21:32] <ubuntiste-msakni> cjwatson: Actually I was looking for those exact information :D
[21:32] <ubuntiste-msakni> cjwatson: dobey what I want to do is to get those informations and export them as graphs to monitor the status of that mirror..
[21:32] <cjwatson> I don't personally find that it needs more detailed documentation, but then that's because I already know the API well!  If *you're* confused by something in particular, then you'd need to explain it
[21:32] <cjwatson> Don't tell me here, write it in a bug report
[21:33] <cjwatson> Since I'm about to go
[21:33] <cjwatson> And IRC is pretty ephemeral
[21:34] <ubuntiste-msakni> cjwatson: I'm just having a chat :D :p I'll report a bug when I can really understand what's in the API and what's not, and can understand how to consume every thing already there.. For now I'm tottaly lost
[21:34] <cjwatson> Graphing is a decent rationale, just want to avoid ending up with that object timing out on the API because it's trying to export too much
[21:34] <cjwatson> ubuntiste-msakni: I definitely recommend playing about with lp-shell in the lptools package, especially if you also install ipython.
[21:35] <cjwatson> In combination with the overview docs on https://help.launchpad.net/API/launchpadlib you can do quite a bit of interactive exploration that way, which helps.
[21:35] <ubuntiste-msakni> I never heard of lp-shell.. I use that py lib, I'm installing lp-shell right now to play with it
[21:35] <cjwatson> lp-shell is a simple wrapper around launchpadlib, designed for interactive use
[21:35] <ubuntiste-msakni> Great :)
[21:35] <ubuntiste-msakni> I'm starting from there :)
[21:36] <cjwatson> And you want ipython for that since the standard Python REPL lacks completion and such
[21:36] <ubuntiste-msakni> thx cjwatson dobey.. Even if I can't find what I need, I should understand that API :/
[21:37] <dobey> the API is pretty simple to understand
[21:37] <dobey> as far as APIs go anyway
[21:38] <cjwatson> There's some Stockholm Syndrome here, I'm sure :)
[21:38] <dobey> heh
[21:39] <elacheche_anis> cjwatson: dobey I'm not a dev.. I'm not used to work with apis :) I'm a n00b x(
[21:39] <dobey> well, i'm sure if we developed it anew today, it'd probably be better, but i've certainly dealt with far worse things :)
[21:40] <elacheche_anis> btw
[21:41] <elacheche_anis> are you aware that the text in here → https://api.launchpad.net/ tell the users that there is a stable version fo the API ?
[21:41] <cjwatson> The actual layout is mostly not too bad.  The main problems with it are things like terrible batch behaviour and other such efficiency problems, and a few too many implementation details being brought to the surface (e.g. in collections).
[21:41] <elacheche_anis> As the v1.0 is (based on that link) not supported anymore x)
[21:41] <cjwatson> Yes, we know about the API versioning stuff.  It needs to be revisited, as the original scheme never worked out to be sensible.
[21:42] <elacheche_anis> :)
[21:42] <cjwatson> Most simple clients can just use devel unless you have some reason to ship them in a way that's hard to update (e.g. code that actually ships with Ubuntu).
[21:43] <cjwatson> If we were doing that again we'd probably version different bits of the API separately or something, but it's not clear that it's worth the effort for major rearrangements.
[21:44] <elacheche_anis> I see :)
[21:44] <elacheche_anis> I'm just trying to use the info in LP on my LoCo website :) So our contributors will use LP, right now they all ignore it
[21:45] <cjwatson> At some point we should indeed make the docs a bit clearer there though.
[21:45]  * cjwatson -> evening