=== zyga_ is now known as zyga [07:53] thanks LocutusOfBorg for vlc 3.0 in bionic :) [08:17] Will bionic generate dbgsym packages automatically? [08:21] Uhh, Ubuntu has been doing that since about edgy. [08:21] So, yes. Bionic will too. [08:27] I mean debhelper, for third-party builds, not what Ubuntu's build hosts do [08:27] i.e. What Debian Stretch does that Debian Jessie did not [08:28] Using debhelper rather than pkg-create-dbgsym? Yes that's already been changed, though I doubt it matters for the resulting dbgsym package. [08:30] ...OK, I need to read better. Sorry, yes. This can already be done and has been for a little while (though in the past you could install that package.) [08:38] Mirv, you are welcome :) I'm sad for the missing chromecast support [08:46] ricotz: Out of curiosity, do you do anything or know of anything done with libdvdcss? I saw it in pkg-multimedia a bit ago. [08:50] Unit193, I don't think it qualifies to be uploaded in the official archives [08:50] Correct, it does not. [08:51] xnox: I have a small ubiquity question once you are around: does the "recursive" property of record_removed() will remove all unused rdepends or just depends ? (It sounds like get_remove_list() only does cache._depcache.broken) [08:52] xnox: and there is no apt autoremove at the end of the installation, correct? [08:55] Unit193: Thanks, what I mean is just whether dbgsym-files would automatically be created when running debuild. We (upstream MySQL) made some packaging changes for non-Stretch to replicate its behavior, and I noticed lintian is complaining about it in Bionic. We never used pkg-create-dbgsym (since as far as I know it's Ubuntu-specific) [09:01] Skuggen: Yes, dbgsym packages as created by debhelper are default, like in Debian. [09:02] Thanks (just means we have to drop that change from the upstream 18.04 packages) :) [09:03] Skuggen: Note that Ubuntu's will have a *.ddeb extension though. [09:04] https://patches.ubuntu.com/d/debhelper/debhelper_11.1.4ubuntu1.patch that's the difference between debhelper in Debian and Ubuntu, pretty minimal now. Not sure why we exclude changelogs though. [09:05] Unit193: Ah, that might actually matter, since our systems might just handle *.deb, thanks [10:12] jamespage: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg what have both python-libnacl and python-nacl? [10:13] doko: you might be asking the wrong person about that bit [10:13] * jamespage looks [10:15] but I agree having both seems a little silly [10:15] hmm, no they seem to be something different [10:17] roaksoax: ^^^ [11:05] xnox: do you mind if I upload http://paste.ubuntu.com/p/vR7hNwZSkt/ to bionic? this fixes an issue we have with snapd caused by a dbus/apparmor mediation change (cc jdstrand, feel free to weight in here) [11:34] hi all i need a bit help about writing bash , does somebody know bash writing here? [11:42] xeon_kyo: I suggest you ask in #bash, this channel is about developing ubuntu [11:44] unless of course, it's an Ubuntu-specific bash question [13:03] sil2100: do you have an exim4 merge planned soon? [13:26] xnox: FYI, I'm switching clamav to 0.99.3 final [13:45] Did anyone hear something about s2disk (or rather, resume) breaking in a recent xenial update? [13:47] juliank: the reverted intel microcode update was causing S3 problems [13:50] mdeslaur: I don't think there even are any microcode updates for Core i*-3* yet [13:52] latest updates were today [13:52] will do some more investigation [14:27] doko: TBH, no idea as i've not looked at what the differences are, but will take a look [14:38] roaksoax: maybe you could ask cjwatson about the differences in python-nacl and python-libnacl, he is one of the Debian uploaders [14:39] doko: that's what I waas planning on doing :) [14:42] different upstream projects with incompatible APIs [14:43] more or less similar functions [14:43] but AIUI switching from one to the other is basically a rewrite [14:44] not my fault :P [14:44] xnox (cc mvo and tyhicks): +1 for the systemd change. fyi, tyhicks and I are going to revisit the upstream dbus changes so there is a possibility at some point we can drop this later in the cycle, but that all depends on what happens with upstream dbus [14:54] Hey, can someone help me understand something? I'm trying to see if I can backport mingw-w64 from bionic (or artful?) to xenial, since the xenial version is badly broken [14:55] Trying just a plain `backportpackage` into a PPA didn't really work, all kinds of dependency issues [14:56] michagogo what kind of dependency mingw-w64 want? [14:56] One sec, let me look again [14:57] Actually, mingw-w64 worked fine, but gcc-mingw-w64 wanted binutils-mingw-w64. I tried to `backportpackage` that, and it failed because it needed binutils [14:58] When I tried binutils, it failed with this error: https://www.irccloud.com/pastebin/dFgEDKXz/ [14:58] In addition, gcc-mingw-w64 wanted gcc-7 [14:58] Maybe it's stupid, but why You have computer date at 1999? [14:59] Eh? I don't. [14:59] I'm not Christopher, either. [14:59] dpkg-genchanges: warning: debian/changelog(l7258): cannot parse non-comformant date '18 Sept 1999 01:21:05 -0400' [14:59] Okay, nevermid [14:59] nevermind [15:00] Are You try install binutils from tar.gz file? [15:01] All I used was `backportpackage`. That was the command that failed with that error I pasted above. [15:04] you might just need to edit the changelog manually then and rerun that dpkg-buildpackage command [15:05] or run it with a different -v argument [15:06] cjwatson: How do I do that? I have ~no experience with Ubuntu packaging [15:07] this will probably be too difficult a task then [15:07] I'm not even sure if what I'm doing makes sense, or if I'm leading myself on a wild goose chase by trying to just `backportpackage` anything it says is missing [15:07] the changelog is in debian/changelog, and the dpkg-buildpackage command was in your paste (run in the temporary directory that backportpackage created) [15:08] Maybe it's just a matter of editing the original gcc-mingw-w64 package to call for an older version or something? [15:08] you are probably in for a bad time in backporting a bunch of toolchain packages with no packaging experience, but OTOH there's probably little alternative if you want to backport mingw-w64, so ... [15:08] Is it just that I don't have experience? Meaning, would it be particularly hard/complex for someone who does know what they're doing? [15:09] a toolchain backport is always a bit of an unknown quantity [15:09] it might just be this one changelog bump in the road, or it might be a task that requires intimate understanding of binutils ... [15:10] Hmm. I was hoping that it might be simpler because it's not something that's used on the system itself, but rather just for cross-compiling [15:10] But OTOH maybe that's completely misguided [15:10] you could certainly start by just fixing the changelog syntax and building the source package with that, but I have no idea how many other complexities there'll be [15:10] and you WILL have to be prepared to do some research for yourself (e.g. looking up how to edit a changelog is going to be one of your easiest tasks here) [15:10] My end goal here is that I'm trying to find a way to allow people to build Bitcoin Core on Xenial [15:11] Right now, the build docs say to edit the apt sources file to pull from the... zesty, I think? repository and apt-get upgrade [15:11] And I know enough to know that that's... inadvisable [15:12] a chroot would no doubt be possible [15:12] Last I heard, chroot wasn't implemented in WSL... [15:14] cryptocurrencies and WSL are two things I know little about and am not interested in learning, so good luck :) [15:14] And in any case, I fear that may be too complicated [15:14] I mean, we already have gitian for building in a VM/LXC container [15:14] Heh, no need to learn about cryptocurrencies :-P [15:15] You can replace 'Bitcoin Core' with 'Some arbitrary package that fails to build with the Xenial version of g++-mingw-w64' [15:16] (Which, actually, _might_ actually be "all software" - I don't remember exactly what the problem was, but I think it was something pretty fundamental...) [15:38] Does anyone know if there's a general guide somewhere to backporting packages that do need to be changed and can't just be built as-is? Even a step-by-step explanation of what `backportpackage` actually does, so I can read and learn what the steps are, and figure out where to step in and change things? [15:39] I'm hoping (perhaps in vain?) that if I just change the dependencies to the GCC that's in Xenial it might work === superm1_ is now known as superm1 [15:48] michagogo: backportpackage is a pretty small script [15:48] I don't think it does much apart from tweak the changelog for you. [15:49] Yeah, I saw. It would be nice if it were in bash [15:49] But I see that it's all python using various libraries [15:49] No thanks. Doing it in bash would be a little insane IMHO. [15:50] Yeah, I didn't mean that I think the script should be in bash [15:50] I assume that the process can be accomplished using a series of commands [15:50] Hm [15:50] Maybe I'll just throw pdb in there> [15:50] Still, you'd have manipulate version string components. [15:51] You'd end up writing a tool to do the manipulation and call that from bash. [15:51] And we have that tool already - it's called backportpackage :) [15:51] rbasak: Yeah, the thing is right now I'm trying to do a non-no-change backport [15:52] michagogo: you know about debdiff, right? Run backportpackage, see what it did with debdiff, then throw away backportpackage and handle the changes you need manually. [15:52] And I didn't see a flag to backportpackage that says "give me the opportunity to change something" [15:52] Debdiff? [15:52] http://manpages.ubuntu.com/manpages/xenial/en/man1/debdiff.1.html [15:52] The thing is, I have ~no Ubuntu packaging experience [15:52] Run it against two dsc files. [15:53] backportpackage leaves its stuff around in a temporary directory [15:53] you can go and edit it if you like [15:53] To me, right now, backportpackage is pretty much a black box, with the end result being that the package ends up in the PPA [15:53] and then build the source package and upload it to the PPA manually [15:54] it writes the dpkg-buildpackage command it uses to build the source package to its output, so you can copy and paste that [15:54] OK, so here are some pieces that I think you should learn: 1) how to get from an unpacked debian source tree to debian source package files (dsc, debian.tar.gz, changes). [15:54] 2) how to unpack debian source package files into a directory [15:55] 3) how to build from debian source package files a set of debs locally. [15:55] 4) how to compare changes [15:55] 5) how to upload to a PPA [15:55] Once you've got that you should generally know what questions you need to ask I think. [15:56] rbasak speaks wisdom. [15:56] Quick lookup: 1) dpkg-buildpackage; 2) dpkg-source -x; 3) sbuild (and mk-sbuild); 4) debdiff; 5) dput [15:57] There are details and nuances with all of that and I have made some deliberate mistakes there in the interest of my summary [15:58] But hopefully that's enough to get you started so you know what docs to look up [15:59] After you've got to grips with those, you should see that backporting is really just a case of grabbing a source package and changing it as needed (just debian/changelog for a no-change backport, and more for other changes as needed) and uploading it again. [16:00] pull-lp-source is worth knowing about too. [16:00] FWIW, nacc and I are working on a tool that makes all of this much easier, but I'm not sure I'd recommend newcomers to using it yet, because there are still many rough edges [16:00] +1 [16:01] all of these things have fairly decent man pages, plus https://wiki.ubuntu.com/SimpleSbuild and https://help.launchpad.net/Packaging/PPA [16:03] * juliank really wants lxd sbuild [16:04] juliank: "git ubuntu build" roughly works and does it in lxd. [16:04] I have two options: Fix the autopkgtest backend to actually work, or write a separate lxd backend. I think the latter is easier, I already have a docker backend :) [16:04] rbasak: well, yeah, but it's not sbuild :D [16:05] I don't think we're ever going to match feature parity with sbuild. Like you say, adding a lxd backend to sbuild would be better I think. [16:05] rbasak: and well, most stuff is not in git-ubuntu repos [16:05] juliank: we're working on fixing that :) [16:05] rbasak: In theory, sbuild should be able to use lxd via it's autopkgtest virt-server integration. In practice, it just hangs or fails with weird errors. [16:05] juliank: OOI (not that we're going to implement them), what does sbuild have that you would miss the most with git ubuntu build? [16:06] I'm not sure I'm missing something specific. [16:06] But I'd also like to use sbuild for debian builds and stuff [16:07] and being as close to a build server as possible is a bonus there [16:07] I think LP also uses _some_ sbuild [16:10] LP uses stock sbuild [16:11] only a few modifications these days and they're all wrapped around the standard package; see lp:launchpad-buildd, lpbuildd/binarypackage.py and sbuildrc [16:12] well, and bin/sbuild-package [16:12] the chroot is managed outside of sbuild in launchpad though AFAICT from build logs [16:13] I didn't think sbuild managed its own chroots anyway? [16:13] mk-sbuild isn't in the sbuild package for example [16:13] (although sbuild-update is) [16:14] well, it has backends for chroot-like things [16:14] _normally_ it's used with schroot [16:14] Oh, I see. That sense of "manage" :) [16:14] there are schroot, sudo, and autopkgtest backends [16:14] I guess LP uses the sudo one then [16:15] I also have a docker one, and am thinking about writing a lxd one [16:15] the docker is prototype-y, though [16:15] there's also a sbuild-launchpad-chroot package that is useful === nacc_ is now known as nacc [16:16] I don't want to build in chroots, because they are crazy insecure [16:17] What does it mean when the Build-Depends line contains e.g. "mingw-w64-i686-dev "? I tried looking for the dsc file syntax, but a couple pages I saw didn't say anything about the part of the syntax [16:19] michagogo: these are build profiles, for bootstrapping new architectures [16:19] so you can have a stage1 with the least features compiled in, then a stage2 with more, ... [16:19] in order to resolve cycles [16:19] Oh, for cases of circular dependencies etc.? [16:19] I see. [16:24] Now I'm confused about the version numbers of gcc-mingw-w64 [16:25] They're numbers like 17, 19.3, 20.2 [16:25] Those don't look like software version numbers [16:25] why not? [16:26] have you seen systemd's version? [16:26] I mean, they don't look like they're version numbers for MinGW, which is at 5.0.3 [16:26] right [16:26] Or GCC, which is at 7.x.x (or 6.x.x or 5.x.x or whatever) [16:26] juliank: no, LP uses the schroot backend [16:26] cjwatson: interesting [16:26] Now I'm starting to think I may not actually understand what the gcc-mingw-w64 package is... [16:26] michagogo: The binaries have a different version number. [16:27] michagogo: So, the gcc-mingw-w64 package probably build-depends on gcc-source and compiles gccs from that [16:27] juliank: The main oddity is that we use schroot type=plain and do the setup/teardown ourselves [16:27] and then it generates packages like gcc-mingw-w64 with versions like 7.2.0-20ubuntu1+20.2 [16:28] juliank: But then the actual entry to the chroot is done using schroot (which means we get its ability to reliably kill a session, which sbuild's sudo mode couldn't do) [16:30] Hm... so if it build-depended on, say, gcc-5-source rather than gcc-7-source, it would produce GCC 5 binaries, with the newer MinGW code? [16:30] Dammit, I think this is turning into "Micha doesn't understand the relationship between GCC and mingw-w64" [16:31] The way I would answer that question would be by going to https://tracker.debian.org/mingw-w64, which links to https://anonscm.debian.org/cgit/collab-maint/mingw-w64.git, grabbing that git tree locally, and then looking back through its history to see if the Build-Depends change to gcc-7-source was accompanied by any other changes [16:33] That sort of approach is usually a good strategy for "help, I need to unwind this complicated new build-dependency for a backport, but I have no idea what else I might need to unwind at the same time" [16:33] cjwatson: the Build-Depends on gcc-7-source is in gcc-mingw-w64, not in mingw-w64 [16:33] michagogo: gcc-mingw-w64? Sounds like you're diving in at the very deep end there. [16:34] michagogo: I would step back and consider your approach. I don't know what problem you're solving, but there might be an easier way. [16:34] Yeah, I'm thinking more and more that I'm looking at something much more complex than I hoped [16:35] My starting point is this [16:35] The version of mingw-w64 (or maybe it's g++-mingw-w64? I don't think I understand well enough how the different projects interact) in xenial is very broken [16:36] michagogo: ok, substitute the starting URL accordingly then [16:37] It produces binaries that don't work, Leading to a certain project having instructions in the build guide to change apt sources in a xenial environment to point to the zesty repos and upgrade [16:37] Which, if I'm not mistaken, is a very effective way to hose your environment. [16:38] Zesty is EOL now. [16:38] But you can usually fire up a lxd container and use a newer release to run a build just fine. [16:38] No need to hose the host system. [16:39] The build process for releases just uses a Trusty container to get around that issue, but it's desirable to have a way to build without all that [16:39] Also, if the reason it doesn't work in Xenial is due to a bug, we're quite happy in general to cherry-pick the fix for all Xenial users to benefit. [16:40] (One example being Windows users, who want to use WSL, which doesn't have containers or chroot afaik) [16:40] Can they not use WSL with a different Ubuntu release? [16:51] rbasak: We only provide xenial WSL images. [16:51] You can upgrade the environment, but then you're on your own. [16:52] AFAIK you're not given a choice as to which version to download [16:52] Ah, OK [16:53] And ISTR that do-release-upgrading breaks things [16:56] slangasek: hey, who should I talk to about a systemd fix? I have a debdiff ready (http://paste.ubuntu.com/p/W2w883BFgR/) and would love feedback if its ok to upload or if I should follow a different process (PR or somesuch) [16:59] mvo: i'm told elsewhwere that slangasek is away today and tmrw [17:00] nacc: aha, thank you [17:02] mvo: np, i wonder if xnox is around (although late for him) [17:04] nacc: it's earlier for xnox than for mvo :D [17:04] but I have not seen him [17:05] that said, a lot of people do not respond on IRC today :) [17:06] mvo: I would not do anything with systemd right now. it's stuck in the cryptsetup transition with test failures [17:06] I think xnox wanted to investigate them [17:08] juliank: ok, thank you [17:13] juliank: :) i never know anymore [17:29] I think I’m probably not going to keep pursuing this right now, but: [17:29] That stage1 stuff in the build-depends that we talked about earlier, is that also relevant for PPAs? [17:30] Meaning, if I wanted to upload packages with circular dependencies to a PPA, would that work [17:30] ? [17:30] michagogo: i believe PPAs don't have build-profiles exposed [17:31] michagogo: so you can't do the bootstrap in a PPA, except by hand (e.g., drop the stuff you don't need to get pkg1 built, then build pkg2, then rebuild pkg1 re-adding what you dropped) [17:32] That's correct. It's a feature that might be worth adding in the feuture. [17:32] *future [17:33] cjwatson: what was that? [17:33] the ability to configure a PPA to build with certain build profiles [17:34] um, yeah, I meant the character [17:34] err, dunno, something lag-induced [17:34] cjwatson: did you restart ddeb-retriever or did it finish? [17:35] in any case, we do have bionic-updates now :) [17:44] I didn't touch it except to deploy your change; I think it finished [17:45] Ah I guess it did not get yakkety,viid,zesty back from LP and hence did not regenerate them or something [17:46] I'm always amazed at how easy some things are too fix [17:47] build-profiles in PPAs> That would be SUPER useful for Qt transitions. [17:50] tsimonq2: ooi how do you use build profiles for qt transitions? [17:51] juliank: The base Qt packages have circular dependencies with the doc packages. If we had access to build with specific profiles, we'd go with nodoc for the first run and then from there unset nodoc and rebuild the packages one more time. [17:52] nacc: How's phpunit coming along? Is there anything I can help out with for php-defaults while you're working on that? [17:53] xevious: just working on monolog and then it should be good [17:53] xevious: if you can look to see any of them need retriggers, (e.g., the packag that was tested has already been updated in bionic-proposed or bionic), that would be helpful. Or if any need an update from Debian. [17:53] that's usually my first step [17:54] Yeah I can do that. [17:54] xevious: thanks, just ping me with what you find [17:55] tsimonq2: interesting [18:39] rbasak/juliank/cjwatson: Thanks for your help. I also discussed the issue a bit with people who have a bit more understanding and think I have a slightly better idea of this whole story. I think I'm going to drop the issue for now, since I don't think I have enough time to learn enough about the various topics involved and get into it. On the horizon for Bitcoin Core specifically, we want our build tooling to optionally create and use its [18:39] own toolchain, in order to be independent of Ubuntu (and other distro) packaging-related issues like this. [18:40] Maybe at some point in the future I'll look into it again as a learning opportunity... [18:40] And I mean, in the meantime mingw-w64 is broken for everyone, it's not just us, but... 🤷🏽‍♂️ === caravena_ is now known as caravena [18:48] juliank: did you see LP: #1747033 ? [18:48] Launchpad bug 1747033 in apt (Ubuntu) "transitional package dependency shouldn't be auto-removable" [Undecided,New] https://launchpad.net/bugs/1747033 [18:49] jbicha: Oh, well, the package is in the wrong section [18:49] it needs to be in oldlibs [18:49] juliank: is that the only problem there? === caravena_ is now known as caravena [18:50] jbicha: yeah, if its in oldlibs, gnome-tweak-tool becomes autoremovable, and gnome-tweaks gets the bit gnome-tweak-tool had before [18:50] if so I'll reassign to gnome-tweaks and look for an AA to help [18:51] jbicha: Sorry I was confused last time I looked at it [18:51] and then I forgot about it [18:52] magic! [20:01] infinity, kees, stgraber, slangasek: TB meeting? [21:52] nacc: Caught up with tickets. Got about 30% done writing a script to check for things needing retriggers. [21:53] xevious: nice :) [21:54] I'm getting back to that now. [22:07] Debian #890287, #890288. Fun. [22:07] Debian bug 890287 in src:mbedtls "mbedtls: CVE-2018-0488 - Risk of remote code execution when truncated HMAC is enabled" [Grave,Open] http://bugs.debian.org/890287 [22:07] Debian bug 890288 in src:mbedtls "mbedtls: CVE-2018-0487 - Risk of remote code execution when verifying RSASSA-PSS signatures" [Grave,Open] http://bugs.debian.org/890288 [23:03] xevious: once php-monolog (just uploaded) is published, I can retrigger phpunit's tests and should be able to pick up wherever you are on php-defaults [23:10] nacc: Is this still the best guide for git-ubuntu + workflow? https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow [23:11] nacc: I've been juggling a number of things today. I should have that script shortly. I'll drop it in a snippet or gist or something when it's ready. [23:11] nacc: Can I PM you to confirm some details? [23:12] xevious: ack [23:12] powersj: the manpages of the snap are probably a bit better [23:12] to enable them, LP: #1699526 [23:13] Launchpad bug 1699526 in usd-importer "Extra steps needed to enable manpages in snap" [Low,Triaged] https://launchpad.net/bugs/1699526 [23:13] powersj: (although i believe that i need to revisit that with some upstream changes recently in snapd) [23:15] nacc: thx! [23:16] powersj: np, i think the merge manpage is basically that wiki page still, but it's supposed to be the place to go [23:16] powersj: also use the beta snap [23:18] ah was on edge [23:18] powersj: edge would be fine [23:18] just a bit less stable :) [23:18] edge should be ok (I thikn that's what i am using) [23:18] note that some repos are currentlly ... in flux :) [23:18] because of our importer changes [23:19] powersj: if you hit issues, let me know, i can walk you through how to workaround them [23:19] nacc: ok thanks again [23:19] np [23:38] xevious: retriggering php-monolog now [23:38] Great. [23:39] xevious: i *think* that will also get a bunch of stuff in php-defaults through [23:39] because it's all the phpunit entangled packages that cause those mismatches [23:50] xevious: cacti just got fixed in debian, it *should* sync down once it builds/publishes there [23:50] Great. [23:50] How long does that usually take? [23:50] hopefully it will be done or in progress when i wake up trmw [23:51] *tmrw* [23:51] xevious: since you're still collecting data on php-defaults, i might try and get php-horde-test through, since that will unblock the rest of horde probably [23:51] Ok. I'm about to publish a gist with the script and the current results. [23:52] xevious: thanks [23:57] nacc: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16