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:07 |
sarnold | WoC: okay, try removing the [arch=ppc64el] bit .. | 00:08 |
WoC | sarnold, G4 ? | 00:08 |
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:18 |
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:20 |
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:23 |
WoC | Is there a handy dandy guide for how to setup for cross compiling ? | 00:30 |
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:34 |
WoC | ty ty ty sarnold | 00:36 |
sarnold | oh maybe that just lets you build the packages that are already in teh archive, like gcc-7-powerpc-linux-gnu | 00:38 |
WoC | E: Unable to locate package cross-gcc-dev | 00:39 |
sarnold | odd, but probably it was the wrong path to suggest :) | 00:41 |
WoC | Found a guide; https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/ | 00:56 |
stgraber | stokachu: bridge.mtu | 01: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 |
JanC | so cross-gcc-dev in cosmic seems like it would help with what you want | 01:06 |
WoC | JanC, wouldnt have the ppa for that ? | 01:18 |
WoC | Builds | 01:18 |
WoC |  amd64 | 01:18 |
JanC | like I said, it's in cosmic (Ubuntu 18.10) | 01:19 |
WoC | could be why i dont see it | 01:19 |
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:20 |
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:21 |
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:22 |
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:23 |
sarnold | /etc/update-manager/release-upgrades | 01:24 |
jbicha | don't use -d that will get you Disco 19.04 which is in early alpha | 01:25 |
WoC | ty, seems to work w/o -d | 01:27 |
WoC | just a bunch of new updates 1st | 01:27 |
stokachu | stgraber: thanks | 01:27 |
mwhudson | this is a new one: a setup.py that manages to link it's 3.7 extensions to libboost_python27.so | 01:54 |
sarnold | 3.7 2.7 who'll notice the difference? :) | 01:56 |
mwhudson | mr segfault notices it seems | 01:57 |
sarnold | quick call dr watson! | 01:57 |
stokachu | stgraber: lxc network set lxdbr0 bridge.mtu 1458 right? | 02:04 |
stokachu | ip link list shows lxdbr0-mtu and lxdbr0, is that expected? | 02:05 |
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:07 |
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:08 |
mwhudson | haha brilliant it now ftbfs on all arches _except_ amd64 | 02:10 |
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:11 |
mwhudson | libdirs = user_libdirs+[os.path.join(sys.prefix,'lib'),'/usr/local/lib', '/usr/lib','/usr/lib/x86_64-linux-gnu'] | 02:14 |
mwhudson | OH YOU EFFING WAHT | 02:15 |
* mwhudson rages | 02:16 | |
WoC | upgrade to 18.10 good so far ;] I just hope it doesnt infect my system with nouveau | 02:40 |
foua | hi! what's the recommended way of creating/building a package which works with both upstart and systemd? | 08:46 |
foua | or 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 | ||
tjaalton | foua: man dh_installinit | 09:12 |
foua | tjaalton: had a look there --- but the package still ends up with _both_ sysv-rc and init-system-helpers dependencies | 09:16 |
tjaalton | foua: so you have d/package.init? | 09:17 |
foua | tjaalton: I don't, no -- I have d/{service}.upstart and d/{service}.service | 09:18 |
tjaalton | does the upstream install something in etc/init.d? | 09:20 |
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:21 |
tjaalton | didn't answer the question | 09:25 |
foua | tjaalton: not sure I understand what you mean with `upstream` here in that case | 09:31 |
tjaalton | upstream sources | 09:31 |
tjaalton | actually looks like it's a feature of compat 9 | 09:32 |
tjaalton | bump it to 10 | 09:32 |
=== alan_g is now known as alan_g_ | ||
coreycb | mwhudson: bandit should be safe to sync. i don't think we even use it tbh. | 12:36 |
coreycb | mwhudson: i'll work on it and make sure it's ok to sync | 12:37 |
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:38 |
ginggs | dapper dingo | 12:45 |
tarzeau | i thought it's disco? | 12:47 |
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] | 12:58 |
ahasenack | rbasak: as an sru team member :) ^ | 13:00 |
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:20 |
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:21 |
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 | 13:22 |
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:03 |
xnox | smoser, yeah. | 14:09 |
xnox | smoser, *host* service => is that client or server side? | 14:10 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 | |
smoser | so i'm not thrilled about more moving parts | 14:20 |
smoser | xnox: also.. what about a container? no udev there. | 14:21 |
xnox | smoser, explain. | 14:22 |
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:23 |
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:24 |
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. | 14:25 |
=== alan_g is now known as alan_g_ | ||
smoser | xnox: still there? | 17:42 |
smoser | never 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: | ||
WoC | is there an easy way with apt/dpkg to force a reinstall of two specific packages w/o regarding dependence's ? | 18:24 |
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:40 |
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:41 |
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:42 |
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:43 |
WoC | http://paste.ubuntu.com/p/rwrNjQH9f4/ | 18:45 |
WoC | this is after do-release-upgrade, btw | 18:46 |
WoC | 18.04 -> 18.10 | 18:46 |
WoC | i want you to know, i really appreciate your help | 18:48 |
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:12 |
Faux | Oh, 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!