| === gusnan is now known as Guest34322 | ||
| Crimson_Rogue | Hello. I need access o ubuntu-touch-dev channel, please! | 02:22 |
|---|---|---|
| Crimson_Rogue | thanks in advance | 02:22 |
| mwhudson | does anyone know how this page is created or deployed? https://help.ubuntu.com/lts/installation-guide/index.html | 03:41 |
| cpaelzer | doko: seb128: good mornign +1 crew of the day - unfortunately the tests queue grew even bigger | 04:54 |
| cpaelzer | so we have even more delay between action and being processed :-/ | 04:54 |
| cpaelzer | In a world were the queues would have been drained by now I'd have restarted the perl regressions cobined with the triggers for the four rebuilds that formerly had a dependency on <<5.30.3 - this seems to be the majority of the issues that I can see | 04:56 |
| cpaelzer | but this isn't perfect and I feel bad for letting a) remaining architectures run into a known test-fail due to these dependencies and b) let them run into these fails just to restart them (could use the extra triggers right away) | 04:57 |
| cpaelzer | doko: seb128: does one of you have the powers (or someone else around) to cancel autopkgtests from the queue so that we can re-insert them with the right triggers and only run them once? | 04:58 |
| === M_hc[m] is now known as _hc | ||
| doko | cpaelzer: sorr, no | 06:52 |
| cpaelzer | doko: do you know who could? | 06:54 |
| cpaelzer | with about 26k tests in the queue I really would want to avoid throwing more tests on top without aborting the old (liekly to fail) ones | 06:55 |
| doko | counting tests across architectures doesn't make sense. but yes, the load is high, but less than yesterday | 06:59 |
| cpaelzer | more than yesterday aroudn the same time :-) | 07:00 |
| cpaelzer | anyway, there is not much we can do for the queue other than wait and not fill it when we could do better | 07:00 |
| Laney | cpaelzer: if you can work out which tests need to be cancelled I can do that | 08:04 |
| Laney | it's a regex which matches on the strings you see in the queue so that form is preferred | 08:06 |
| cpaelzer | Laney: hi and thanks in advance | 08:14 |
| cpaelzer | Laney: with line you mean the entries like 'libdatetime-format-w3cdtf-perl {"triggers": ["perl/5.30.3-1"], "submit-time": "2020-06-02 08:57:21"}' | 08:14 |
| Laney | indeed | 08:15 |
| cpaelzer | ok, that should be doable - but I'll do some safety checks before I pass it to you ... | 08:15 |
| cpaelzer | Laney: will they then be listed as failed (or any other defined state) as I'd like to use retry-autopkgtest-regressions to resubmit the list with the right triggers? | 08:16 |
| cpaelzer | and finally, IIRC pitti once said there is ajson output of the lists at http://autopkgtest.ubuntu.com/running - do you know where that is? | 08:17 |
| Laney | cpaelzer: They will be RUNNING or RUNNING-ALWAYSFAIL | 08:20 |
| Laney | and /queues.json is probably what you want | 08:20 |
| pitti | cpaelzer, Laney: o/ | 08:21 |
| Laney | hey pitti | 08:21 |
| pitti | wow, nice to look at autopkgtest.u.c. again -- still looks very familiar :) | 08:21 |
| cpaelzer | hiho pitti | 08:21 |
| pitti | and I see the queues are as long as they used to be | 08:21 |
| Laney | perl is very thouroughly tested! | 08:21 |
| pitti | http://autopkgtest.ubuntu.com/statistics takes a lot of time | 08:22 |
| cpaelzer | Laney: the json is what I wanted thanks. Do you need the regex to match against the json, the text output in the browser or the HTML-escaped text that is transferred? | 08:23 |
| Laney | cpaelzer: if you unescape the quotes, that is the raw contents of the queue item which we're matching against | 08:27 |
| cpaelzer | ok | 08:27 |
| Laney | per queue, it's like filter-amqp user:pass@host queue_name regex | 08:27 |
| cpaelzer | hmmm, I just realized that the rate of the tests running into the known dependency issue got much better | 08:32 |
| cpaelzer | yesterday it was about 1/5th of the tests, so I wanted to abort all and restart with the right triggers | 08:32 |
| cpaelzer | but all the tests that got added since then didn't run into the same | 08:33 |
| cpaelzer | so I might be good with just re-scheduling the failed cases | 08:33 |
| cpaelzer | sorry Laney for the noise then, I think we are good without mass-cacnel+mass-restart then | 08:33 |
| cpaelzer | if the ratio changes I'll let you know | 08:33 |
| Laney | ok | 08:33 |
| cpaelzer | and I'll still come up with a list to cancel, just not all 16k - more like a few dozen or so | 08:34 |
| doko | cpaelzer, seb128: I'm currently working on ftbfs starting from the archive opening. I'm skipping ubuntu-app-launch, would be nice if someone with desktop experience could look at that | 08:37 |
| doko | RikMills: could you have a look at the qt-gstreamer ftbfs? | 08:39 |
| cpaelzer | ok doko | 08:39 |
| cpaelzer | doko: I was this morning also looking at excuses bottom-up for things not needing autopkgtests as the queue is so full - that is how I got to plinth that I asked about before | 08:40 |
| cpaelzer | doko: just ping here with the cases you grab so seb128 and I are aware - ok ? | 08:40 |
| doko | cpaelzer, seb128: working on rapmap | 08:42 |
| cpaelzer | ok doko, I'm about to reschedule the perl tests that are known to need extra triggers | 08:44 |
| cpaelzer | Laney: my regexp would be complete, it would be just 44 to cancel, probably not worth the hassle. When you do that do you get something like a confirmation which were effectively removed so that I can use the list to restart exactly the right set? | 08:51 |
| cpaelzer | and avoid e.g. update latency of update-excuses and such | 08:52 |
| Laney | cpaelzer: 44's probably not worth worrying about, I'd say optimise human time and take a bit of duplication there | 08:52 |
| RikMills | doko: qt-gstreamer is RC buggy in debian with that FTBFS, unmaintained upstream, and retired in fedora and probably other distros. I think we should look at the last rdeps in preperation to ditch it | 08:53 |
| doko | RikMills: do you volunteer? ;p | 08:53 |
| RikMills | doko: I can have a look. its only rdep has none itself. libreoffice recommends it, but that could well be legacy leftover | 08:56 |
| RikMills | who is good to ping for libreoffice now? | 08:56 |
| doko | hellsworth: ^^^ | 08:57 |
| RikMills | right. I think they are is the US. I'll have a look at the last actual rdep in the meantime | 08:58 |
| cpaelzer | agreed Laney | 09:03 |
| * cpaelzer is happy that it won't be the hundreds/thousands of retries that it seemed to be yesterday | 09:03 | |
| === ricab__ is now known as ricab | ||
| cpaelzer | doko: seb128: I'll take a look at php-horde-* | 09:42 |
| LocutusOfBorg | seb128, hello, please network-manager-applet merge? it might be good the one I did in my ppa if you want https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa | 10:04 |
| LocutusOfBorg | sil2100, hello it would be awesome to unblock initramfs-tools from focal unapproved queue. People are hit by this bug, I get report on telegram and somewhere else... | 11:05 |
| Crimson_Rogue | Hello. | 11:58 |
| Crimson_Rogue | i'm needing access to the ubuntu touch development channel. | 11:58 |
| Crimson_Rogue | Thanks in advance. | 11:58 |
| xnox | Crimson_Rogue: the one from canonical is i guess here. | 12:02 |
| xnox | Crimson_Rogue: the community ubports effort => i don't know where | 12:02 |
| Crimson_Rogue | it is now an invite-only channel | 12:02 |
| Laney | I think they don't use IRC: https://ubports.com/join-us | 12:11 |
| Crimson_Rogue | #ubuntu-touch | 12:12 |
| xnox | Crimson_Rogue: the only active thing is ubports thing that Laney pointed out. If you are after historic ubuntu-touch development by Canonical & the Ubuntu Project, it's here. But the most we can say is that well, we ceased developing it. | 12:27 |
| seb128 | LocutusOfBorg, hey, sorry but I don't have the free slot from a nm library change/transition atm, why do you need it? | 12:27 |
| xnox | jibel: sorry, i have invalid email address for you in my address book. | 12:27 |
| xnox | jibel: i hope you are subscribed to the ubuntu-installer mailing list | 12:27 |
| xnox | jibel: hm but it is your launchpad-id and it should work | 12:28 |
| xnox | jibel: do you have your launchpad sso or ubuntu sso set to invalid default email address? or is there a loop? | 12:28 |
| sil2100 | LocutusOfBorg: hey! Ok, I'll look at it tomorrow for sure during my shift, or later today if I have a few cycles | 12:53 |
| LocutusOfBorg | thanks sil2100 | 13:01 |
| LocutusOfBorg | seb128, there is an annoying auto sync issue with the binary takeover for it... | 13:02 |
| LocutusOfBorg | it should be a trivial thing to do, modulo MIRing the new libnm promoting | 13:02 |
| seb128 | LocutusOfBorg, "modulo MIR' :p | 13:02 |
| Crimson_Rogue | I'll be back later. thank you for the info. | 13:03 |
| === heliocastro is now known as helio|afk | ||
| seb128 | LocutusOfBorg, what's the autosync issue? it just didn't sync because it takes over binaries no? | 13:05 |
| RikMills | doko: is qt-gstreamer blocking anything? I found a patch to fix the ftbfs, but am not keen to apply it to something basically dead, unless it is a blocker for something | 13:07 |
| LocutusOfBorg | yes seb128 | 13:07 |
| seb128 | LocutusOfBorg, so it's practice it's some debt but not creating an active problem? | 13:08 |
| LocutusOfBorg | there are few fixes in the new network-manager and libnma, as usual, but nothing too serious | 13:17 |
| seb128 | LocutusOfBorg, I'm opened https://bugs.launchpad.net/ubuntu/+bug/1881906 | 13:19 |
| ubottu | Launchpad bug 1881906 in Ubuntu "[MIR] libnma" [Undecided,New] | 13:19 |
| seb128 | launchpad is buggy, https://launchpad.net/ubuntu/+source/libnma exists and includes a 'report a bug' but that just ooops | 13:19 |
| LocutusOfBorg | thanks, can I maybe just do it then? | 13:20 |
| LocutusOfBorg | I mean, I can merge network-manager | 13:20 |
| LocutusOfBorg | and that library will auto sync | 13:20 |
| seb128 | LocutusOfBorg, if you want to do the merge feel free yes | 13:21 |
| seb128 | I can review/upload if you wish | 13:21 |
| wgrant | seb128: well it's oopsing because the package doesn't exist in Ubuntu! | 13:22 |
| wgrant | The package should probably have 404d | 13:22 |
| wgrant | MIRing something that doesn't exist seems weird. | 13:22 |
| wgrant | Oh autosync failed, I see. | 13:23 |
| seb128 | wgrant, well, launchpad gives me a working https://launchpad.net/ubuntu/+source/libnma page and let me open the 'file a bug' screen and enter all the details, so that's confusing | 13:23 |
| wgrant | Absolutely. | 13:23 |
| cjwatson | https://bugs.launchpad.net/launchpad/+bug/1635118 | 13:23 |
| ubottu | Launchpad bug 1635118 in Launchpad itself "Submitting bug for non-existent distro source package triggers OOPS on submission, should not allow you to start" [Critical,Triaged] | 13:23 |
| seb128 | cjwatson, thanks | 13:23 |
| seb128 | wgrant, while I've you around ... :) did you use any sort of magic to build pulseaudio on riscv64 before focal? it has a test consistently failing there is focal/groovy, which security bypassed and published without the arch, but it's blocking other fixes now and I'm unsure how to deal with it | 13:25 |
| wgrant | seb128: Nothing special, I'm afraid. | 13:25 |
| seb128 | I wonder if the SRU team would be open to publish with that arch missing | 13:25 |
| seb128 | since the current security update is already not built there... | 13:26 |
| seb128 | SRU team,opinion on ^? | 13:26 |
| wgrant | seb128: Can you just disable that test on that arch? | 13:26 |
| seb128 | wgrant, I guess I could, it means doing another round of upload/getting the SRU approved/verified/etc | 13:27 |
| seb128 | which would set us back again for landing an important fix | 13:27 |
| seb128 | (which already happened once since the SRU was superseeded by a security update) | 13:27 |
| * jdstrand notes that riscv64 is considered a 'bonus architecture' for security updates and we'll publish without it | 13:29 | |
| jdstrand | I mentioned this before, but neither the security update nor the SRU fixes introduced the failing test case | 13:30 |
| jdstrand | it is the act of rebuilding. iirc, the particular test demonstrates it is non-functional. if that is true, I suggest not papering over it and letting it fail and ignoring the failure in the sru | 13:31 |
| jdstrand | s/failing test case/failure in the test case/ | 13:32 |
| cpaelzer | doko: seb128: azure-cli is green in proposed-migration now | 13:34 |
| cpaelzer | doko: seb128: looking at python-azure now which is part of the same set | 13:34 |
| seb128 | ack | 13:36 |
| rbasak | Why is vala in universe if desktop stuff in main (eg. simple-scan) build-depends on it? As a preprocessor/generator type thing, doesn't it need to be in main for security support? | 14:10 |
| doko | RikMills: sure, we can remove it instead | 14:11 |
| juliank | rbasak: it technically works | 14:11 |
| juliank | rbasak: this could make sense, but the same argument would apply to any header-only library | 14:12 |
| juliank | it's a bit hard to figure out which those are I suppose | 14:12 |
| rbasak | juliank: indeed, but I thought the relaxation of the build-depends-drags-into-main rule came with this condition? | 14:12 |
| juliank | rbasak: possibly, but you don't necessarily notice it if you happen to include code generated by universe components | 14:13 |
| rbasak | Right, but I noticed, and it's trivial to check everything that build depends on valac. So does this now need to be fixed? | 14:13 |
| juliank | which is why I don't like the rule relaxation, as it works only sensible for dynamically linked libraries :) | 14:14 |
| juliank | I'm not super sure about this, because you don't want to support valac for 3rd parties | 14:14 |
| juliank | just because we need it at build-time for some packages, does not mean we should provide security support for the entire thing | 14:15 |
| rbasak | https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html documented the change | 14:15 |
| rbasak | "If you have a build-dependency which does not result in a runtime dependency, but *does* result in code being copied into the final package, you must ensure that this code copying is declared using the Built-Using header" | 14:16 |
| rbasak | vorlon: ^ what's your opinion on how that applies to vala? | 14:16 |
| rbasak | juliank: I understand that concern, but that is just the regular consequence of things in main. | 14:17 |
| juliank | the same also applies to other packages, like triehash | 14:18 |
| juliank | (triehash is APT's perfect hash function generator) | 14:18 |
| juliank | (it generates C code) | 14:18 |
| juliank | (but it's just generating switches, so meh) | 14:18 |
| hellsworth | RikMills: what's up with libreoffice (i see the ping from the middle of my night) | 14:19 |
| rbasak | mdeslaur is TB and security so might also have a useful opinion on this? ^ | 14:19 |
| juliank | Apart from the policy question, it's basically a question of whether security team can do security maintenance on code generators in universe to the extend they pertain to our own uses of them | 14:20 |
| juliank | and if they are aware of that thing | 14:20 |
| mdeslaur | hrm, yeah, stuff like that is complicated | 14:21 |
| cpaelzer | doko: seb128: I'm going to look at the haskell related FTFBS, but no promise I can do anything but stare at them with an angry face | 14:23 |
| cpaelzer | 1179 hits in update-excuses is worth a look fur sure ... | 14:23 |
| rbasak | I just became aware of it because the other day I processed an SRU for some package that regressed and needed a rebuild following a vala SRU, so was quite aware of this - and just now processed a vala SRU and was surprised to see it in universe. | 14:23 |
| seb128 | cpaelzer, ack | 14:24 |
| mdeslaur | I don't think vala actually copies code, its processes it...but I guess it could introduce a security issue that needs to be fixed in vala | 14:24 |
| rbasak | Right...and then would require a rebuild of everything that build-depended on it | 14:24 |
| mdeslaur | but a CVE would be assigned to the application in most cases, not to vala itself, even if ultimately the issue is vala | 14:24 |
| mdeslaur | yes, a rebuild | 14:24 |
| rbasak | Anyway | 14:24 |
| rbasak | I don't mind what you decide | 14:24 |
| rbasak | I just wanted to make sure it wasn't falling into a gap. | 14:24 |
| rbasak | It's between security and the TB I guess :) | 14:25 |
| mdeslaur | well, I'm not really deciding anything :) | 14:25 |
| mdeslaur | but I don't feel strongly enough to escalate it | 14:25 |
| rbasak | Well, you sit on both teams, so your problem now :-P | 14:25 |
| doko | cpaelzer, seb128: looking at sleef and rdeps | 14:25 |
| seb128 | cpaelzer, doko, I'm looking at pygame | 14:25 |
| mdeslaur | rbasak: haha, "thanks" | 14:26 |
| mdeslaur | :) | 14:26 |
| rbasak | Not feeling strongly enough to escalate it is also a decision. That you're making. Which I'm also fine with :) | 14:26 |
| cpaelzer | doko: seb128: in case you miss my pings I usually also live update https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status when I pick new things | 14:30 |
| seb128 | cpaelzer, sounnds like a good idea, I should do the same | 14:30 |
| RikMills | hellsworth: libreoffice-qt5 recommends qtgstreamer-plugins-qt5 which is currently ftbfs and unmaintained/dead upstream. removed from distros like opensuse, fedora etc. so I wondered if libreoffice got any benefit from that any more, or if it might be some legacy recommends that could be dropped | 14:33 |
| RikMills | or at least if not kn own, could be looked into | 14:33 |
| hellsworth | ah ok cool thanks for the backstory. my guess is that it is a legacy recommends that could be dropped but i dont know for sure :) | 14:34 |
| hellsworth | i'l try building/testing it without qtgstreamer-plugins-qt5 and get back to you | 14:35 |
| hellsworth | takes forever for it to build so maybe a day or two... | 14:35 |
| RikMills | ok. ty :) | 14:36 |
| doko | hellsworth: why do you need a rebuild to check for a recommendation? | 14:38 |
| hellsworth | well recommended gets installed when you install libreoffice | 14:40 |
| seb128 | jdstrand, ack | 14:40 |
| hellsworth | so is there a runtime problem if that dep doesn't get installed? that's what i figured i'd answer with a rebuild | 14:40 |
| hellsworth | well i could just uninstall that dep and hope things are fine.. but there's still room for a runtime issue to crop up | 14:41 |
| seb128 | slyon, hey, I wonder if the netplan.io/arm64 autopkgtest failure on groovy with the new n-m is something you looked at yet? | 14:43 |
| seb128 | slyon, http://autopkgtest.ubuntu.com/packages/n/netplan.io/groovy/arm64 | 14:43 |
| seb128 | it keeps failing so it's looking a real issue | 14:43 |
| slyon | hey seb128. I had a short look at it but it's non-obvious what's happening there... I have it on my list and will have a closer look in the next couple of days | 14:45 |
| seb128 | slyon, thanks | 14:45 |
| rbasak | didrocks: I'm looking at your docker.io focal SRU. May I have some help understanding the issue please? | 14:48 |
| rbasak | I think I follow what's going wrong, but not what a user is doing that causes it to go wrong. | 14:48 |
| rbasak | What's the user story associated with this bug? | 14:48 |
| rbasak | For example: does this break all docker.io users with ZFS on root on Focal? Or just some? And if just some, what are they doing (if anything) to trigger it? | 14:49 |
| doko | hellsworth: yes, so why the rebuild? | 14:50 |
| didrocks | rbasak: it breaks all docker.io users with ZFS on root on Focal is they don’t docker rm <container> | 14:52 |
| didrocks | if* | 14:52 |
| didrocks | which I guess most of users seem to do seeing the bug reports we are getting | 14:52 |
| didrocks | (basically, creating tons of datasets) | 14:52 |
| didrocks | which are then backed up | 14:52 |
| didrocks | creating even more datasets | 14:52 |
| rbasak | didrocks: ah - so if users don't clean up their own containers and end up with a large number of them, then zsys starts to time out? | 14:53 |
| LocutusOfBorg | seb128, better move here :) | 14:53 |
| didrocks | rbasak: yeah, also native zfs commands start to be really slow | 14:53 |
| seb128 | LocutusOfBorg, right | 14:53 |
| didrocks | the idea to is thus to move them outside of the backup realm to not create snapshots | 14:53 |
| didrocks | which reduces greatly the number of datasets | 14:53 |
| rbasak | That makes sense for Groovy. I have a concern about doing is in Focal though. | 14:54 |
| rbasak | about doing this in Focal | 14:54 |
| didrocks | rbasak: well, I don’t see any alternative TBH, otherwise they whole system will stop functionning at some point | 14:54 |
| rbasak | Most importantly, you'll be changing users' systems to stop backing up what they were previously backing up? | 14:54 |
| LocutusOfBorg | seb128, it worked | 14:54 |
| LocutusOfBorg | meh the conflicts were related to debian stuff | 14:54 |
| rbasak | That's a pretty severe change in behaviour I think! | 14:55 |
| didrocks | rbasak: right, but those are containers themselve | 14:55 |
| rbasak | Is zsys packaged in Ubuntu? | 14:55 |
| didrocks | it’s seeded by default | 14:55 |
| LocutusOfBorg | I pushed, if you can have a look, it would be really nice | 14:55 |
| seb128 | LocutusOfBorg, well, that's what a merge is about, resolving conflicts :) | 14:55 |
| didrocks | and again, it doesn’t only impact zsys | 14:55 |
| seb128 | LocutusOfBorg, k | 14:55 |
| didrocks | but zfs commands as well | 14:55 |
| didrocks | with very greatly increased boot time | 14:55 |
| LocutusOfBorg | seb128, I resolved them with MoM stuff | 14:55 |
| rbasak | I appreciate the problem and that it needs to be fixed somehow. | 14:55 |
| didrocks | (like up to a minute to import the pool if you go to the extreme) | 14:55 |
| LocutusOfBorg | but I thought they were related on upstream changes, not debian packaging bits, this is why I gave up | 14:55 |
| LocutusOfBorg | lol, when I looked better, it was trivial | 14:56 |
| seb128 | :) | 14:56 |
| rbasak | I'm just not sure that this is the right way for Focal. | 14:56 |
| rbasak | didrocks: I have a meeting now. Let me ponder this. | 14:57 |
| seb128 | LocutusOfBorg, seems fine to me, please just undo the gbp.conf branch name change (or change to ubuntu/master and push there) | 14:57 |
| seb128 | -debian-branch = master | 14:57 |
| seb128 | +debian-branch = debian/master | 14:57 |
| LocutusOfBorg | done thanks! | 14:58 |
| seb128 | thanks! | 14:58 |
| didrocks | rbasa: ack, keep me posted :) | 14:58 |
| LocutusOfBorg | I still need to learn something on the ubuntu git vcs stuff VS MoM | 14:58 |
| hellsworth | RikMills: doko: libreoffice-qt5 seems fine if qtgstreamer-plugins-qt5 is removed.. this change will need to go into the next release of libreoffice | 15:20 |
| doko | ta | 15:31 |
| === helio|afk is now known as heliocastro | ||
| bdmurray | marcustomlinson: Can you help with SRU info for bugs 1880987 (saying look at the error tracker is fine) and bug 1874591? I'll prepare the 20.04 upload | 16:55 |
| ubottu | bug 1880987 in update-manager (Ubuntu) "/usr/bin/update-manager:TypeError:_on_finished:_action_done:get_deb2snap_dups:_on_finished:_action_done:get_deb2snap_dups" [High,Fix released] https://launchpad.net/bugs/1880987 | 16:55 |
| ubottu | bug 1874591 in update-manager (Ubuntu) "[SRU] AptUrl GTK window stuck on screen after install completed" [High,Fix released] https://launchpad.net/bugs/1874591 | 16:55 |
| marcustomlinson | bdmurray: k done | 17:07 |
| bdmurray | marcustomlinson: great, thanks! | 17:24 |
| vorlon | rbasak: I certainly don't think vala is any sort of exception to that rule | 18:21 |
| rbasak | vorlon: (not an) exception in which direction? | 19:06 |
| vorlon | rbasak: if packages build-depend on vala things which results in vala code being copied into the target binary package whose source package is the build-dependency rather than the binary package's own source package, then that package should be listed in built-using | 19:08 |
| vorlon | because the whole point of the exercise is to be able to have metadata that we can use to track the source of the binary package, for both licensing and security | 19:08 |
| rbasak | vorlon: does code generation count as being copied? | 19:09 |
| vorlon | what's the source of the code being generated? | 19:09 |
| rbasak | AIUI, code written in vala is converted by valac to C and then goes through the normal toolchain | 19:10 |
| rbasak | So vala is essentially part of the toolchain, and a security vulnerability in vala would require vala to be updated before a rebuild to fix the issue | 19:10 |
| vorlon | ok, I don't see why that would be different from gcc or binutils | 19:10 |
| vorlon | which don't get put into built-using | 19:10 |
| rbasak | And if it doesn't get put into built-using you don't mind vala being in universe as a build dependency in this fashion? | 19:11 |
| vorlon | or bison or flex or | 19:11 |
| vorlon | I don't | 19:11 |
| rbasak | OK, thanks | 19:11 |
| vorlon | in principle | 19:11 |
| rbasak | Yes flex is closer to my understanding of what vala is doing | 19:11 |
| vorlon | doko might disagree and want it in main | 19:11 |
| vorlon | but that would be an argument for explicitly seeding it rather than expecting it to be in built-using | 19:12 |
| xnox | another example is dbus-bindinding-tool which is quite similar to valac too | 19:57 |
| xnox | (it takes xml, and spits out C code, that gets compiled into the final binary) | 19:57 |
| xnox | or like any of our documentation toolchains, like pandoc | 19:57 |
| xnox | To me built-using is about static linking or vendorisation; i.e. copy the binary from another .deb and ship it again, in a different path or form | 19:59 |
| hellsworth | there is a new libreoffice 6.4.4 package being built for proposed but the s390x builds are failing | 19:59 |
| hellsworth | It looks like the builder had some issue installing | 19:59 |
| hellsworth | 'sbuild-build-depends-libreoffice-dummy' from apt. Rightfully so because | 19:59 |
| hellsworth | this package is nowhere to be found in the archive. I don't know what is | 19:59 |
| hellsworth | prompting the install of this package.. | 19:59 |
| hellsworth | we've relaunched the buidl and it it still fails the same way | 20:00 |
| hellsworth | here is the current log: https://launchpad.net/ubuntu/+source/libreoffice/1:6.4.4-0ubuntu1/+build/19401810 | 20:00 |
| hellsworth | there's nothing in the s390x build log in a ppa that tries to install sbuild-build-depends-libreoffice-dummy | 20:02 |
| hellsworth | any thoughts on this? Maybe the s390x has some sort of broken deps or this is accidentally being attempted to be installed | 20:02 |
| vorlon | xnox: agreed | 20:05 |
| === ben_r_ is now known as ben_r | ||
| cjwatson | hellsworth: sbuild-build-depends-<foo>-dummy is a package that sbuild synthesises based on all the build-depends | 20:17 |
| cjwatson | hellsworth: You should be able to reproduce the same thing in a local sbuild installation | 20:18 |
| cjwatson | hellsworth: Well, not on s390x I guess ... try chdist then | 20:18 |
| RikMills | sbuild-build-depends-libreoffice-dummy : Depends: fontforge-nox but it is not installable or | 20:18 |
| RikMills | fontforge but it is not installable | 20:18 |
| cjwatson | hellsworth: That's basically sbuild's way of saying that your package's build-dependencies aren't installable | 20:18 |
| cjwatson | Right, so focus on that not on the sbuild-build-depends-<foo>-dummy bit | 20:19 |
| cjwatson | ubuntu-archive@snakefruit:~$ chdist apt-get groovy-proposed-s390x install fontforge | 20:19 |
| cjwatson | ... | 20:20 |
| cjwatson | fontforge : Depends: fontforge-common (= 1:20190801~dfsg-4) but 1:20190801~dfsg-5 is to be installed | 20:20 |
| RikMills | fontforge 1:20190801~dfsg-5 ftbfs on s390x | 20:20 |
| cjwatson | IOw the problem is https://launchpad.net/ubuntu/+source/fontforge/1:20190801~dfsg-5/+build/19377545 | 20:20 |
| cjwatson | Right, that | 20:20 |
| cjwatson | It depends on an Architecture: all package from the same source, so stuff gets sad if they aren't in sync | 20:20 |
| RikMills | tests failed on s390x it seems? | 20:21 |
| cjwatson | I dunno, not going to dig further :) | 20:21 |
| RikMills | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961841 | 20:23 |
| ubottu | Debian bug 961841 in src:fontforge "fontforge FTBFS on 64bit big endian: test failures" [Serious,Open] | 20:23 |
| hellsworth | cjwatson: RikMills: thanks for putting me on the right path of fontforge | 20:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!