| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| alkisg | Hi, I'm trying to import https://anonscm.debian.org/cgit/collab-maint/ltsp.git/ to bzr, https://code.launchpad.net/~alkisg/ltsp/ltsp-debian-packaging-bzr, and I'm getting this error: http://launchpadlibrarian.net/306676857/alkisg-ltsp-ltsp-debian-packaging-bzr.log | 06:53 |
|---|---|---|
| alkisg | bzrlib.errors.CertificateError: Certificate error: hostname 'anonscm.debian.org' doesn't match either of '*.alioth.debian.org', 'alioth.debian.org' | 06:53 |
| alkisg | Can I do something to solve the issue? Or is it a matter of debian web masters using a different certificate/hostname? | 06:54 |
| wgrant | alkisg: It's probably related to SNI and the older version of Python on LP's importds. Are you aware that LP now supports git->git imports? | 06:55 |
| wgrant | You don't need git->bzr any more unless you specifically want bzr. | 06:55 |
| alkisg | wgrant: I tried git->git, but I can't get the recipe right then, I get another issue (let me gather info and report it now...) | 06:56 |
| wgrant | alkisg: bzr-git imports should gain SNI support over the next few weeks as we upgrade the importds from precise to xenial, but using LP's native git mirroring is going to be more supportable than bzr-git in the future. | 07:00 |
| alkisg | wgrant: thank you, I deleted my git->git tests, I'll run some imports again and will report in 20' or so about the recipe failure I get there | 07:00 |
| wgrant | alkisg: Great, let me know if you still have issues. | 07:04 |
| wgrant | Git recipes are pretty good nowadays, and we want to know about any cases where there are regressions vs bzr. | 07:04 |
| alkisg | wgrant: I want to combine the upstream from bzr, lp:ltsp, with the imported git of the debian/ dir, https://code.launchpad.net/~alkisg/ltsp/+git/ltsp-debian-packaging | 07:06 |
| alkisg | wgrant: is it possible to combine bzr and git in the same recipe? | 07:06 |
| wgrant | alkisg: Ah, it's not possible to mix VCSes in a recipe. | 07:06 |
| wgrant | So you still need git->bzr imports, I suppose. | 07:06 |
| alkisg | wgrant: would it make sense to import ltsp/bzr from launchpad, to ltsp/git to launchpad, so that my recipe only has git? | 07:06 |
| wgrant | Ah, if LTSP upstream is git, then yeah, it would make sense to import and use that instead. | 07:07 |
| alkisg | Upstream LTSP is bzr, while the debian maintainer keeps the packaging debian/ dir in git | 07:07 |
| wgrant | Hm, unless there's a git repository of the LTSP codebase, that wont' really work. | 07:08 |
| alkisg | Can i close ltsp upstream which is in lp in bzr format, | 07:08 |
| alkisg | to lp again in git format? | 07:08 |
| alkisg | *clone, import | 07:08 |
| wgrant | LP can't convert other VCSes to git. | 07:08 |
| alkisg | Ah, only to bzr? Ouch | 07:09 |
| wgrant | hm, let me try tweaking some URLs to bypass the SNI issue. | 07:09 |
| === chihchun is now known as chihchun_afk | ||
| * alkisg thinks he used git:// while creating the recipe, and it was modified to https? :-/ | 07:15 | |
| wgrant | alkisg: You created the git->git mirror with git://, but git->bzr with https:// | 07:17 |
| alkisg | Sorry for the PEBKAC error :) Ty for all the help! | 07:17 |
| wgrant | (and a cgit https URL, at that) | 07:17 |
| wgrant | The import has now succeeded, great. | 07:17 |
| wgrant | Let me know if you run into anything else. | 07:17 |
| alkisg | wgrant: would you happen to have an answer for this too? | 07:18 |
| alkisg | (12:21:24 μμ) alkisg: Hi, we have a mailing in launchpad for our epoptes project, https://launchpad.net/~epoptes | 07:18 |
| alkisg | (12:21:24 μμ) alkisg: We've set epoptes@lists.launchpad.net as the debian package maintainer address in https://packages.qa.debian.org/e/epoptes.html | 07:18 |
| alkisg | (12:21:24 μμ) alkisg: Our problem is that the mails sent by bugs.debian.org are discarded, while we want them to appear in the mailing list. We obviously can't register bugs.debian.org as a team member, so what else can we do to accomplish that/ | 07:18 |
| alkisg | (12:34:12 μμ) alkisg: Sample message that we didn't see in the epoptes@lists.launchpad.net mailing list, even though it was sent: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854098;msg=2 | 07:18 |
| alkisg | (12:34:13 μμ) ubot5: Debian bug 854098 in epoptes "Vnc4 is now a transitional package to tigervnc" [Normal,Fixed] | 07:18 |
| ubot5 | Debian bug 854098 in epoptes "Vnc4 is now a transitional package to tigervnc" [Normal,Fixed] | 07:18 |
| wgrant | alkisg: AIUI, Debian Policy requires that maintainer addresses accept email from all addresses. It isn't possible for a Launchpad mailing list to accept email from non-Launchpad members, so by my understanding it is a violation of Policy to specify an LP ML in Maintainer. | 07:20 |
| alkisg | Ah | 07:20 |
| alkisg | Thank you wgrant, then we'll think of some other way to implement that | 07:21 |
| alkisg | Recipe failed to build, https://code.launchpad.net/~alkisg/+recipe/ltsp-trunk+debian-packaging | 07:36 |
| alkisg | bzr: ERROR: bzrlib.errors.BzrCommandError: No control file to take the package name from, and --package not specified. | 07:37 |
| === chihchun_afk is now known as chihchun | ||
| wgrant | alkisg: You want nest-part, not nest, I suspect. | 07:41 |
| alkisg | Ty, testing... | 07:41 |
| wgrant | alkisg: You're currently nesting that entire packaging branch, which contains a debian dir, into the debian dir. | 07:41 |
| alkisg | Ah true, the old dir only had debian/, now he has the whole dir there | 07:41 |
| wgrant | so you end up with debian/debian/control | 07:41 |
| alkisg | The debian maintainer changed the way he does things, he used to only have the debian/ contents in git, now he keeps a clone of the source there too, so nest-part it is :) | 07:42 |
| wgrant | Yep | 07:48 |
| wgrant | Now just boring patch failures! | 07:49 |
| alkisg | Haha, yup, I can manage those; I'll just ping vagrantc to also have a debian/ dir that corresponds to upstream and not debian-testing | 07:52 |
| === JanC is now known as Guest38106 | ||
| === JanC_ is now known as JanC | ||
| === ggherdov`____ is now known as ggherdov` | ||
| === _salem is now known as salem_ | ||
| === chihchun is now known as chihchun_afk | ||
| === grumble is now known as Guest51839 | ||
| === rumble is now known as grumble | ||
| mitchellk_ | Hi folks, getting “W: Failed to fetch http://ppa.launchpad.net/rwky/redis/ubuntu/dists/precise/main/binary-i386/Packages 404 Not Found” on all TravisCI builds for the past hour. Not sure if this is TravisCI issue or Launchpad | 15:20 |
| === mitchellk_ is now known as mitchellk | ||
| dobey | mitchellk: that PPA doesn't exist | 15:57 |
| mitchellk | hmmm, Travis CI builds are calling it? will check with @TravisCiStatus. Nothing changed in my travis build settings, started doing this an hour ago | 15:58 |
| dobey | not sure, but looking on launchpad, i don't see that user owning a ppa with that name | 15:58 |
| mitchellk | fixed with adding “dist: trusty” to travis.yml … been working for 2 weeks without it but must require it now. Thanks for your help. | 16:04 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| alkisg | Is there anything e.g. in the environment that my ./autogen.sh or my debian/control could check, to do a conditional "if building on launchpad" or "if building this launchpad recipe"? | 19:19 |
| dobey | there's no good reason you should need to do that, no | 19:22 |
| shadeslayer | Hi, could someone tell me what kind of arm64 builders Launchpad uses? | 19:23 |
| dobey | shadeslayer: it's armv8. do you mean something else? | 19:24 |
| shadeslayer | dobey: yeah, what SoC :) | 19:24 |
| shadeslayer | curious about what SoC offers good backwards compat with v7 | 19:24 |
| dobey | no idea. it's some arm server box with lots of cores | 19:24 |
| shadeslayer | ^_^ | 19:25 |
| shadeslayer | right :D | 19:25 |
| shadeslayer | I'm currently using the Cavium Thunder X SoC, but that has no compat with b7 | 19:25 |
| shadeslayer | *v7 | 19:25 |
| dobey | shadeslayer: well the bq m10 tablet with ubuntu is running armhf userspace, and it's a mediatek thing | 19:25 |
| dobey | shadeslayer: and the one in the meizu pro 5 is samsung i think | 19:26 |
| shadeslayer | dobey: right, but surely you don't have a tablet doing the builds :P | 19:26 |
| dobey | no, it's some rack hardware i presume | 19:26 |
| shadeslayer | right | 19:26 |
| dobey | i /think/ probably samsung or qualcomm chips | 19:31 |
| === JanC is now known as Guest50386 | ||
| === JanC_ is now known as JanC | ||
| shadeslayer | hehe | 19:32 |
| shadeslayer | I'll be getting my hands on some APM X Gene 2 soon | 19:33 |
| shadeslayer | hopefully they will solve all my armhf and arm64 needs :D | 19:33 |
| dobey | shadeslayer: fwiw, dragon board is an official target for snaps on arm, and i think they deal with armhf just fine | 19:37 |
| shadeslayer | I see | 19:37 |
| dobey | you can already throw ubuntu core on a dragon board and do dev work on it, if that's what you need. | 19:38 |
| dobey | should be totally doable to set up an armhf container/chroot for building for armhf locally | 19:39 |
| dobey | i don't know anything about the x gene thing | 19:39 |
| alkisg | dobey: I'm trying to create a recipe for daily builds, and I have an upstream branch and a debian packaging branch. What I want to do, is to omit some debian/patches that have already been upstreamed.... I'm not sure how to that without conditionals | 19:39 |
| shadeslayer | dobey: roger roger :) | 19:40 |
| dobey | alkisg: fork the packaging branch and remove them from there, and use that for the daily build recipe | 19:41 |
| alkisg | dobey: that's what I wanted to avoid, having to always maintain 2 debian branches, when with conditionals we would be able to maintain one... | 19:42 |
| dobey | alkisg: you want to create a conditional on the wrong thing. the way you avoid that is to get all the patches upstream so you don't have to worry about them not applying. | 19:51 |
| alkisg | dobey: the patches do go upstream, but the debian packaging keeps the old source , at the time of the freeze, and it has the patches in debian/patches | 19:52 |
| alkisg | So e.g. whatever fixes we commit upstream after debian stretch freeze, go to debian/patches instead of src/ | 19:53 |
| alkisg | dobey: do you think I would be able to nest/merge: upstream, then debian/, then a tree with a single empty file, debian/patches/series? | 19:53 |
| alkisg | Would that work in not-applying any patches, or would launchpad complain about "patches cannot be applied" before merging that empty patches/series file? | 19:54 |
| dobey | alkisg: yes, so there is a different debian/ tree for experimental than for stable. you can't avoid that | 19:54 |
| dobey | i don't think you can nest in a directory that exists. and i don't recall what happens if the series file is just empty. you'd have to merge a branch that chagned that, in which case you're maintaining a fork, because you'll have to keep merging up anytime the series file changes in debian | 19:56 |
| cjwatson | shadeslayer: a bunch of HP Proliant m400 cartridges | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!