| LeePen | gnu_srs: There is already a RFP: #765971! | 11:14 |
|---|---|---|
| gnu_srs1 | LeePen: No need for an upgrade of eudev for beowulf? Regarding Debian we can make a +debian version and take over #765971 making it an ITP again! | 12:18 |
| LeePen | That is good about eudev in beowulf. Sounds a good plan for #765971. I think I have my hands full with elogind in debian ;) | 12:20 |
| fsmithred | I just tried to build desktop-base and I'm getting the following error: | 13:52 |
| fsmithred | dh_systemd_enable: dh_systemd_enable is no longer used in compat >= 11, please use dh_installsystemd instead | 13:53 |
| fsmithred | I'm not aware that I'm using dh_systemd_enable | 13:54 |
| fsmithred | this did not happen with test builds a few months ago | 13:57 |
| fsmithred | If I drop compat to 10, it builds. | 13:57 |
| LeePen | Is this for unstable? | 13:58 |
| fsmithred | building locally now. Will build for unstable next, then beowulf. | 13:58 |
| fsmithred | any idea where dh_systemd_enable is coming from? | 13:59 |
| LeePen | Because debian/unstable is unfrozen, lots of new versions of packages are now in. I think the default debhelper compat has increased to 12. | 14:00 |
| fsmithred | oh, I've been using 11 for everything | 14:00 |
| fsmithred | "everything" is ultimately for beowulf | 14:00 |
| amesser | yay, my Synology DS213j now runs beowulf ;-) | 14:23 |
| fsmithred | cool | 14:30 |
| LeePen | I am just about to try a build of policykit for beowulf using the ~beowulf1 naming scheme. | 14:34 |
| LeePen | Let's see what happens… | 14:35 |
| LeePen | rrq: I don't seem to have perms to do a new build for beowulf. I have reopened yours to trigger it. I hope that is OK? | 14:42 |
| Evilham | doubt that works | 14:43 |
| fsmithred | Please fill me in on this naming scheme. | 14:47 |
| amesser | Did you notice, that /sbin/lvm in buster/beowulf depends on libsystemd while in ascii/jessie not? If one is using root on lvm devices, the system boot now depends on having a libsystemd. This generates a possibly bad sideeffect: Assuming something goes wrong with libelogin update or install -> system wont boot anymore ;-) | 14:49 |
| LeePen | amesser: you are right, the increasing dependence of basic utilities on libsystemd is madness. | 14:53 |
| LeePen | Well, the policykit build seems to have worked, apart from arm which ran out of memory when compressing. | 14:57 |
| LeePen | Evilham: Are you able to restart the arm64 build? | 14:58 |
| LeePen | And no complaints about the naming scheme! | 14:58 |
| LeePen | fsmithred: it is the one I suggested a few weeks ago to avoid getting higher versions in beowulf than ceres when we have to rebuild. | 14:59 |
| fsmithred | maybe I missed that meeding | 14:59 |
| fsmithred | I made a different suggestion for the same problem | 14:59 |
| LeePen | I only suggested it here, IIRC | 14:59 |
| fsmithred | oh | 15:00 |
| LeePen | Rather than bumping the packaging number, you append ~beowulf1 to it. | 15:00 |
| fsmithred | my suggestion was to build for unstable with version number X | 15:00 |
| LeePen | That way we always have ceres > beowulf. | 15:00 |
| fsmithred | then build Xb for beowulf | 15:00 |
| fsmithred | then build Xu for unstable | 15:01 |
| fsmithred | I think yours is better if it really works | 15:01 |
| fsmithred | oh, how do you arrange your changelog? | 15:02 |
| fsmithred | wpm | 15:02 |
| fsmithred | oops | 15:02 |
| fsmithred | won't it complain if the last entry isn't the highest version? | 15:02 |
| LeePen | It hasn't | 15:02 |
| fsmithred | I'll try it | 15:03 |
| fsmithred | (assuming I can build a package) | 15:03 |
| fsmithred | anyone have an idea of what I should do with my dh_systemd_enable error? | 15:03 |
| LeePen | This is what I just did for policykit: https://git.devuan.org/devuan-packages/policykit-1/blob/suites/beowulf/debian/changelog | 15:05 |
| LeePen | I think all that matters to jenkins is that it is different. And all that matters to dak is that the version number is higher in that particular suite. | 15:05 |
| LeePen | fsmithred: Have a look at the latest debhelper(7). The section 'v11 changes from v10' seems to cover it. | 15:09 |
| fsmithred | How to use an empty override target to disable dh_installsystemd? | 15:11 |
| LeePen | In debian/rules just add | 15:11 |
| LeePen | override_dh_installsystemd: | 15:12 |
| LeePen | with at least 1 enpty line after it. | 15:12 |
| fsmithred | thanks | 15:12 |
| fsmithred | missing separator on that line in debian/rules | 15:13 |
| LeePen | hmmm | 15:17 |
| fsmithred | needed a tab | 15:17 |
| fsmithred | and the override isn't working | 15:18 |
| fsmithred | dh_systemd_enable: dh_systemd_enable is no longer used in compat >= 11, please use dh_installsystemd instead | 15:19 |
| fsmithred | Here's what I started with in rules: | 15:19 |
| fsmithred | include /usr/share/cdbs/1/rules/buildcore.mk | 15:19 |
| fsmithred | include /usr/share/cdbs/1/rules/debhelper.mk | 15:19 |
| fsmithred | binary-fixup/desktop-base:: | 15:19 |
| fsmithred | dh_gconf --priority=15 | 15:19 |
| fsmithred | do I need to put the override before the includes? | 15:19 |
| rrq | LeePen: re policykit on arm64 -- you want a second try? | 15:21 |
| LeePen | Yes please. The compress ran oom. | 15:22 |
| LeePen | I hope you didn't mind me reusing your build? | 15:22 |
| LeePen | I can't trigger new beowulf builds | 15:22 |
| rrq | no worries. | 15:23 |
| rrq | it's likely to get oom again of course, but we'll see | 15:23 |
| LeePen | fsmithred: I have hardly ever used cdbs | 15:25 |
| fsmithred | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885407 solution: use 9 or 10 | 15:25 |
| LeePen | Good find. I get the impression cdbs is on the way out | 15:29 |
| rrq | fsmithred: new netinstall iso; now with all udeb in the pool. | 15:32 |
| fsmithred | Looks like I should bump the version to 3.something. (1:1.2 in jessie, 1:2.0.3 in ascii, so 1:3.0 in beowulf?) | 15:32 |
| LeePen | fsmithred: Seems reasonbale | 15:33 |
| rrq | anyone sitting on an extlinux udeb? would be nice to offer that as installer option, in addition to grub and lilo | 15:35 |
| LeePen | rrq: arm64 still oom: | 15:36 |
| LeePen | 14:35:04 dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory | 15:36 |
| rrq | can you run "dpkg-buildpackage -us -uc -B -rfakeroot" on it locally, to get a comparison? | 15:41 |
| fsmithred | rrq, did you figure out why lxqt was installed? | 15:41 |
| rrq | no I dropped that thread.. | 15:42 |
| LeePen | rrq: was the dpkg-buildpackage for me re failed arm64? | 15:46 |
| rrq | yes | 15:46 |
| rrq | I'll look at build #66 vs #69 | 15:46 |
| LeePen | I have already built it in a beowulf pbuilder (amd64) | 15:47 |
| fsmithred | ok, how do I create a project label? | 15:55 |
| rrq | LeePen: looks like it's due to a race in the build process | 15:55 |
| fsmithred | the obvious, select "Create project label" does nothing. | 15:55 |
| rrq | you need to select it after creating it | 15:56 |
| fsmithred | I can't create it | 15:56 |
| rrq | there's a button if you scroll down far enough | 15:56 |
| fsmithred | yeah, it says Create project label in the drop-down | 15:56 |
| fsmithred | one would assume that it's used for creaing a new project label. | 15:57 |
| fsmithred | but selecting it and giving it a name does nothing. | 15:57 |
| fsmithred | so I must be doing it wrong | 15:57 |
| rrq | the 'create project label' brings up a tyne creation dialog, which has a 'create' button below the visible bottom | 15:59 |
| fsmithred | I found instructions. Have to go to the issues button on the left side, then go to labels. | 16:00 |
| rrq | i.e.: give it a name, pick a colour, then scroll down and click 'create' | 16:00 |
| fsmithred | I tried that method three times | 16:00 |
| fsmithred | seems obvious | 16:00 |
| rrq | then, after creating it, you still need to select it for the issue | 16:01 |
| fsmithred | which I'm beginning to believe should be a warning sign | 16:01 |
| fsmithred | can't select it because it doesn't get created | 16:01 |
| LeePen | rrq: bbib | 16:02 |
| LeePen | biab! | 16:02 |
| fsmithred | ok, got it | 16:03 |
| fsmithred | they should get rid of that 'Create label' entry in the label drop-down menu | 16:03 |
| rrq | as soon as we've collected our wits, we'll migrate away ... | 16:04 |
| fsmithred | yeah, I'm looking forward to it | 16:05 |
| fsmithred | oh, I better build the icon and window themes for beowulf, too. d-b needs them. | 16:05 |
| rrq | LeePen: a third try, where I operated the "wipe the workspace" button first | 16:07 |
| LeePen | rrq: :( | 16:18 |
| LeePen | I got to go for a bit. bbl | 16:18 |
| rrq | LeePen: successful build (arm64) #67 doesn't have those dh_shlibdeps complaints that the faile builds (68-70) attract | 16:30 |
| rrq | maybe removing those "useless dependencies" is good? | 16:34 |
| rrq | goodnight | 16:36 |
| fsmithred | clearlooks-phenix-darkpurpy-theme won't build for unstable. https://ci.devuan.org/job/clearlooks-phenix-darkpurpy-theme-source/lastBuild/console | 17:31 |
| fsmithred | This theme has been a major pain in the ass right from the start. If someone wants to take over and sort it out, I'd be happy to give it up. | 17:32 |
| golinux | fsmithred: Sorry it's being a difficult child. | 17:51 |
| fsmithred | I think part of the problem is that katolaz bumped the version in dak. Not sure about that. | 17:54 |
| fsmithred | gotta go. back in a little bit. | 17:54 |
| fsmithred | back | 18:39 |
| fsmithred | cinnabar theme won't build in beowulf because of the change we made in gtkrc | 18:53 |
| golinux | The minor color change? | 18:53 |
| golinux | Not that important. If you revert, will it be happy? | 18:54 |
| fsmithred | maybe | 18:56 |
| fsmithred | but I have to figure out how to give it a proper version number wihtout bumping the upstream version number | 18:57 |
| fsmithred | fuck it, I'm gonna add +devuan | 18:58 |
| fsmithred | in case upstream bumps their version next time | 18:58 |
| fsmithred | golinux, what was the old color? | 18:59 |
| fsmithred | nm, found it | 19:01 |
| mason | fsmithred: Is there any downside to using +devuan across the board for packages we customize? It seems like the right thing to do to me. | 19:04 |
| fsmithred | we use that for packages that we modify from debian | 19:04 |
| fsmithred | in this case, we changed the package name, so we didn't add the +devuan | 19:04 |
| fsmithred | I wish we could agree on what the number after the +devuan means | 19:05 |
| mason | ah | 19:05 |
| fsmithred | and my personal preference would be to align the first digit of that number with the release number | 19:05 |
| mason | fsmithred: Do we have a document somewhere with a general stab at it? Be useful to document it and then argue it out if people feel differently. | 19:06 |
| mason | Devuan release, not upstream, yes? | 19:06 |
| fsmithred | so +devuan1 for jessie, +devuan2 for ascii, +devuan3.1 for first revision of beowulf version | 19:06 |
| mason | fsmithred: How about an explicit 0 for first version? | 19:06 |
| fsmithred | not sure if it's documented | 19:06 |
| fsmithred | yeah | 19:06 |
| fsmithred | 3.0 | 19:06 |
| mason | fsmithred: Seems worth documenting, and I like the dot zero so it's uniform. | 19:07 |
| fsmithred | I think some are done that way | 19:07 |
| mason | Machine sortable == win. | 19:07 |
| fsmithred | gbp:error: Can't determine upstream version from changelog | 19:09 |
| fsmithred | desktop-base in beowulf will fail until this is fixed | 19:13 |
| fsmithred | I suppose I could bump 7.0.1-3 to 7.0.1-3-1 or some other stupid workaround | 19:13 |
| fsmithred | I really wanted to be done with this before I go away. | 19:14 |
| amesser | fsmithred: what is the actual versoin which gives the gbp error? | 19:18 |
| DPA | I've created a bug report yesterday, which affects basically all packages built on devuan: https://bugs.devuan.org//cgi/bugreport.cgi?bug=353 . I now this may be unnecessary to say her, but I just wanted make sure y'all are aware of it. | 19:23 |
| fsmithred | amesser, last one I tried was 7.0.1-3+devuan3.0 | 19:38 |
| fsmithred | version currently in unstable is 7.0.1-3 | 19:38 |
| amesser | hm should be fine | 19:38 |
| fsmithred | which is the same as the version of clearlooks-phenix-theme | 19:38 |
| fsmithred | from which it was modified | 19:39 |
| amesser | is a tag in the git repo which maches the definition in debian/gbp.conf ? | 19:39 |
| fsmithred | oh, I didn't make a tag | 19:39 |
| fsmithred | and I don't know how to answer that question | 19:39 |
| fsmithred | [DEFAULT] | 19:41 |
| fsmithred | ignore-branch=true | 19:41 |
| fsmithred | upstream-tag=v%(version)s | 19:41 |
| fsmithred | [buildpackage] | 19:41 |
| fsmithred | compression-level=9 | 19:41 |
| fsmithred | the only tags are from upstream | 19:41 |
| amesser | ok, the upstream-tag=v%(version)s means, that gbp would expect to find a tag "v7.0.1" | 19:49 |
| fsmithred | git tag | 19:49 |
| fsmithred | archive/debian/7.0.1-2 | 19:49 |
| fsmithred | debian/7.0-1 | 19:49 |
| fsmithred | debian/7.0-2 | 19:49 |
| fsmithred | debian/7.0.1-1 | 19:49 |
| fsmithred | debian/7.0.1-2 | 19:49 |
| fsmithred | debian/7.0.1-3 | 19:50 |
| fsmithred | 7.0.1-3 built without problems for unstable | 19:50 |
| fsmithred | does that line need to be in gbp.conf? | 19:51 |
| amesser | hm, thats strange | 19:53 |
| fsmithred | what's strange? | 19:53 |
| amesser | the line is only for gbp to know how it can derive the upstream version from a debian pkg version | 19:53 |
| amesser | that it builds with 7.0.1-3 but not with 7.0.1-3+devuan3.0 since the split should occur at the "-" | 19:54 |
| fsmithred | why does it need to know the upstream version? | 19:54 |
| amesser | usually building a deb package involves building the original source archive as well. | 19:55 |
| amesser | gbp does this by getting the "upstream tag" from the git repo and tar-ing it | 19:55 |
| amesser | (this is the "orig" .tar.xz) | 19:56 |
| fsmithred | how can I tell gbp to stfu and build the package? | 20:11 |
| amesser | you mean if you invoke by commandline on your wokrstation? | 20:17 |
| fsmithred | I mean to force it to build this package for beowulf | 20:18 |
| fsmithred | unless someone is around who can move the ceres package to beowulf | 20:18 |
| amesser | well, its an commandline option meant for testing only: | 20:19 |
| amesser | gbp buildpackage --git-no-create-orig | 20:19 |
| fsmithred | I don't need to test on commandline. I can build it locally and it works. | 20:21 |
| fsmithred | oh | 20:21 |
| fsmithred | I didn't test build with the new version | 20:22 |
| mason | Argh, we don't ship elilo. | 20:48 |
| LeePen | rrq: Hope you slept well. | 22:23 |
| LeePen | I have been diffing the amd64 (successful) and arm64 (failure) builds of policykit on beowulf: | 22:24 |
| LeePen | http://ix.io/1Wsc | 22:26 |
| LeePen | The things that caught my eye are that arm64 has an older version of jenkins-devuan-glue and doesn't seem to use eatmydata. Does the arm64 host need updating? | 22:27 |
| LeePen | Alternatively, I may be on completely the wrong track. | 22:27 |
| LeePen | I'll check back in the (my!) morning. | 22:28 |
| LeePen | Thanks. | 22:28 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!