| RAOF | Do we not get build logs for riscv? | 02:56 |
|---|---|---|
| RAOF | cf: https://launchpad.net/ubuntu/+source/mir/2.4.1-0ubuntu1/+build/21751476 | 02:57 |
| === lucas_ is now known as lucas | ||
| cjwatson | RAOF: You do if the buildd-manager doesn't get "No route to host" at some point during the build. (I'm not entirely sure why, as the build seems to have completed successfully as far as the builder was concerned. Maybe it overloaded the VM host such that it couldn't do networking for a bit or something?) | 07:53 |
| cjwatson | RAOF: https://people.canonical.com/~cjwatson/tmp/mir-21751476.log if that's helpful. I've retried that build again, so let's see | 08:00 |
| === cpaelzer_ is now known as cpaelzer | ||
| === alan_g_ is now known as alan_g | ||
| === cmagina_ is now known as cmagina | ||
| === genii-core is now known as genii | ||
| bittin | Hello, Any SRU/MRU meeting today ? | 14:24 |
| === not_phunyguy is now known as phunyguy | ||
| === mwhudson_ is now known as mwhudson | ||
| mwhudson | doko, mclemenceau: ha my glibc snapshot packages are completely broken | 21:27 |
| mwhudson | dpkg (subprocess): unable to execute old libc6:amd64 package post-removal script (/var/lib/dpkg/info/libc6:amd64.postrm): Permission denied | 21:29 |
| soreau | launchpad ppa, I uploaded package A which installs A.pc but when I try to install dependent package B, it says it can't find A even though pkg-config is installed | 21:55 |
| soreau | how can I solve this? | 21:55 |
| soreau | A is included in B's build depends | 21:55 |
| sarnold | what's the exact error you're working with? I can't tell if you're working an apt erorr, dpkg error, or gcc error.. | 21:56 |
| soreau | sarnold: it's meson error | 21:57 |
| soreau | meson even says it tried pkg-config | 21:57 |
| soreau | so I'm not understanding how it can't find a .pc file installed in /usr/lib/$libdir/pkgconfig | 21:58 |
| sarnold | aha; if you run the same pkg-config command by hand does it work okay? | 21:59 |
| soreau | sarnold: how can I do that? this is a failure in the ppa launchpad builder, it works fine locally | 21:59 |
| sarnold | soreau: ahhhhh | 22:00 |
| sarnold | how are you doing the local builds? I think sbuild is the 'closest' match to the builders on launchpad | 22:00 |
| soreau | dpkg-buildpackage | 22:01 |
| sarnold | ah, that'll use whatever's installed on your computer rather than building a reproducable build environment | 22:02 |
| sarnold | try setting up sbuild locally and see if you can recreate the problem | 22:02 |
| soreau | I'm just using it to generate source package to upload | 22:02 |
| soreau | sarnold: even if I recreate it locally, how does this help me solve it? | 22:02 |
| soreau | I'm more interested in the ways that this can possibly happen.. | 22:04 |
| soreau | A.pc is installed, B's meson build system can't find it with pkg-config | 22:04 |
| soreau | in launchpad ppa builder | 22:05 |
| soreau | and pkg-config is installed | 22:05 |
| sarnold | soreau: you could compare the packages that are installed during the build against the packages that are installed on your system; or you could compare the opensnoop-bpfcc output during the good build against the bad build and see which files might be missing, etc | 22:05 |
| mwhudson | -rw-r--r-- root/root 220376 2021-06-28 02:52 ./lib64/ld-linux-x86-64.so.2 | 22:06 |
| mwhudson | umm | 22:06 |
| sarnold | that's cute.. | 22:08 |
| mwhudson | so my glibc 2.34 snapshot packages _build_ fine but they sure don't _work_ | 22:09 |
| cjwatson | soreau: Reproducing it locally helps you solve it because you can get a shell in an environment corresponding to the build failure, find what command meson is actually running, and poke around starting from there. | 22:42 |
| cjwatson | soreau: Maybe meson is running pkg-config in a weird way, maybe there's some non-default path that needs to be set up, maybe something else, I don't know. Speculating on it is likely to be less productive than trying to set up a reproducer, in my experience. | 22:43 |
| soreau | cjwatson: so you can get a shell to the environment that mimics the launchpad build environment | 22:44 |
| cjwatson | soreau: sbuild is usually close enough for this sort of thing, yes | 22:44 |
| soreau | that would be helpful as eyes to have indeed | 22:44 |
| soreau | so I have no idea how to use this sbuild thing | 22:45 |
| cjwatson | https://wiki.ubuntu.com/SimpleSbuild | 22:45 |
| soreau | thanks | 22:46 |
| cjwatson | There's a moderate amount of setup the first time you use it, then it's pretty low-effort after that | 22:46 |
| soreau | well I expected work when making a ppa, I didn't expect it to work against me | 22:46 |
| cjwatson | I doubt it's specific to Launchpad | 22:49 |
| soreau | cjwatson: this tells you to add a line to fstab to a nonexistent directory /scratch | 22:51 |
| cjwatson | Indeed, your build failure reproduces locally | 22:51 |
| soreau | and doesn't tell you to create it afaict | 22:51 |
| soreau | cjwatson: well can you just tell me what the problem is? | 22:52 |
| cjwatson | So I'm too tired to work out what might be wrong with the wiki page | 22:52 |
| cjwatson | But are you intending to use libgbm in this package? | 22:52 |
| soreau | I mean doesn't /usr/lib/$libdir/pkgconfig/wlroots.pc exist? | 22:52 |
| soreau | and doesn't `pkg-config --modversion wlroots` find it? | 22:52 |
| cjwatson | "pkg-config --modversion wlroots" works - the build log says as much. But "pkg-config --cflags wlroots" fails, saying that gbm isn't present | 22:53 |
| soreau | well darn | 22:54 |
| cjwatson | Perhaps this is a wlroots bug - if it needs gbm then surely it should depend on libgbm-dev | 22:54 |
| cjwatson | Or this package could Build-Depends: libgbm-dev | 22:54 |
| soreau | yea | 22:54 |
| * soreau tries | 22:54 | |
| cjwatson | I don't know which is better in this case | 22:54 |
| cjwatson | I would normally assume that if a pkg-config file requires some other library then it's the job of the package shipping that pkg-config file to handle the Depends | 22:54 |
| cjwatson | But maybe there's some odd special case here | 22:54 |
| cjwatson | Also it's odd for the pkg-config file to be in wlroots rather than in libwlroots-dev, but I don't know this particular library | 22:55 |
| cjwatson | You would normally want to split out the development files so that you don't have to drag in all the development dependencies at runtime | 22:55 |
| cjwatson | So usually you'd have /usr/lib/*/libwlroots.so.10 in a libwlroots10 package, and /usr/include, /usr/lib/*/pkgconfig, and /usr/lib/*/libwlroots.so in libwlroots-dev | 22:56 |
| cjwatson | Then it'd be easy to give libwlroots-dev proper dependencies on the other -dev packages it needs | 22:57 |
| soreau | cjwatson: but dragging in the dev deps doesn't make it run any slower, it just consumes more disk space, right? | 22:57 |
| cjwatson | Any system that builds the source package in a clean chroot with only its build-dependencies installed would have detected this | 22:57 |
| cjwatson | I mean sure | 22:57 |
| soreau | this is for desktop, where if you don't have enough disk space, you have no business running this software | 22:58 |
| cjwatson | But what I'm describing is completely conventional Debian library packaging and there's no reason not to do it | 22:58 |
| cjwatson | And sometimes -dev packages do end up with slightly weird dependencies for one reason or another so they shouldn't be pulled in frivolously on desktop systems | 22:58 |
| soreau | either the computer is working or it isn't, who cares how it works :P | 22:59 |
| cjwatson | Either you take my advice or you don't :) | 22:59 |
| soreau | cjwatson: I understand what you're saying, I'm mostly being facetious | 23:00 |
| soreau | but I am not trying to get this software into upstream, that is a pro packager's job | 23:00 |
| cjwatson | I'm mostly just giving this advice now because it's way easier to fix this sort of thing before names get entrenched | 23:00 |
| cjwatson | But sure, you could also hack around it | 23:01 |
| soreau | names? | 23:01 |
| cjwatson | Package names | 23:01 |
| soreau | well that's not my fault if it happens | 23:01 |
| cjwatson | Since you have them in Build-Depends of other packages in your PPA | 23:01 |
| cjwatson | So it's easier to just get them right to start with | 23:01 |
| soreau | 'right'? | 23:01 |
| soreau | that's subjective | 23:02 |
| cjwatson | No it's not, not here | 23:02 |
| soreau | fair enough | 23:02 |
| cjwatson | There are packaging standards that define right | 23:02 |
| sarnold | and had they been followed, you probably would have had things just work | 23:02 |
| cjwatson | You can absolutely ignore them and do your own thing, but you'll be working against some tools if you do so, so in my experience it's just making a rod for your own back | 23:02 |
| soreau | well I can't do my first ppa 'right' the very first time, I'm not perfect | 23:03 |
| cjwatson | Oh absolutely | 23:03 |
| soreau | I'm not ignoring you either, just not really understanding why packages are split | 23:03 |
| cjwatson | I'm just making recommendations for the easiest path to a fix | 23:03 |
| sarnold | we joke about "the debian handshake" :) | 23:03 |
| soreau | why not just do like it makes sense and make source package == deb package and have none of these -dev packages | 23:04 |
| cjwatson | eh, I dislike that joke TBH, it's too close to gatekeeping for my liking | 23:04 |
| soreau | I mean what is the purpose of splitting things up in the first place | 23:04 |
| cjwatson | Because disk space is not a trivial concern | 23:04 |
| cjwatson | And -dev packages sometimes need to depend on complex things, more than just "some more files in /usr/include and /usr/lib" | 23:04 |
| soreau | but why not just make it binary - either package X is installed, or it's not | 23:05 |
| soreau | but I digress | 23:05 |
| cjwatson | Like I say, disk space is not actually a trivial concern - including all the development library counterparts to every runtime library on your system would bloat it very considerably | 23:06 |
| soreau | I suppose that is true | 23:06 |
| soreau | so you're saying you can make a smaller binary distro with the use of splitting things | 23:07 |
| cjwatson | For any single library it might happen to be trivial, but we have packaging standards so that things interoperate and to try to keep the amount of package-specific stuff to a minimum | 23:07 |
| cjwatson | Massively so | 23:07 |
| soreau | that makes sense at least | 23:07 |
| cjwatson | https://www.debian.org/doc/debian-policy/ch-sharedlibs.html is the relevant chapter-and-verse of standards for this although somewhat dense | 23:09 |
| soreau | cjwatson: now look at happened with wayfire_0.8.0-7 https://launchpadlibrarian.net/547221766/buildlog_ubuntu-focal-amd64.wayfire_0.8.0-7_BUILDING.txt.gz | 23:09 |
| soreau | ERROR: Dependencies must be external dependencies | 23:09 |
| soreau | oh please | 23:09 |
| soreau | I had this problem locally once before IIRC but can't recall what fixed it | 23:10 |
| cjwatson | Package xcb-present was not found in the pkg-config search path. | 23:10 |
| soreau | ah | 23:10 |
| soreau | some of a | 23:10 |
| cjwatson | The actual error is somewhat further up the log | 23:10 |
| cjwatson | So same thing in principle, libwlroots-dev needs to depend on all the -dev packages corresponding to stuff in its Requires.private | 23:10 |
| cjwatson | (in its .pc) | 23:10 |
| cjwatson | cmake is just being super-noisy here. You want to look just below the "pkg-config --cflags wlroots" line | 23:11 |
| soreau | cjwatson: no this is not the problem | 23:11 |
| soreau | cjwatson: the real problem is this: | 23:11 |
| soreau | Run-time dependency wlroots found: NO (tried pkgconfig and cmake) | 23:11 |
| soreau | Looking for a fallback subproject for the dependency wlroots | 23:11 |
| soreau | Executing subproject wlroots | 23:11 |
| cjwatson | Or indeed the first match for "pkg-config error", that's probably a more sensible search term | 23:12 |
| soreau | it tries to build wlroots even though ---- it's already installed with the .pc file | 23:12 |
| cjwatson | soreau: No, that is a consequence. | 23:12 |
| soreau | ok fine let me try something | 23:12 |
| cjwatson | It says "pkg-config error with 'wlroots'", tells you why, and *then* goes on to try random fallback crap | 23:12 |
| cjwatson | Ignore the random fallback crap until you aren't getting the earlier pkg-config errors | 23:12 |
| cjwatson | (This is a general principle of reading build logs in most systems, I find - you want to look for the *first* unexpected error and investigate that. Otherwise you can end up mired in debugging irrelevant things that don't actually really pertain to the problem, they're just the build system getting confused) | 23:15 |
| mwhudson | hmm does anyone know how the glibc packaging works? :) | 23:15 |
| soreau | cjwatson: yes I should know better to look for the first error, I will try the term you suggest | 23:18 |
| cjwatson | So I think I have the right dependencies, but uh my laptop slowed to a crawl once this source package got into the main body of its build so I can't copy and paste them right now ... | 23:23 |
| soreau | cjwatson: So I just made wayfire depend on all the wlroots and wf-config deps and it found both of them and built as I expected | 23:26 |
| soreau | but this has happened with multiple packages now, it wants to do some compiling test so I need to have the dependent package depend on packages that the build dep does... | 23:27 |
| cjwatson | Right, that happens when the build-dep is packaged with incomplete dependencies of its own | 23:28 |
| soreau | ultimately specifying the deps in multiple packages, even though they depend on each other.. | 23:28 |
| soreau | well shit | 23:28 |
| soreau | how do I fix that? | 23:28 |
| soreau | I put all of these packages in the build-dep of the.. build-dep | 23:29 |
| cjwatson | Add depends to the build-dep. In this case wlroots is under your control | 23:29 |
| soreau | I did | 23:29 |
| mwhudson | ah https://sourceware.org/pipermail/libc-alpha/2021-June/127569.html and the rest of that thread | 23:29 |
| cjwatson | You can extend its Depends line | 23:29 |
| soreau | oh depends, not build depends | 23:29 |
| soreau | I figured the build depends would pull stuff in and those packages make their way into the depends | 23:29 |
| cjwatson | Maybe first read up on what Depends and Build-Depends do exactly | 23:29 |
| soreau | or I could just guess and wonder ;) | 23:30 |
| cjwatson | Not in general. Some dependencies can be autodetected - for example packages that provide libraries that show up in DT_NEEDED object references. -dev dependencies aren't normally autodetected like that though | 23:31 |
| cjwatson | I think it might in principle be possible to autodetect them from .pc files, but I've thought about it for all of 30 seconds so there may be some reason not to | 23:32 |
| soreau | cjwatson: where is the recommended docs for deps/build deps etc? | 23:32 |
| cjwatson | https://www.debian.org/doc/debian-policy/ is the canonical reference | 23:33 |
| cjwatson | It's for Debian of course, but at this sort of level the Ubuntu packaging system.is the same | 23:34 |
| soreau | so if I make package A depend on package X and then B is dependent on A however it complains that it wants X's .pc file.. how do you fix this? | 23:38 |
| cjwatson | B isn't correctly dependent on A here though, that's the problem | 23:38 |
| soreau | it isn't? | 23:38 |
| cjwatson | Or A isn't correctly dependent on X, one of the two | 23:38 |
| cjwatson | Maybe be less abstract | 23:38 |
| soreau | I think the latter | 23:38 |
| soreau | and I'm asking if that were the case, how would you fix it properly | 23:39 |
| cjwatson | Can we please be less abstract? | 23:39 |
| cjwatson | In this case, wayfire Build-Depends wlroots; wlroots ships a .pc file that has Requires.private: gbm (etc.); and wlroots does not depend on libgbm-dev | 23:39 |
| cjwatson | (or various other similar -dev packages) | 23:39 |
| soreau | but it does in build-deps | 23:40 |
| cjwatson | Irrelevant | 23:40 |
| soreau | just clarifying | 23:40 |
| cjwatson | The Build-Depends of wlroots are only *directly* considered when building wlroots itself | 23:40 |
| cjwatson | When building something that build-depends on wlroots, only wlroots's Depends are relevant | 23:41 |
| soreau | oh ok.. hm | 23:41 |
| soreau | so how do you know what needs to go in the deps? | 23:41 |
| cjwatson | So I would (a) split wlroots into libwlroots10 and libwlroots-dev as described above (you could get away without this but IMO this would be a correct thing to do) and (b) add libgbm-dev and all the rest to the Depends of libwlroots-dev | 23:41 |
| soreau | but how do you know to add libgbm-dev to the deps without a build log screaming at you? | 23:42 |
| cjwatson | Discovering the necessary dependencies by going through the Requires.private of wlroots's .pc file and finding the packages that ship each of those .pc files | 23:42 |
| cjwatson | wlroots probably already build-depends on most of them, so just make sure that any of the -dev packages that it build-depends on that ship .pc files referenced by wlroots.pc (which isn't *that* long a list, easy enough to go through by hand) are also in libwlroots-dev's Depends | 23:45 |
| cjwatson | If you wanted to test it, bootstrap a clean chroot, install pkg-config and libwlroots-dev, and see whether "pkg-config --cflags wlroots" works | 23:46 |
| cjwatson | (if you don't want to do the libwlroots10/libwlroots-dev split right now, substitute "wlroots" for "libwlroots-dev" in my last few lines) | 23:47 |
| cjwatson | soreau: So I would be inclined to start with something along the lines of https://paste.ubuntu.com/p/MjzgzsWKvr/ - there are certainly things that could be improved there, but it should be a start | 23:58 |
| cjwatson | (test-built, seems to produce something reasonable-looking, I haven't tried building wayfire against it but I would expect this to make things easier at least once you update wayfire's Build-Depends to say libwlroots-dev rather than wlroots) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!