| xnox | slashd: when uploading d-i please commit to vcs lp:~ubuntu-core-dev/debian-installer/ubuntu and there are branches for stable series too. | 10:30 |
|---|---|---|
| === cpaelzer__ is now known as cpaelzer | ||
| cpaelzer | hi, I'm trying to use a launchpad build recipe but I need to "fuse" d/p/series and various ways I tried failed me so I wanted to ask for best practise | 10:49 |
| cpaelzer | I tried a d/p/ dir with custom patches and a commit that extend d/p/series - but that fails on git auto-merge (even thou it is trivial) | 10:49 |
| cpaelzer | next I provided a d/p/myseries, and in the recipe ran like "run cat d/p/myseries >> d/p/series" | 10:50 |
| cpaelzer | that seemed to work, but after applying all patches the package already brings, the extra patches fail to apply | 10:50 |
| cpaelzer | but not with a actual "failed to patch" | 10:51 |
| cpaelzer | I get gitbuildrecipe.deb_util.NoSuchTag | 10:51 |
| cpaelzer | I also tried to patch things myself with run commands that do like "run patch ..." those worked, but since buildpackage later on cleans and applies things fell apart | 10:52 |
| cpaelzer | hence I'm looking for best practise or examples of lp recipies "fusing" a full debian package (content + debian dir) with another repo that has "more" patches to add on top | 10:52 |
| cpaelzer | any hint welcome | 10:52 |
| cpaelzer | the no such tag is the code path for non-native packages (trying to get a tarball) | 10:54 |
| cpaelzer | from there it falls back to consider building from the local tree, and there quilt bails out (to the NoSuchTag is a red herring) | 10:55 |
| cpaelzer | if only quilt would have any error message, it applies things (withotu error) until it ends and then complains "Command '['quilt', 'push', '-a', '-v']' returned non-zero exit status 1." | 10:56 |
| cjwatson | I think the right answer is a commit that extends debian/patches/series, and so I would suggest trying git-build-recipe locally and seeing if you can work out why git is failing to do the trivial merge | 11:01 |
| cpaelzer | I already try it locally with git-build-recipe | 11:03 |
| cjwatson | And you may find that things work better if you arrange for either pristine-tar to work or for one of the repositories involved to have an upstream/<version> or upstream-<version> tag | 11:03 |
| cpaelzer | it just isn't very verbose to tell me what fails | 11:03 |
| cjwatson | Sure, but I have now told you what I think the right option to pursue is | 11:03 |
| cjwatson | So that may narrow things down | 11:03 |
| cjwatson | The "run" option is useless because LP won't honour that | 11:03 |
| cpaelzer | the patch I'm currently on already extends d/p/series which works, just the quilt push later fails atm | 11:04 |
| cpaelzer | I might adapt the git-build-recipe code to be more verbose at those places, maybe I find what breaks it atm | 11:04 |
| cjwatson | The quilt push bit only happens if you don't have a way for it to get an upstream tarball | 11:04 |
| cjwatson | Fix that and you will avoid that problem | 11:04 |
| cjwatson | i.e. | 11:05 |
| cjwatson | 12:03 <cjwatson> And you may find that things work better if you arrange for either pristine-tar to work or for one of the repositories involved to have an upstream/<version> or upstream-<version> tag | 11:05 |
| cpaelzer | interesting | 11:05 |
| cjwatson | So NoSuchTag is NOT a red herring | 11:05 |
| cpaelzer | the remote I clone from has another branch with pristine-tar content (git-ubuntu) but since there are two such branches I need to make that known | 11:06 |
| cjwatson | I mean maybe git-build-recipe should do better on that path, but you want to avoid being on that path | 11:06 |
| cpaelzer | that might need to fetch ubuntu/pristine-tar and then set it as the local pristine-tar branch | 11:06 |
| cpaelzer | Thanks for the hint cjwatson, I'll try to make it somehow recognize the pristine tar that I have | 11:08 |
| cjwatson | I'm not sure why anyone would expect a branch called ubuntu/pristine-tar to work, given that pristine-tar doesn't consider such a branch name | 11:08 |
| cjwatson | And in any case the upstream tarball is not logically connected to a distribution | 11:09 |
| cjwatson | I would just rename ubuntu/pristine-tar to pristine-tar | 11:09 |
| cpaelzer | well I don't expect it to work until I have created a local branch with the right non prefixed name | 11:09 |
| cjwatson | pristine-tar fetches remote branches | 11:09 |
| cpaelzer | that is the structure of git-ubuntu creating those branch names | 11:10 |
| cpaelzer | which I'm not going to change atm :-) | 11:10 |
| cjwatson | So weird | 11:10 |
| cjwatson | But you could always have the repository that you're layering on top just have a pristine-tar branch | 11:10 |
| cpaelzer | very true, thank you | 11:11 |
| cpaelzer | that might be a way out | 11:11 |
| cjwatson | Or a suitable tag | 11:11 |
| cpaelzer | actually I just got it working to recognize the pristine-tar | 11:11 |
| cpaelzer | that comes from git-ubuntu | 11:11 |
| cpaelzer | no more NoSuchTag | 11:12 |
| cjwatson | (I guess I can see why git-ubuntu does that: the tarballs might disagree and then what would it do? But it's hard to see how that cooperates well with actual pristine-tar) | 11:12 |
| cpaelzer | but still failing to apply quilt push -a | 11:12 |
| cpaelzer | ah no here is my NoSuchTag, ok I'm considering adding it to the repo that I'm layering on top | 11:12 |
| cjwatson | I am absolutely certain that quilt push -a is not called unless you get a NoSuchTag | 11:13 |
| akik | what's ubuntu's policy on using NOPASSWD in sudoers? i'm asking because cloud-init is still doing it for the default user and cloud-init is originally a ubuntu project | 11:13 |
| cjwatson | Ah, now I see https://bugs.debian.org/895377 which I guess is basically for this | 11:14 |
| ubottu | Debian bug 895377 in pristine-tar "/usr/bin/pristine-tar: add support for specifing branch name to pristine-tar cli" [Normal,Open] | 11:14 |
| cpaelzer | cjwatson: agreed as i said "... here is my NoSuchTag" - it was just hidden in all the output | 11:14 |
| cjwatson | Sorry, you were writing so many lines on IRC so quickly that I was having some difficulty keeping up :) | 11:15 |
| === ricab is now known as ricab|lunch | ||
| ddstreet | tdaitx i notice the openjdk-8 (and other versions) autopkgtests have been failing for, well, ever...have you looked at the failure logs and/or are you working on fixing the tests? | 12:42 |
| === ricab|lunch is now known as ricab | ||
| tdaitx | ddstreet: yeah, it is a known issue, the testsuite has thousands of tests, some of those are unstable tests, anyhow any of them need to be either ignored (by adding them to a blacklist in the testsuite itself) or fixed, there's a long term plan to get all of them fixed | 13:06 |
| ddstreet | tdaitx ok cool - since they aren't useful now (I assume?) could you maybe disable them? I would suggest hinting britney to ignore them, but it seems like you update them often enough that just hinting the latest version would still result in some annoying failures after each update... | 13:22 |
| ddstreet | plus that will save time and energy re-running them when we know they aren't going to pass :) | 13:23 |
| === cpaelzer__ is now known as cpaelzer | ||
| cpaelzer | cjwatson: I got a pristine-tar set up and have it working through the git-build-recipe steps | 14:35 |
| cpaelzer | thanks for the hint | 14:35 |
| cpaelzer | yet now I wonder about launchpad permission management. I'd expect that I can select owner/target-ppa for a group that I'm admin in | 14:35 |
| cpaelzer | the group is private, maybe that makes it not present it to me on the UI of "new-recipe" | 14:36 |
| cjwatson | cpaelzer: Recipes cannot use private components; the builder doesn't have permissions to fetch them | 14:36 |
| cpaelzer | ok, good to know | 14:37 |
| cjwatson | cpaelzer: (this is in theory fixable but would be a fair chunk of work) | 14:37 |
| xnox | smoser: commented on the list-boots bug. it's funny! | 14:44 |
| smoser | wow. yeah. | 14:46 |
| smoser | it really sucks though for using the journal | 14:46 |
| xnox | smoser: What can I say, your welcome! =) | 14:46 |
| xnox | smoser: i wonder, if journal should be assking for app specific bootid, under containers. | 14:47 |
| smoser | i'll just reboot my host every time | 14:47 |
| xnox | but then one would get a new bootid on every journald restart | 14:47 |
| xnox | i guess we could stash it into /run/systemd/journal or something | 14:48 |
| xnox | i would prefer lxd to fake boot_id though | 14:48 |
| xnox | as it should be managing the container lifecycle | 14:48 |
| smoser | yeah. it does do that with uptime | 14:49 |
| xnox | smoser: please open a bug at https://github.com/lxc/lxd/issues ? | 14:50 |
| smoser | i think it'd be https://github.com/lxc/lxcfs | 14:52 |
| smoser | and looks like it'd be pretty straight forward to put a random number | 14:52 |
| * smoser learns something today | 14:53 | |
| xnox | smoser: i'm not sure if there is any other way. cause at the moment containers know if the host has been rebooted or not. | 14:54 |
| xnox | smoser: and i'm not sure if journald has logs from containers... for a particular host... queried from the host. | 14:54 |
| xnox | smoser: maybe check if any other container solutions handle this at all or not | 14:54 |
| smoser | here i'd been using the 'uuidd' service to get myself uuids. but i could have just read from /proc/sys/kernel/random/uuid all along. | 14:55 |
| smoser | but that would not have been as cool as using a dbus service. | 14:56 |
| smoser | :) | 14:56 |
| xnox | smoser: https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn.c#L1841 | 14:56 |
| xnox | smoser: so at least nspawn does things | 14:56 |
| xnox | you can read /proc/sys/kernel/random/boot_id ;-) | 14:56 |
| xnox | ah, wait that's the static one | 14:56 |
| xnox | smoser: please open a bug against lxcfs if that's where the code is, and do use the pointer to the nspawn's setup_boot_id code | 14:58 |
| smoser | https://github.com/lxc/lxcfs/issues/285 | 15:01 |
| smoser | thank you xnox. i'll watch for your lxcfs pull request later today. | 15:02 |
| xnox | hahahaha | 15:43 |
| xnox | smoser: you were already told now =) | 15:43 |
| xnox | smoser: and meh, i don't code in github.com/lxc* =) | 15:43 |
| * xnox diehard C coder only | 15:43 | |
| smoser | xnox: that is C | 15:55 |
| smoser | excuses-- | 15:55 |
| TJ- | is there some voodoo to understanding where to find the actual, meaningful, git commit logs for package git repos? All I see to find is "Import patches-unapplied ..." | 16:35 |
| Odd_Bloke | TJ-: For the git-ubuntu repos, you mean? AIUI, the uploader has to go through a specific process for their git history (if there is any!) to be included in those imports. | 16:38 |
| Odd_Bloke | But rbasak could probably tell you more. | 16:39 |
| TJ- | Odd_Bloke: specifically I'm looking at the grub2 git repo, but I've hit this several times with other packages and given up! | 16:39 |
| ahasenack | TJ-: the import commits will really just record the change as a big chunk, like a debdiff. To preserve git history, an upload tag must be pushed to the repo together with the dput upload. Then, when the importer sees the new package to import, if its contents match the tree associated with that upload tag, the git rich history will be preserved | 16:55 |
| ahasenack | so far only the server-owned packages have been following that, and when a member of the server team does the upload (because he can push said tag) | 16:56 |
| TJ- | ahasenack: hmmm, so there's no way to easily see the real project history unless the developer takes care of it? | 17:02 |
| ahasenack | it really depends what tooling the developer used, we need to remain compatible with people who prefer debdiffs and plain dputs | 17:03 |
| TJ- | right. hmmmph! makes it really challenging to discover where a regression lives | 17:04 |
| TJ- | right now seems like 19.04 grub2 has regressed and broken GRUB_ENABLE_CRYPTODISK so was hoping to quickly parse the recent commits in search of candidates | 17:05 |
| TJ- | cyphermox: maybe you could cast your eye over Bug #1813126 | 17:06 |
| ubottu | bug 1813126 in grub2 (Ubuntu) "[19.04] GRUB_ENABLE_CRYPTODISK=y ignored" [Undecided,Confirmed] https://launchpad.net/bugs/1813126 | 17:06 |
| cyphermox | TJ-: right now I don't have time to look at that; but I suspect it will have something to do with the change in LUKS format | 17:21 |
| cyphermox | you might want to have a look at what 'sudo grub-probe --device /dev/mapper/<your crypto device> --target=abstraction' reports, but I think it won't be a regression so much as something that has never been supported yet | 17:22 |
| cyphermox | (though I am, admittedly, just guessing) | 17:22 |
| cyphermox | TJ-: if you want to have a look on your own before I can get to this though; you'll want to look at https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/log/?h=ubuntu | 17:22 |
| cyphermox | it's a git-dpm tree, that means it's a fairly straightforward tree where one can relatively easily do bisection against the package or against the patched (or unpatched) tree ('git-dpm checkout-patched' will get you a patched tree, and if you rebase you can get to just before any patches are applied) | 17:25 |
| TJ- | cyphermox: thanks, that's perfect | 17:35 |
| TJ- | cyphermox: you nailed it; LUKS2 in my test case, despite I used "cryptsetup luksFormat --type luks ..." hmmph | 17:37 |
| TJ- | cyphermox: aha, cryptsetup semantics have changed since 18.04, 19.04 --type=luks == luks2, need to use --type=luks1 | 17:42 |
| === gusnan_ is now known as gusnan | ||
| vorlon | infinity, stgraber, kees, mdeslaur: TB in 7? | 18:53 |
| mdeslaur | ack | 18:54 |
| xnox | vorlon: kenvandine: rcj: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1831675 | 23:34 |
| ubottu | Launchpad bug 1831675 in livecd-rootfs (Ubuntu Bionic) "core18 snap missing from bionic desktop, snaps fail to seed offline" [Undecided,New] | 23:34 |
| vorlon | xnox: is this a daily desktop image you're talking about? | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!