cjwatson | sergio-br2: yes, that's the bug I referred to earlier, still trying to get it sorted out. | 01:57 |
---|---|---|
cjwatson | sergio-br2: fixed now | 04:14 |
sergio-br2 | yay | 04:14 |
sergio-br2 | oh my | 04:17 |
sergio-br2 | it's building | 04:17 |
sergio-br2 | https://code.launchpad.net/~dolphin-emu/+recipe/dolphin-daily-trusty | 04:18 |
sergio-br2 | exciting | 04:18 |
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:37 |
sergio-br2 | eh, I'm not getting the revision number... | 04:46 |
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? | 04:47 |
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:38 |
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:39 |
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:40 |
Peng | "rsa:1024"!? | 06:56 |
wgrant | alkisg: faketime requires /run/shm to be mounted. Why do you need faketime? | 07:09 |
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:10 |
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:11 |
ubot5 | Debian bug 778462 in faketime "faketime: does not work in chroot if /run/shm is not mounted as tmpfs inside the chroot ("sem_open: Function not implemented")" [Minor,Open] | 07:11 |
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:12 |
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:13 |
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:14 |
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:16 |
wgrant | alkisg: Does it make sense to generate the cert as part of the image build at all? | 07:17 |
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 | 07:18 |
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:27 |
cjwatson | voldyman: "Manage webhooks" on the branch or repository index page. | 15:32 |
voldyman | cjwatson: i can't create say a webhook for all merge requests in a project? | 15:33 |
voldyman | i am right now polling that information once per hour | 15:34 |
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:35 |
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:37 |
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:40 |
voldyman | :) filing a bug now. | 15:41 |
voldyman | you guys are awesome | 15:41 |
voldyman | cjwatson: https://bugs.launchpad.net/launchpad/+bug/1538613 | 15:43 |
ubot5 | Launchpad bug 1538613 in Launchpad itself "Allow creating webhooks for project groups" [Undecided,New] | 15:43 |
cjwatson | thanks | 15:49 |
sergio-br2 | hey cjwatson | 15:50 |
sergio-br2 | <sergio-br2> does launchpad just get the tarball from the master branch? | 15:50 |
sergio-br2 | I expected it had .git/ directory in the source, because the dolphin-emu build use some hash from there | 15:51 |
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:54 |
cjwatson | depends what it's trying to do with it | 15:55 |
sergio-br2 | it's not important, it's just some revision numbers | 15:58 |
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 | 15:59 |
cjwatson | That may not be appropriate, I don't know | 16:00 |
=== semiosis_ is now known as semiosis | ||
ubuntiste-msakni | Hey! Anyone around? | 21:23 |
cjwatson | ubuntiste-msakni: What's the problem? (Usually best to just ask straight out.) | 21:23 |
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:25 |
* 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:26 |
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:27 |
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:28 |
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:29 |
cjwatson | it is, yes | 21:30 |
cjwatson | probably needs a manual hack in the wadl-to-html stuff | 21:30 |
cjwatson | bug please | 21:30 |
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:31 |
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:32 |
cjwatson | Since I'm about to go | 21:33 |
cjwatson | And IRC is pretty ephemeral | 21:33 |
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:34 |
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:35 |
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:36 |
dobey | the API is pretty simple to understand | 21:37 |
=== ubuntiste-msakni is now known as elacheche_anis | ||
dobey | as far as APIs go anyway | 21:37 |
cjwatson | There's some Stockholm Syndrome here, I'm sure :) | 21:38 |
dobey | heh | 21:38 |
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:39 |
elacheche_anis | btw | 21:40 |
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:41 |
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:42 |
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:43 |
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:44 |
cjwatson | At some point we should indeed make the docs a bit clearer there though. | 21:45 |
* cjwatson -> evening | 21:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!