/srv/irclogs.ubuntu.com/2018/11/09/#ubuntu-devel.txt

WoCE: Type '[arch=ppc64el]' is not known on line 11 in source list /etc/apt/sources.list00:07
sarnolddoes anyone know who "owns" https://help.ubuntu.com/lts/installation-guide/powerpc/index.html  ? it calls power4 "recent".  Isuspect the whole thing is useless at this point..00:07
sarnoldWoC: okay, try removing the [arch=ppc64el] bit ..00:08
WoCsarnold, G4 ?00:08
mwhudsonno https://en.wikipedia.org/wiki/POWER400:18
mwhudsonInstalling Ubuntu 18.04 “Bionic Beaver” For powerpc <- um, installing ubuntu 18.04 on an architecture it's not built for?00:18
sarnoldmwhudson: yeah. probably the whole guide ought to be nuked..00:20
mwhudsonsarnold: seems like it00:20
sarnoldat first I was annoyed by the "powerpc" entry on z/OS line .. but that's the least of the problems on that page, I think :)00:20
stokachustgraber: hey, is there some sort of setting i can apply so that my lxdbr0 doesn't keep resetting it's MTU back to 1500?00:23
stokachui need it to persist at 145800:23
WoCIs there a handy dandy guide for how to setup for cross compiling ?00:30
sarnoldhmm. the cross-gcc-dev package looks like it's supposed to help set up the environments. I've never tried it though :/00:34
WoCty ty ty sarnold00:36
sarnoldoh maybe that just lets you build the packages that are already in teh archive, like gcc-7-powerpc-linux-gnu00:38
WoCE: Unable to locate package cross-gcc-dev00:39
sarnoldodd, but probably it was the wrong path to suggest :)00:41
WoCFound a guide; https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/00:56
stgraberstokachu: bridge.mtu01:02
JanC"""This package provides the rules and scripts for making cross-toolchain packages. It can also be used directly to make cross-toolchains that are not packaged for the archive."""01:05
JanCso cross-gcc-dev in cosmic seems like it would help with what you want01:06
WoCJanC, wouldnt have the ppa for that ?01:18
WoCBuilds01:18
WoC amd6401:18
JanClike I said, it's in cosmic (Ubuntu 18.10)01:19
WoCcould be why i dont see it01:19
WoCJanC, is there a simple way to upgrade from 18.04 to 18.10 without wiping the current install ?01:20
sarnolddo-release-upgrade -- maybe do-release-upgrade -d01:20
JanCor do it in the GUI when you use that01:21
WoCo-release-upgrade -d01:21
WoCChecking for a new Ubuntu release01:21
WoCUpgrades to the development release are only01:21
WoCavailable from the latest supported release.01:21
sarnoldthen just do-release-upgrade :)01:22
WoCdo-release-upgrade01:22
WoCChecking for a new Ubuntu release01:22
WoCNo new release found.01:22
WoCJanC, how do you do it in the gui ?01:23
JanCyou might have to change the setting from LTS-only to all releases01:23
WoCoh01:23
sarnold/etc/update-manager/release-upgrades01:24
jbichadon't use  -d   that will get you Disco 19.04 which is in early alpha01:25
WoCty, seems to work w/o -d01:27
WoCjust a bunch of new updates 1st01:27
stokachustgraber: thanks01:27
mwhudsonthis is a new one: a setup.py that manages to link it's 3.7 extensions to libboost_python27.so01:54
sarnold3.7 2.7 who'll notice the difference? :)01:56
mwhudsonmr segfault notices it seems01:57
sarnoldquick call dr watson!01:57
stokachustgraber: lxc network set lxdbr0 bridge.mtu 1458 right?02:04
stokachuip link list shows lxdbr0-mtu and lxdbr0, is that expected?02:05
mwhudsoncoreycb, jamespage: would anything bad happen if we synced src:bandit from debian?  (also Someone(tm) should fix it so it depends on python3 not the python3X it was built with...)02:07
stgraberstokachu: yep because you can't set the mtu on an empty bridge, so that device is created just to force the bridge mtu to line up02:08
mwhudsonhaha brilliant it now ftbfs on all arches _except_ amd6402:10
stokachustgraber: ack thanks, in the end lxdbr0 will have correct mtu set?02:11
stgraberstokachu: yeah, the bridge should take the mtu of the interface with the lowest one02:11
stokachustgraber: 10-4, thanks again02:11
mwhudson    libdirs = user_libdirs+[os.path.join(sys.prefix,'lib'),'/usr/local/lib', '/usr/lib','/usr/lib/x86_64-linux-gnu']02:14
mwhudsonOH YOU EFFING WAHT02:15
* mwhudson rages02:16
WoCupgrade to 18.10 good so far ;] I just hope it doesnt infect my system with nouveau02:40
fouahi! what's the recommended way of creating/building a package which works with both upstart and systemd?08:46
fouaor is the recommended way to side-step the question and build a separate package for each system?08:47
=== lathiat_ is now known as lathiat
tjaaltonfoua: man dh_installinit09:12
fouatjaalton: had a look there --- but the package still ends up with _both_ sysv-rc and init-system-helpers dependencies09:16
tjaaltonfoua: so you have d/package.init?09:17
fouatjaalton: I don't, no -- I have d/{service}.upstart and d/{service}.service09:18
tjaaltondoes the upstream install something in etc/init.d?09:20
fouathe run/install-time dependencies of the package is only `Depends: ${misc:Depends}` --- so it shouldn't be09:21
fouaworth mentioning is that I use compat 909:21
tjaaltondidn't answer the question09:25
fouatjaalton: not sure I understand what you mean with `upstream` here in that case09:31
tjaaltonupstream sources09:31
tjaaltonactually looks like it's a feature of compat 909:32
tjaaltonbump it to 1009:32
=== alan_g is now known as alan_g_
coreycbmwhudson: bandit should be safe to sync. i don't think we even use it tbh.12:36
coreycbmwhudson: i'll work on it and make sure it's ok to sync12:37
tarzeauhttps://popcon.ubuntu.com/ the links of the archs link to dapper... is that 10 years ago?12:38
tarzeaushouldn't ubuntu either support p.u.c and the package right, or just drop it?12:38
ginggsdapper dingo12:45
tarzeaui thought it's disco?12:47
ahasenackhi, this sru has a verification-failed tag. I fixed the problem and uploaded a new package just now, should I just remove the verification-failed tag? What about the verification-needed one?12:58
ahasenackhttps://bugs.launchpad.net/ubuntu/+source/samba/+bug/179577212:58
ubottuLaunchpad bug 1795772 in samba (Ubuntu Bionic) "rmdir on non-empty samba directory fails silently" [High,In progress]12:58
ahasenackrbasak: as an sru team member :) ^13:00
rbasakahasenack: leave the failed tag there please. When the replacement is accepted by the SRU team, the tags will get reset correctly by the script.13:20
ahasenackok13:21
rbasakThat way it won't show up as green in the pending-sru report in the meantime, which would be bad.13:21
ahasenackeven if verification-needed was also removed?13:21
rbasakI'm not sure exactly what the report does with both failed and needed present13:22
ahasenackI just don't want it to be ignored13:22
rbasakOr needed gone but no failed13:22
ahasenacki.e., someone sees the upload, glances at the report, it's red because of verification-failed, nothing to do13:22
ahasenacksomething like that13:22
smoserxnox: around ?14:03
smoserlooking for systemd related help at https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/180235414:03
ubottuLaunchpad bug 1802354 in open-iscsi (Ubuntu) "iscsid does not run if there are only initramfs initiated targets" [High,Confirmed]14:03
xnoxsmoser, yeah.14:09
xnoxsmoser, *host* service => is that client or server side?14:10
smoserthe answer to the question i *think* you're asking is 'server'.14:12
xnoxsmoser, tah.14:12
smoserbasically any time we have an iscsi mount we want iscsid to be running.14:12
xnoxtrue14:12
smoserif it isn't running, and the iscsi server on remote-system gets restarted14:13
smoserthen our system might fall over14:13
xnoxwhich on my books means a udev rule with ', SYSTEMD_WANTS=iscsid.service"14:13
xnoxsuch that such mounts (actually systemd .device autogenerated unit) starts iscsid.service.14:13
smoseroh. on the disk14:13
smoserbut "wants" ?14:14
smoseri think this is convoluted by the .scoket14:14
smosererr.. .socket14:14
smoserwill the wants result in the *service* running? rather than the .socket ?14:14
xnoxi hope that iscsid.service; has After=iscsid.socket Wants=iscsid.socket => such that starting iscsid.service, actually starts socket and the service, with socket passed to the service14:15
xnoxthus the answer to your quextion, is the result is that *both* service and socket are running.14:16
xnoxbut14:16
smoserwell, no14:16
xnoxwe don't run systemd inside initramfs; and hopefully replug post initramfs does start these things.14:16
xnoxi guess look at mdadm udev rules and systemd units.14:17
smoserright. thats something to check.14:17
xnoxby default no units are running at all; and the mdmon@ units are started purely from udev rules.14:17
xnoxand because of lack of systemd, initramfs does its own thing.14:17
smoserok. wants=iscsid.service, compared to just 'iscsid'. that makes sense.14:17
smoserbut the cold plug may trigger14:18
smoserwhich woudl be sufficient.14:18
xnoxyeap14:18
xnoxwell. `naked` unit name, results in `.service` appended. but i preffer full unit names everywhere.14:18
smoserthat makes sense.14:18
smoserok. i can play with udev rules.14:18
smoserbut then ... this is all much more complicated14:19
* smoser is somewhat frustrated that this change was pushed in to fix a "bug" of a service running that wasn't necessary.14:19
smoserso i'm not thrilled about more moving parts14:20
smoserxnox: also.. what about a container? no udev there.14:21
xnoxsmoser, explain.14:22
smoserwell, if the only way we run iscsid.service is through udev14:23
smoserthen in that case, where there were non-"open-iscsi.service" created iscsi mounts, we would not get iscsid to run14:23
smoserbut i suspect /sys/class/iscsi_session is not namespaced anyway14:24
smoserso thats probably a good thing14:24
xnoxsmoser, and how would those mounts appear? from initramfs -> but there isn't one. If they came from the host? then the host should be running iscsid, not the container.14:24
smoserright. yes, from the host is what i was suggestiong.14:24
smoserin the container creationo.14:24
smoserandyou're right, then the host's iscsid coudl/should be doing it.14:25
coreycbmwhudson: i've synced bandit and requests. bandit needs python-hacking to build successfully but it's ftbfs. I think fixed by the requests sync - rebuilding atm.14:25
=== alan_g is now known as alan_g_
smoserxnox: still there?17:42
smosernever mind. sorry for current ping mioght bother you later.17:42
=== infinity changed the topic of #ubuntu-devel to: Archive: Open | 18.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Cosmic | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
WoCis there an easy way with apt/dpkg to force a reinstall of two specific packages w/o regarding dependence's ?18:24
xnoxWoC, sudo apt install --reinstall foo bar18:40
xnoxdoes that not do what you want?18:40
xnoxor if you have specific debs you can allo do18:40
WoCchecking18:40
xnox$ sudo apt install --reinstall ./foo_1-3_amd64.deb18:40
xnoxnote the './' ie. full path18:41
xnoxjust "foo_1-3_amd64.deb" will not work18:41
WoCNope, the packages are; cacti & cacti-spine18:41
WoCi can not seem to purge18:41
WoCbroken18:42
xnoxwell, this is not a support channel, and without seeing the output of your system, it's hard to blindly guess and recommend things.18:42
xnoxbut yes, apt/dpkg need to be in a consistent state first.18:42
WoCis there a way to erase them from the list of installed packages ?18:42
xnox....18:42
xnoxplease use pastebin, to paste what's the output from apt?18:43
WoCk18:43
xnoxone can like | pastebinit18:43
xnox`| pastebinit` is very handy18:43
WoChttp://paste.ubuntu.com/p/rwrNjQH9f4/18:45
WoCthis is after do-release-upgrade, btw18:46
WoC18.04 -> 18.1018:46
WoCi want you to know, i really appreciate your help18:48
FauxWhatever you do, don't go put "exit 0" at the top of /var/lib/dpkg/info/cacti*.prerm. That wouldn't be an approved solution at all.22:12
FauxOh, luckily that was ages ago and they left.22:15

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