[00:07] <WoC> E: Type '[arch=ppc64el]' is not known on line 11 in source list /etc/apt/sources.list
[00:07] <sarnold> does 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:08] <sarnold> WoC: okay, try removing the [arch=ppc64el] bit ..
[00:08] <WoC> sarnold, G4 ?
[00:18] <mwhudson> no https://en.wikipedia.org/wiki/POWER4
[00:18] <mwhudson> Installing Ubuntu 18.04 “Bionic Beaver” For powerpc <- um, installing ubuntu 18.04 on an architecture it's not built for?
[00:20] <sarnold> mwhudson: yeah. probably the whole guide ought to be nuked..
[00:20] <mwhudson> sarnold: seems like it
[00:20] <sarnold> at 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:23] <stokachu> stgraber: 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] <stokachu> i need it to persist at 1458
[00:30] <WoC> Is there a handy dandy guide for how to setup for cross compiling ?
[00:34] <sarnold> hmm. the cross-gcc-dev package looks like it's supposed to help set up the environments. I've never tried it though :/
[00:36] <WoC> ty ty ty sarnold
[00:38] <sarnold> oh maybe that just lets you build the packages that are already in teh archive, like gcc-7-powerpc-linux-gnu
[00:39] <WoC> E: Unable to locate package cross-gcc-dev
[00:41] <sarnold> odd, but probably it was the wrong path to suggest :)
[00:56] <WoC> Found a guide; https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
[01:02] <stgraber> stokachu: bridge.mtu
[01:05] <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:06] <JanC> so cross-gcc-dev in cosmic seems like it would help with what you want
[01:18] <WoC> JanC, wouldnt have the ppa for that ?
[01:18] <WoC> Builds
[01:18] <WoC>  amd64
[01:19] <JanC> like I said, it's in cosmic (Ubuntu 18.10)
[01:19] <WoC> could be why i dont see it
[01:20] <WoC> JanC, is there a simple way to upgrade from 18.04 to 18.10 without wiping the current install ?
[01:20] <sarnold> do-release-upgrade -- maybe do-release-upgrade -d
[01:21] <JanC> or do it in the GUI when you use that
[01:21] <WoC> o-release-upgrade -d
[01:21] <WoC> Checking for a new Ubuntu release
[01:21] <WoC> Upgrades to the development release are only
[01:21] <WoC> available from the latest supported release.
[01:22] <sarnold> then just do-release-upgrade :)
[01:22] <WoC> do-release-upgrade
[01:22] <WoC> Checking for a new Ubuntu release
[01:22] <WoC> No new release found.
[01:23] <WoC> JanC, how do you do it in the gui ?
[01:23] <JanC> you might have to change the setting from LTS-only to all releases
[01:23] <WoC> oh
[01:24] <sarnold> /etc/update-manager/release-upgrades
[01:25] <jbicha> don't use  -d   that will get you Disco 19.04 which is in early alpha
[01:27] <WoC> ty, seems to work w/o -d
[01:27] <WoC> just a bunch of new updates 1st
[01:27] <stokachu> stgraber: thanks
[01:54] <mwhudson> this is a new one: a setup.py that manages to link it's 3.7 extensions to libboost_python27.so
[01:56] <sarnold> 3.7 2.7 who'll notice the difference? :)
[01:57] <mwhudson> mr segfault notices it seems
[01:57] <sarnold> quick call dr watson!
[02:04] <stokachu> stgraber: lxc network set lxdbr0 bridge.mtu 1458 right?
[02:05] <stokachu> ip link list shows lxdbr0-mtu and lxdbr0, is that expected?
[02:07] <mwhudson> coreycb, 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:08] <stgraber> stokachu: 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 up
[02:10] <mwhudson> haha brilliant it now ftbfs on all arches _except_ amd64
[02:11] <stokachu> stgraber: ack thanks, in the end lxdbr0 will have correct mtu set?
[02:11] <stgraber> stokachu: yeah, the bridge should take the mtu of the interface with the lowest one
[02:11] <stokachu> stgraber: 10-4, thanks again
[02:14] <mwhudson>     libdirs = user_libdirs+[os.path.join(sys.prefix,'lib'),'/usr/local/lib', '/usr/lib','/usr/lib/x86_64-linux-gnu']
[02:15] <mwhudson> OH YOU EFFING WAHT
[02:16]  * mwhudson rages
[02:40] <WoC> upgrade to 18.10 good so far ;] I just hope it doesnt infect my system with nouveau
[08:46] <foua> hi! what's the recommended way of creating/building a package which works with both upstart and systemd?
[08:47] <foua> or is the recommended way to side-step the question and build a separate package for each system?
=== lathiat_ is now known as lathiat
[09:12] <tjaalton> foua: man dh_installinit
[09:16] <foua> tjaalton: had a look there --- but the package still ends up with _both_ sysv-rc and init-system-helpers dependencies
[09:17] <tjaalton> foua: so you have d/package.init?
[09:18] <foua> tjaalton: I don't, no -- I have d/{service}.upstart and d/{service}.service
[09:20] <tjaalton> does the upstream install something in etc/init.d?
[09:21] <foua> the run/install-time dependencies of the package is only `Depends: ${misc:Depends}` --- so it shouldn't be
[09:21] <foua> worth mentioning is that I use compat 9
[09:25] <tjaalton> didn't answer the question
[09:31] <foua> tjaalton: not sure I understand what you mean with `upstream` here in that case
[09:31] <tjaalton> upstream sources
[09:32] <tjaalton> actually looks like it's a feature of compat 9
[09:32] <tjaalton> bump it to 10
=== alan_g is now known as alan_g_
[12:36] <coreycb> mwhudson: bandit should be safe to sync. i don't think we even use it tbh.
[12:37] <coreycb> mwhudson: i'll work on it and make sure it's ok to sync
[12:38] <tarzeau> https://popcon.ubuntu.com/ the links of the archs link to dapper... is that 10 years ago?
[12:38] <tarzeau> shouldn't ubuntu either support p.u.c and the package right, or just drop it?
[12:45] <ginggs> dapper dingo
[12:47] <tarzeau> i thought it's disco?
[12:58] <ahasenack> hi, 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] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1795772
[12:58] <ubottu> Launchpad bug 1795772 in samba (Ubuntu Bionic) "rmdir on non-empty samba directory fails silently" [High,In progress]
[13:00] <ahasenack> rbasak: as an sru team member :) ^
[13:20] <rbasak> ahasenack: 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:21] <ahasenack> ok
[13:21] <rbasak> That way it won't show up as green in the pending-sru report in the meantime, which would be bad.
[13:21] <ahasenack> even if verification-needed was also removed?
[13:22] <rbasak> I'm not sure exactly what the report does with both failed and needed present
[13:22] <ahasenack> I just don't want it to be ignored
[13:22] <rbasak> Or needed gone but no failed
[13:22] <ahasenack> i.e., someone sees the upload, glances at the report, it's red because of verification-failed, nothing to do
[13:22] <ahasenack> something like that
[14:03] <smoser> xnox: around ?
[14:03] <smoser> looking for systemd related help at https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1802354
[14:03] <ubottu> Launchpad bug 1802354 in open-iscsi (Ubuntu) "iscsid does not run if there are only initramfs initiated targets" [High,Confirmed]
[14:09] <xnox> smoser, yeah.
[14:10] <xnox> smoser, *host* service => is that client or server side?
[14:12] <smoser> the answer to the question i *think* you're asking is 'server'.
[14:12] <xnox> smoser, tah.
[14:12] <smoser> basically any time we have an iscsi mount we want iscsid to be running.
[14:12] <xnox> true
[14:13] <smoser> if it isn't running, and the iscsi server on remote-system gets restarted
[14:13] <smoser> then our system might fall over
[14:13] <xnox> which on my books means a udev rule with ', SYSTEMD_WANTS=iscsid.service"
[14:13] <xnox> such that such mounts (actually systemd .device autogenerated unit) starts iscsid.service.
[14:13] <smoser> oh. on the disk
[14:14] <smoser> but "wants" ?
[14:14] <smoser> i think this is convoluted by the .scoket
[14:14] <smoser> err.. .socket
[14:14] <smoser> will the wants result in the *service* running? rather than the .socket ?
[14:15] <xnox> i 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 service
[14:16] <xnox> thus the answer to your quextion, is the result is that *both* service and socket are running.
[14:16] <xnox> but
[14:16] <smoser> well, no
[14:16] <xnox> we don't run systemd inside initramfs; and hopefully replug post initramfs does start these things.
[14:17] <xnox> i guess look at mdadm udev rules and systemd units.
[14:17] <smoser> right. thats something to check.
[14:17] <xnox> by default no units are running at all; and the mdmon@ units are started purely from udev rules.
[14:17] <xnox> and because of lack of systemd, initramfs does its own thing.
[14:17] <smoser> ok. wants=iscsid.service, compared to just 'iscsid'. that makes sense.
[14:18] <smoser> but the cold plug may trigger
[14:18] <smoser> which woudl be sufficient.
[14:18] <xnox> yeap
[14:18] <xnox> well. `naked` unit name, results in `.service` appended. but i preffer full unit names everywhere.
[14:18] <smoser> that makes sense.
[14:18] <smoser> ok. i can play with udev rules.
[14:19] <smoser> but then ... this is all much more complicated
[14:19]  * smoser is somewhat frustrated that this change was pushed in to fix a "bug" of a service running that wasn't necessary.
[14:20] <smoser> so i'm not thrilled about more moving parts
[14:21] <smoser> xnox: also.. what about a container? no udev there.
[14:22] <xnox> smoser, explain.
[14:23] <smoser> well, if the only way we run iscsid.service is through udev
[14:23] <smoser> then in that case, where there were non-"open-iscsi.service" created iscsi mounts, we would not get iscsid to run
[14:24] <smoser> but i suspect /sys/class/iscsi_session is not namespaced anyway
[14:24] <smoser> so thats probably a good thing
[14:24] <xnox> smoser, 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] <smoser> right. yes, from the host is what i was suggestiong.
[14:24] <smoser> in the container creationo.
[14:25] <smoser> andyou're right, then the host's iscsid coudl/should be doing it.
[14:25] <coreycb> mwhudson: 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.
=== alan_g is now known as alan_g_
[17:42] <smoser> xnox: still there?
[17:42] <smoser> never mind. sorry for current ping mioght bother you later.
=== 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:
[18:24] <WoC> is there an easy way with apt/dpkg to force a reinstall of two specific packages w/o regarding dependence's ?
[18:40] <xnox> WoC, sudo apt install --reinstall foo bar
[18:40] <xnox> does that not do what you want?
[18:40] <xnox> or if you have specific debs you can allo do
[18:40] <WoC> checking
[18:40] <xnox> $ sudo apt install --reinstall ./foo_1-3_amd64.deb
[18:41] <xnox> note the './' ie. full path
[18:41] <xnox> just "foo_1-3_amd64.deb" will not work
[18:41] <WoC> Nope, the packages are; cacti & cacti-spine
[18:41] <WoC> i can not seem to purge
[18:42] <WoC> broken
[18:42] <xnox> well, 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] <xnox> but yes, apt/dpkg need to be in a consistent state first.
[18:42] <WoC> is there a way to erase them from the list of installed packages ?
[18:42] <xnox> ....
[18:43] <xnox> please use pastebin, to paste what's the output from apt?
[18:43] <WoC> k
[18:43] <xnox> one can like | pastebinit
[18:43] <xnox> `| pastebinit` is very handy
[18:45] <WoC> http://paste.ubuntu.com/p/rwrNjQH9f4/
[18:46] <WoC> this is after do-release-upgrade, btw
[18:46] <WoC> 18.04 -> 18.10
[18:48] <WoC> i want you to know, i really appreciate your help
[22:12] <Faux> Whatever 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:15] <Faux> Oh, luckily that was ages ago and they left.