[00:38] <WACOMalt> ok I know this is a long shot, but anyone in here using zpanel as a backend on ubuntu-derver for http?
[00:41] <WACOMalt> I seem to have messed up my vhosts by doing a documentroot overide while trying to set up ssl
[01:32] <WACOMalt> Hello everyone. Can anyone help me track down a long existing issue on my ubuntu server 14.04 machine regarding apt-get ? basically anytime I get it I get errors about unresolved locales package conflicts.
[01:33] <WACOMalt> https://hastebin.com/kodusumoyo.vbs
[01:34] <WACOMalt> is the typical output I see when trying to install anything at all
[01:35] <WACOMalt> if I do apt-get -f install I get https://hastebin.com/aduvisevab.sql
[01:58] <qman__> WACOMalt: you appear to have unofficial sources in your apt, causing a libc version conflict
[01:59] <WACOMalt> where can I check for these?
[01:59] <WACOMalt> @ qman__
[02:00] <qman__> WACOMalt: /etc/apt/sources.list and /etc/apt/sources.list.d/*
[02:00] <WACOMalt> ok I'll post the contents of those in just a moment. thanks for the pointer
[02:00] <qman__> if you have installed software or upgraded while having these sources added, it's likely your system is in a very broken state that's going to be difficult or impossible to resolve
[02:01] <WACOMalt> : [
[02:01] <qman__> you can also get more information about where it's picking up these version with apt-cache policy
[02:01] <WACOMalt> ok here's sources.list https://hastebin.com/polubinace.coffeescript
[02:01] <qman__> e.g. apt-cache policy libc6-bin
[02:03] <WACOMalt> libc-bin reports this: https://hastebin.com/oyakukidag.rb qman__
[02:04] <WACOMalt> and here is my sources.list.d folder contents: https://hastebin.com/anifapolip.css
[02:04] <WACOMalt> looking in each of those, all appear to be for trusty
[02:04] <WACOMalt> btsync being the only one that doesnt indicate that in the filename
[02:06] <qman__> do   apt-cache policy libc6
[02:07] <qman__> and for locales
[02:09] <WACOMalt> https://hastebin.com/icotovafig.rb
[02:10] <WACOMalt> to my eyes those appear to all be trying to come from official repos
[02:10] <qman__> all but that first libc6
[02:11] <WACOMalt> can I tell it to just reinstall those packages?
[02:11] <qman__> you have a version that doesn't have a source, probably means you no longer have the source it came from
[02:11] <qman__> 2.2408
[02:11] <qman__> 2.24-8
[02:11] <qman__> which is a pretty serious problem, you can try to force install the repo verison of libc6 but it's one of the most core packages in the system
[02:12] <qman__> so anything that depends on it which you've installed could break
[02:12] <WACOMalt> is there any way to find out what source that came from, and re-add that source?
[02:14] <qman__> the problem is that you never should have had that source to begin with
[02:14] <WACOMalt> so, in theory, when that go intsalled, whatever was gonna break should have already been broken, right?
[02:14] <qman__> you can check /var/log/dpkg.log and /var/log/apt/history.log, but I don't know how much help those will be
[02:16] <tarpman> 2.24-8 is a debian version - looks like you must have added a debian unstable repository at some point?
[02:17] <tarpman> recently, because unstable only has 2.24-9 even today
[02:17] <WACOMalt> its possible but I have no idea why :/
[02:17] <tarpman> if you added a repository and then removed it, you must know why you did it
[02:18] <WACOMalt> the only thing I could imagine is if something like znc or btsync required some weird version to compile maybe
[02:18] <WACOMalt> but I honestly have no memory of this
[02:18] <WACOMalt> checking logs
[02:19] <tarpman> my suggestion is - apt-get install 'libc6=2.19-0ubuntu6.9'
[02:19] <tarpman> to force it to downgrade to exactly the repository version
[02:19] <qman__> that may or may not be resolvable and will probably require you to remove packages that depended on it
[02:19] <tarpman> yeah
[02:19] <WACOMalt> is there any way to guarantee if I run this I can return to the current working (albeit not ideal) system?
[02:19] <qman__> but is really the only way to fix it, if it's possible at all
[02:20] <tarpman> but it's my only suggestion short of fully reinstalling your system
[02:20] <qman__> no
[02:20] <tarpman> you have backups - right?
[02:20] <tarpman> if not, now would be a good time to make one
[02:20] <qman__> there's no undo feature here
[02:20] <qman__> so yes, backup and restore is the only way
[02:21] <WACOMalt> :E
[02:22] <WACOMalt> welp, at least I'm only risking my own data XD
[02:22] <WACOMalt> here goes something
[02:22] <WACOMalt> aaand the ssh window appears to have stalled
[02:22] <WACOMalt> :E
[02:23] <WACOMalt> E: Version '2.19-0ubuntu6.9' for 'libc6' was not found
[02:24] <qman__>   2.19-0ubuntu6.11
[02:24] <qman__> is the one your apt says it can get
[02:24] <qman__> so try that
[02:25] <WACOMalt> https://hastebin.com/katuvazeri.vbs
[02:26] <qman__> yep, your system state is a mess
[02:26] <qman__> also known as frankendebian
[02:27] <WACOMalt> v_v
[02:27] <qman__> so, you can try to find which versions of those packages it's complaining about should be installed (if any) via apt-cache policy and installing/removing as necessary in the same line, or give up and reinstall
[02:28] <qman__> but those packages will have other codependencies, and those will have codependencies, and so on for many levels
[02:28] <tarpman> those should all be from the same source - 2.19-0ubuntu6.11 ought to work for all of them
[02:28] <tarpman> in theory....
[02:28] <WACOMalt> so... if I re-add that debian repo I apparently had
[02:29] <WACOMalt> can I re-install those from that, then remove them cleanly?
[02:29] <qman__> if you did that, you would still have a mess
[02:29] <tarpman> no, that will only make things worse
[02:29] <WACOMalt> ok
[02:31] <qman__> your next attempt from here would be doing apt-cache policy from each of those packages it complains for, finding which versions they are, and then doing: apt-get install 'libc6=2.19-0ubuntu6.11' 'libc6-dev=2.19-0ubuntu6.11' 'libc6-i386=2.19-0ubuntu6.11' 'libc6-dbg=2.19-0ubuntu6.11'
[02:31] <qman__> assuming that's the version for them
[02:31] <qman__> rinse and repeat until resolved or unresolvable
[02:31] <tarpman> libc-dev-bin in there too, I think
[02:32] <WACOMalt> note to self. Not unlike deleting system32 on my windows background... do NOT eff with system files of linux
[02:32] <qman__> the key mistake here was adding a debian repository to ubuntu
[02:32] <qman__> never do this, and never do the reverse
[02:33] <qman__> or with mint, or any other distribution other than the one you're using
[02:34] <WACOMalt> dangit all the logs are .gz files aside from the current, 0 byte, one
[02:34] <tarpman> 'less' is usually happy to read the .gz's directly
[02:36] <WACOMalt> nope no dice
[02:37] <WACOMalt> bunch of jibberish
[02:37] <tarpman> pastebin
[02:39] <WACOMalt> https://hastebin.com/seperevago.pl
[02:39] <qman__> if you have zcat, you can use that
[02:39] <qman__> zcat /var/log/log.gz | less
[02:43] <WACOMalt> qman__: https://hastebin.com/raw/bexefetibi
[02:44] <WACOMalt> there's like 20 of these logs... so I'm not sure which would have the offending stuff
[02:46] <WACOMalt> Is there a good place to ask for some direct support (aka pair support w/ direct shell access)
[02:46] <WACOMalt> *paid
[02:47] <tarpman> https://www.canonical.com/services/contact-us ?
[02:49] <sarnold> to be honest I'm not sure if the ubuntu advantage folks would tackle this one or not
[02:50] <sarnold> The Answer for "I've installed packages from half-dozen non-ubuntu sources" is probably going to be "here's an install iso"
[02:50] <qman__> yeah, when I encounter that situation, I don't fix it, I start over
[02:50] <qman__> install a new system, set up software, migrate data
[02:51] <tarpman> ++
[02:51] <qman__> it's easier and guarantees results
[02:51] <WACOMalt> well, that is an acceptable solution I would pay for :P
[02:52] <WACOMalt> I dont have the local storage or bandwidth to handle that process
[06:19] <lordievader> Good morning.
 my bios only gives me two options for primary graphics adapter pci express and pci,  while it will use a card in my x4 slot if one isn't present in the x16,  It seems to default to use the x16 slot if there are cards present in both slots. Is there any way I can force ubuntu server to use the card in the x4 as primary?
[11:13] <TafThorne> WACOMalt: view (as in read only vi (which is really vim)) is happy to read compressed text files.
[11:15] <TafThorne> I'd also have suggested you see what `aptitude` suggests as ways to unstick things.  Ripping out a couple of packaged once your sources are sorted can sometimes get things back to a stable (enhough) state.
[13:00] <ronator> On Ubuntu 16, should I use ntpd or systemd-timesyncd? Can the latter also smoothly add drift to system time or would it act like ntpdate setting the time promptly.
[13:01] <andol> ronator: If it's an always-on server I would go with regular ntpd.
[13:03] <ronator> andol: yes, they are; thx
[13:09] <lordievader> Seems like they do quite the same things. Though timesync is hooked into networkd, not sure if that is a dependency. https://wiki.archlinux.org/index.php/systemd-timesyncd
[14:25] <nacc> rbasak: fyi i think the snap is working now
[14:27] <rbasak> \o/ thanks!
[14:32] <nacc> rbasak: np
[14:32] <nacc> rbasak: i had another question for you, though re: LP: #1322264
[14:32] <nacc> i agree 100% with your assessment
[14:33] <nacc> but for relatively obvious bugfixes from upstream, for relatively complicated software configurations, how are we expecting an SRU to work?
[14:33] <nacc> or do we just acknowledge we will ship buggy software for 5 years?
[14:33] <nacc> (or encourage folks to upgrade instead)
[14:34] <rbasak> nacc: I think a best effort to get as close as possible to address the rationale of the SRU policy would be fine.
[14:34] <rbasak> But a lack of answer suggests to me that nobody is going to bother to help if there does turn out to be a regression.
[14:35] <nacc> rbasak: ack that makes sense
[14:35] <rbasak> And I think one problem of the current SRU policy is that the SRU driver is incentivized to focus just on the bug being fixed, rather than the bigger picture of not regression others' use cases.
[14:35] <rbasak> *not regressing
[14:35] <nacc> I just provided an additional comment and hopefully that one user with a detailed report can help
[14:35] <nacc> yep, agreed
[14:36] <rbasak> I have no idea in this case for example whether this bug affects 0.01% or 100% of munin users.
[14:36] <nacc> it's an error path handler, afaict
[14:36] <nacc> but yeah
[14:37] <rbasak> If 0.01%, then my "nobody is going to bother to help if there does turn out to be a regression" concern (due to lack of response) justifies a reject, IMHO.
[14:37] <rbasak> So to not reject, if those things are addressed in the bug, then I think it would be fine to reconsider.
[14:38] <nacc> yeah
[14:38] <nacc> I'm just trying to think of how to explain that rationally to a drive-by contributor, whose response will be "it's been fixed upstream for 3 years"
[14:38] <nacc> (I'd expect)
[14:39] <rbasak> Feel free to copy and paste this discussion :)
[14:39] <nacc> yep
[14:39] <rbasak> and https://wiki.ubuntu.com/StableReleaseUpdates#Why
[14:39] <nacc> ah that's a good reference!
[15:33] <nacc> rbasak: oh! i remember i added a hidden flag for the devel pointers
[15:33] <nacc> rbasak: so for tomcat, you can run `usd import --fixup-devel tomcat7`
[15:34] <nacc> and it will just correctly merge them up so they at least are correct for now (iirc)
[15:38] <rbasak> Nice!
[15:38] <nacc> rbasak: sorry, i had forgotten about that option, it was specifically for cases like this :)
[15:38] <nacc> since we don't update -devel for non-updated branches by default
[17:08] <powersj> rbasak: Looking at LP: #1681736, appears to be a few older bugs with similar issues around mysql-common not installed and failing to create symlinks. Any thoughts?
[17:09] <rbasak> powersj: we do get reports like that. I'm not sure it's a bug though.
[17:09] <rbasak> mysql-common ships /usr/share/mysql-common/configure-symlinks
[17:09] <rbasak> And mysql-server-5.7 depends on a recent enough version of it.
[17:09] <rbasak> I suspect outside-of-Ubuntu packages.
[17:10] <powersj> ahhhh
[17:10] <rbasak> mysql-common 10.0.15+maria-1~trusty [origin: unknown]
[17:10] <rbasak> There we are
[17:10] <rbasak> From Dependencies.txt
[17:11] <powersj> ah! thank you
[17:11] <powersj> rbasak: want to comment on it?
[17:11] <rbasak> Sure
[17:13] <rbasak> Done
[17:13] <powersj> rbasak: is apt-ordering listing the status of the apt command in terms of what it will install during the current operation, with status? and dependencies listing everything that is required to complete the install, including what may already be installed?
[17:13] <powersj> I ask because I looked at apt-ordering, not dependencies
[17:14] <rbasak> powersj: AptOrdering.txt looks like it's telling you what order apt decided to get dpkg to install packages in.
[17:15] <rbasak> Dependencies.txt tells you what versions of what were installed at the time of the error I think.
[19:36] <Erix> hi
[19:36] <Erix> i can not find nor install a2ensite for apache2 on ubuntu server 16.10
[19:37] <nacc> Erix: it's in apache2 package in /usr/sbin
[19:39] <Erix> nacc: thanks.
[19:40] <Erix> nacc, it is not there
[19:40] <Erix> and locate cannot find it
[19:40] <Erix> I installed apache2 within nextcloud snap package
[19:40] <nacc> um
[19:40] <nacc> snaps are different :)
[19:40] <nacc> and more than likely, you'd need to ask the snap owner
[19:41] <Erix> ok. thanks again
[19:41] <nacc> but they are under no obligation to provide a2ensite
[19:41] <nacc> and the a2ensite they do provide would only be visible in the snap
[19:41] <nacc> unelss they expose it as a distinct command
[19:41] <Erix> so is there another way to activate a virtualhost config file without it?
[19:42] <sarnold> try something like snapname.a2ensite
[19:42] <nacc> Erix: well, you certainly don't need snaps for virtualhosts
[19:42] <nacc> Erix: but the snap would need to expose it's internal a2ensite, i think
[19:42] <sarnold> iirc snaps force all commands to have that name.name thing, except for the one command named the same as the snap.
[19:42] <nacc> what sarnold said
[19:42] <nacc> *if* they expose the command at all
[19:42] <sarnold> right
[19:43] <nacc> Erix: you might ask kyrofa in #snappy
[19:43] <nacc> i believe kyrofa packages that snap
[19:43] <nacc> https://github.com/nextcloud/nextcloud-snap
[19:44] <Erix> thanks.
[19:44] <Erix> lots new info for me
[19:44] <nacc> given that bin/apachectl is excluded, i'm not sure if a2ensite is in the snap
[19:44] <nacc> not 100%, kyrofa is probably the best reference
[20:10] <DammitJim> is there a channel for continuous integration?
[20:11] <DammitJim> I want to find out if stuff like that can handle xml file dependencies for apps
[20:32] <nacc> !alis | DammitJim
[20:33] <nacc> DammitJim: do you mean CI in general?
[20:34] <DammitJim> like I want to know if a CI system should be deploying an xml file
[20:35] <teward> hm, I think the default fail2ban regexes don't work proper...
[20:35] <DammitJim> lol
[20:36] <nacc> DammitJim: like ... any CI system? and what do you mean deploy?
[20:42] <DammitJim> like bamboo
[20:46] <teward> i was going to say "Assume we don't know what you're talking about when you say "deploy"" but he left.
[20:46] <teward> and fail2ban is still evil
[20:47]  * teward had to write his own regex to match dovecot and postfix auth fails
[20:47] <nacc> teward: :) yeah, i dont' know what bamboo is...
[22:53] <drab> anybody around using debmirror? I just set it up, process was interrupted 80% of the way, I just restarted it and it's redownloading everything...
[22:53] <sarnold> ewwwwwww
[22:54] <drab> isn't it supposed to pick up from where it left rsync style? the repo is already 79GB
[22:54] <drab> so definitely something got downloaded...
[22:54] <sarnold> I'd expect the lists to be downloaed again from scratch
[22:54] <sarnold> but I'd seriously hope everything else would pick up where it left off
[22:54] <drab> yeah, sure, I expected the same
[22:54] <drab> but it's redownloading all the pkgs
[22:54] <sarnold> feels worth a bug report
[22:55] <sarnold> maybe nothing will happen but it'll feel good to file it all the same ;)
[22:56] <drab> oh I see, I think it's rechecking every pkg and some must hvae changed in the last few hrs or something... it
[22:56] <drab> 's already at 12% and that took about 30mins earlier on
[22:56] <drab> nwo it took a couple mins
[22:57] <drab> for now it's printing all lines with 200OK, maybe that means it's identifying the pks is the same
[22:57] <drab> there's no explanation about the output in the man
[22:57] <drab> but I think even when it d/l'ed it the first time it said 200