[16:08] juliank, hi, wrt your comment on https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/378890 is https://pastebin.canonical.com/p/W2twwC7HVj/ what you mean? sorry, having trouble unpacking your sentence, not super-familiar with debian policies [16:09] ackk: No, the opposite of that [16:09] ackk: You want Conflicts: bind9, chrony, isc-dhcp-server, maas-cli, maas-common, maas-dhcp, maas-dns, maas-proxy [16:10] rbasak: It should be working again, FWIW. [16:10] ackk: And you want Breaks: maas-rack-controller (<< 1:0.1~), maas-region-api (<< 1:0.1~), maas-region-controller (<< 1:0.1~) [16:11] ackk: So that you tell the package manager to upgrade those 3 packages you have meta packages for, and that the other packages you Conflict with are obsolete and need to be removed [16:11] JackFrost: thank you! [16:12] juliank, oh I see [16:12] juliank, WRT makefile, it's just there for help testing with creating a repo (as is the conf/distribution). is it a problem to have it there? [16:12] It's not a problem, but it's going to be fairly pointless once uploaded [16:12] tumbleweed: p=toil: reverse-depends src:$p; reverse-depends -b src:$p [16:12] b'\n\n500 Internal Server Error\n\n

Internal Server Error

The server encountered an internal error or\nmisconfiguration and was unable to complete\nyour request.

Please contact the server administrator at \n admin@ubuntuwire.com to inform them of the time this error occurred,\n and the actions you performed just before this error.

>More information about this error may be available\nin the server error log.

Apache/2.4.18 (Ubuntu) Server at qa.ubuntuwire.org Port 80

\n' [16:13] juliank, fair enough [16:15] juliank, thanks, updated everything I think [16:22] ackk: I think you also want to make the Replaces unversioned for those items that have turned from Breaks to Conflicts [16:24] ackk: snapd is also available on s390x and armhf, I take it there are no maas snaps built for those? [16:25] juliank, correct. about that, I was wondering if the list should be there for all packages, or just the "maas" one and have "all" for the others? [16:25] doko: I'll poke it [16:26] rbasak: Heh, looks like you or someone poked IS anyway. [16:26] JackFrost: I did, yes, thanks. I'm a bit puzzled as to how it's all put together and who can do what, but thank you for whatever you did, if anything :-) [16:27] ackk: Well [16:27] rbasak: Someone just restarted it too, which is likely a decent thing anyway. I'm not Canonical at all, just know a trick to get it back. :) [16:27] ackk: This way at least, you don't end up with packages that have missing dependencies [16:27] ackk: But it's a bit wasteful [16:27] JackFrost: I'm starting to make sense of it now, thanks :) [16:27] juliank, yeah, I was wondering if there was a best practice for this case [16:28] optimally the snap would be published for armhf and s390x as well, then the package could be architecture: all [16:29] I mean, it could be now, but it would fail to install there [16:29] which isn't super nice [16:29] but also not super terrible I think [16:30] juliank, right, but we don't support those archs at the moment. publishing snaps would mean we'd have to (or at least give the impression we do?) [16:31] Well, they were "supported" before, fsvo of that word [16:31] in the sense that the binaries where architecture independent and could be installed everywhere :) [16:32] The other argument is that probably nobody will have installed it, so keeping it Architecture: all won't break anyone [16:33] The other argument is that if people do have it installed on armhf/s390x, they'll be left without maas after a dist-upgrade, instead of an old maas [16:33] which I think is all reasonable [16:33] but not super optimal [16:34] Probably keeping the Architecture list makes sense [16:34] but you probably do need them for all, so ubuntu-release-upgrader has an easier time [16:34] and offers to remove the maas installation on armhf/s390x (if any) after an install [16:34] s/install$/dist upgrade/ [16:35] ackk: given that MAAS supports s390x, i'm not sure why you wouldn't built it there? [16:35] juliank, ok, sparkiegeek just enabled builds for all archs, so I guess I can switch to all there [16:35] xnox, IDK why they weren't built before [16:35] ackk: however the argument is that normally one will deploy MAAS on an amd64 box, and then deploy onto s390x from an amd64 box [16:35] ackk: needs manually ticking tick boxes [16:35] =) [16:36] yeah [16:36] I'll switch it to all [16:36] Sometimes I feel I should add External-Depends: snap:foo to apt [16:36] so people can depend on snaps [16:36] to some extend :D [16:37] or Snap-Depends: foo [16:37] :D [16:37] juliank, ooh that'd be nice, with channel/tracks please :) [16:37] Snap-Depends: foo/ubuntu-18.04 [16:37] ? [16:37] :D [16:37] juliank, Snap:Depends maas:2.7/stable/ubuntu-18.04 ? :) [16:38] channels confuse me, aargh [16:38] juliank, you're not alone [16:48] juliank, we might still have an issue with i386 though? [16:54] ackk: no, i386 is dead [16:54] juliank, for apt as well? [16:54] it's only there as an extension to amd64 [16:54] juliank, what if you have an i386 install and you ugprade? [16:54] you can't [16:55] packages have been removed [16:55] (on focal) [16:56] ah, good [17:01] juliank, updated dependencies and set arch to "all" fwiw === ben_r_ is now known as ben_r [20:31] juliank, i finally have python-apt building with pybuild+setuptools+ tests passing, do you want me to file a bug somewhere before making a merge request? [21:05] I'm experiencing problems when rebuilding openjdk-lts on Ubuntu: The .so's have missing elf headers where building on debian has the headers. I've now tried to add buster packages to bionic within pbuilder, but it doesn't work YET. I've added binutils and everything gcc/libc related, is there something I am missing? [21:15] I'd like to avoid shelling out to determine the arch I'm running on; is there any file I could read that contains the same value that `dpkg --print-architecture` would return? [21:20] Odd_Bloke: I'm not aware of any other reliable way [21:21] Thanks! [21:37] Odd_Bloke: (OK, I suppose another approach is to be in an Architecture: package and just encode $(DEB_HOST_ARCH) into your own program or an auxiliary file at build time) [21:37] Would also preclude that package being particularly compatible with just about any kind of multiarch [21:38] techalchemy: no, a bug is not needed [21:38] :) [21:39] cjwatson: That sounds more complicated than the 2ms it takes to exec dpkg warrants, so I'll stick with --print-architecture. :p Thanks again! [21:40] :-) [22:54] Odd_Bloke: 'include /usr/share/dpkg/architecture.mk' will set the dpkg-architecture vars for ya [22:54] Ah, yeah, this is a runtime thing not a build time thing. [22:54] ah