/srv/irclogs.ubuntu.com/2020/02/11/#ubuntu-devel.txt

ackkjuliank, 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 policies16:08
juliankackk: No, the opposite of that16:09
juliankackk: You want Conflicts: bind9, chrony, isc-dhcp-server, maas-cli, maas-common, maas-dhcp, maas-dns, maas-proxy16:09
JackFrostrbasak: It should be working again, FWIW.16:10
juliankackk: And you want Breaks: maas-rack-controller (<< 1:0.1~), maas-region-api (<< 1:0.1~), maas-region-controller (<< 1:0.1~)16:10
juliankackk: 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 removed16:11
rbasakJackFrost: thank you!16:11
ackkjuliank, oh I see16:12
ackkjuliank, 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
juliankIt's not a problem, but it's going to be fairly pointless once uploaded16:12
dokotumbleweed:  p=toil: reverse-depends src:$p; reverse-depends -b src:$p16:12
dokob'<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n<html><head>\n<title>500 Internal Server Error</title>\n</head><body>\n<h1>Internal Server Error</h1>\n<p>The server encountered an internal error or\nmisconfiguration and was unable to complete\nyour request.</p>\n<p>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.</p>\n<p16:12
doko>More information about this error may be available\nin the server error log.</p>\n<hr>\n<address>Apache/2.4.18 (Ubuntu) Server at qa.ubuntuwire.org Port 80</address>\n</body></html>'16:12
ackkjuliank, fair enough16:13
ackkjuliank, thanks, updated everything I think16:15
juliankackk: I think you also want to make the Replaces unversioned for those items that have turned from Breaks to Conflicts16:22
juliankackk: snapd is also available on s390x and armhf, I take it there are no maas snaps built for those?16:24
ackkjuliank, 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
tumbleweeddoko: I'll poke it16:25
JackFrostrbasak: Heh, looks like you or someone poked IS anyway.16:26
rbasakJackFrost: 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:26
juliankackk: Well16:27
JackFrostrbasak: 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
juliankackk: This way at least, you don't end up with packages that have missing dependencies16:27
juliankackk: But it's a bit wasteful16:27
rbasakJackFrost: I'm starting to make sense of it now, thanks :)16:27
ackkjuliank, yeah, I was wondering if there was a best practice for this case16:27
juliankoptimally the snap would be published for armhf and s390x as well, then the package could be architecture: all16:28
juliankI mean, it could be now, but it would fail to install there16:29
juliankwhich isn't super nice16:29
juliankbut also not super terrible I think16:29
ackkjuliank, 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:30
juliankWell, they were "supported" before, fsvo of that word16:31
juliankin the sense that the binaries where architecture independent and could be installed everywhere :)16:31
juliankThe other argument is that probably nobody will have installed it, so keeping it Architecture: all won't break anyone16:32
juliankThe 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 maas16:33
juliankwhich I think is all reasonable16:33
juliankbut not super optimal16:33
juliankProbably keeping the Architecture list makes sense16:34
juliankbut you probably do need them for all, so ubuntu-release-upgrader has an easier time16:34
juliankand offers to remove the maas installation on armhf/s390x (if any) after an install16:34
julianks/install$/dist upgrade/16:34
xnoxackk:  given that MAAS supports s390x, i'm not sure why you wouldn't built it there?16:35
ackkjuliank, ok, sparkiegeek just enabled builds for all archs, so I guess I can switch to all there16:35
ackkxnox, IDK why they weren't built before16:35
xnoxackk:  however the argument is that normally one will deploy MAAS on an amd64 box, and then deploy onto s390x from an amd64 box16:35
xnoxackk:  needs manually ticking tick boxes16:35
xnox=)16:35
ackkyeah16:36
ackkI'll switch it to all16:36
juliankSometimes I feel I should add External-Depends: snap:foo to apt16:36
juliankso people can depend on snaps16:36
juliankto some extend :D16:36
juliankor Snap-Depends: foo16:37
juliank:D16:37
ackkjuliank, ooh that'd be nice, with channel/tracks please :)16:37
juliankSnap-Depends: foo/ubuntu-18.0416:37
juliank?16:37
juliank:D16:37
ackkjuliank, Snap:Depends maas:2.7/stable/ubuntu-18.04 ? :)16:37
juliankchannels confuse me, aargh16:38
ackkjuliank, you're not alone16:38
ackkjuliank, we might still have an issue with i386 though?16:48
juliankackk: no, i386 is dead16:54
ackkjuliank, for apt as well?16:54
juliankit's only there as an extension to amd6416:54
ackkjuliank, what if you have an i386 install and you ugprade?16:54
juliankyou can't16:54
juliankpackages have been removed16:55
juliank(on focal)16:55
ackkah, good16:56
ackkjuliank, updated dependencies and set arch to "all" fwiw17:01
=== ben_r_ is now known as ben_r
techalchemyjuliank, 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?20:31
DarkchaosI'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:05
Odd_BlokeI'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:15
cjwatsonOdd_Bloke: I'm not aware of any other reliable way21:20
Odd_BlokeThanks!21:21
cjwatsonOdd_Bloke: (OK, I suppose another approach is to be in an Architecture: <not "all"> package and just encode $(DEB_HOST_ARCH) into your own program or an auxiliary file at build time)21:37
cjwatsonWould also preclude that package being particularly compatible with just about any kind of multiarch21:37
julianktechalchemy: no, a bug is not needed21:38
juliank:)21:38
Odd_Blokecjwatson: That sounds more complicated than the 2ms it takes to exec dpkg warrants, so I'll stick with --print-architecture. :p  Thanks again!21:39
cjwatson:-)21:40
dannfOdd_Bloke: 'include /usr/share/dpkg/architecture.mk' will set the dpkg-architecture vars for ya22:54
Odd_BlokeAh, yeah, this is a runtime thing not a build time thing.22:54
dannfah22:54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!