[00:00] <teward> and a completely different procedure
[00:00] <Neo4> teward: ok, then I return php*
[00:00] <sarnold> be careful with shell globs at the command line
[00:00] <teward> Neo4: that can be damaging to do that, I would use one of the other answers.
[00:00] <teward> ^ this
[00:00] <Neo4> teward: no command the same sudo apt-get purge php* or php.*
[00:00] <sarnold> if you have files named php... in the directory then things will get very surprising very quickly
[00:01] <Neo4> sarnold: in what directory apt-get purge search files for remove?
[00:02] <Neo4> shall I use php* instead like suggested in that topic use php.*
[00:02] <Neo4> php.* will match php.(any text)
[00:02] <Neo4> I might need php(any text)
[00:02] <Neo4> ok
[00:02] <sarnold> Neo4: that's the most surprising thing -- if you type "cd /etc ; apt-get purge pass*"   what will RUN is "apt-get purge passwd passwd- passwd.org passwdqc.conf"
[00:03] <sarnold> Neo4: if you're in a different directory, maybe the shell will expand the * to match other files
[00:03] <sarnold> or maybe it won't expand anythuing at all, if no files or directories match, so the glob will be passed to apt directory
[00:03] <sarnold> s/directory/directly/
[00:03] <teward> sarnold: they can do 'php*' to interpret it as a direct literal, which can be problematic if you aren't careful with it.
[00:04] <teward> which is how I purge apache2 and a dozen other patterns from VPS preinstalled images which come with crap on them :p
[00:04] <Neo4> sarnold: i run shell script that placed in $HOMe/shell/vps_install
[00:04] <teward> Neo4: may I ask, what's your native language?  we might be able to find a language-specific room that you can work with if your primary language is not English, so that they can answer you in your primary language.
[00:05] <teward> if you don't mind answering, that is.
[00:05] <Neo4> sarnold: do you think apt-get linked to current directory? I think it search in some list of certained direcotries
[00:05] <sarnold> Neo4: I don't think apt-get cares about the current working directory
[00:05] <sarnold> but the shell sure does
[00:05] <Neo4> teward: I very proficient in English, don't need :)
[00:05] <sarnold> which is why I ALWAYS use single-quotes when passing globs to apt-get
[00:06] <Neo4> sarnold: but you said if I go to cd /etc and then run apt-get purge pass* it will remove passwd and others file
[00:06] <sarnold> right
[00:06] <sarnold> so DO NOT DO THAT :)
[00:06] <sarnold> use single quotes
[00:06] <sarnold> always
[00:07] <Neo4> sarnold: why I neccessary do cd /etc ?
[00:07] <Neo4> I can run run apt-get purger from any place?
[00:07] <teward> Neo4: it doesn't matter whether you do that or not, the problem is how the terminal shell interprets php* versus 'php*'
[00:07] <sarnold> Neo4: because I know the /etc directory has files with predictable names that I can use as an example
[00:07] <teward> one with single quotes, one without.
[00:08] <Neo4> sarnold: ok, you just say about files?
[00:08] <teward> Neo4: consider this example: we are in a directory that has the following files: phptest.php phpinfo.php index.php haillucifer.php
[00:08] <sarnold> Neo4: files *and* directories
[00:08] <teward> if we do this command: apt-get remove php*
[00:08] <teward> the shell will see php* and then replace that with all the filenames or directory names with 'php' at the beginning
[00:08] <teward> and then apt-get will fail
[00:08] <teward> because there is no phptest.php package and no phpinfo.php package
[00:09] <teward> *however*, if you do this command: apt-get remove 'php*'
[00:09] <teward> then it hands the exact literal string of: php*
[00:09] <teward> ... to apt, and then lets apt handle expanding that pattern into package names to mark for removal
[00:10] <teward> so then it'd pick up php5.2 php5.2-fpm php5.2-common, etc.
[00:10] <Neo4> teward: why we should be in some directory? it maybe rm php* will remove not apt-get remove ???
[00:10] <teward> ...
[00:10] <teward> okay, i'm done, I tried, I'm sorry, but your broken english is irritating me too much.  I believe sarnold can build upon what I said
[00:10] <teward> sarnold: sorry to drop this on your plate :/
[00:10] <teward> *goes to do something else*
[00:11] <Neo4> teward: if we go to this direcotry $HOME/ddd and there will files 1.php 2.php and we run apt-get remove *.php. does it remove files form this direcotry?
[00:11] <sarnold> no, apt-get only works on packages
[00:11] <sarnold> but the shell will expand all the filenames
[00:11] <sarnold> and those might match something important.
[00:12] <Neo4> teward: see only on package, you are tried explain me about you badly understand yourself
[00:12] <Neo4> if we run rm *.php than we remove files in current dir
[00:12] <Neo4> sarnold: you are right
[00:12] <Neo4> teward: don't find reason in language if you can't clearly convey your thoughts :)
[00:13] <Neo4> ok, understood
[00:14] <sarnold> Neo4: you might also want to turn on join/part messages in your irc client, teward logged off four minutes ago, heh
[00:14] <Neo4> sarnold: what does it mean?
[00:14] <Neo4> I don't know what the messages
[00:15] <sarnold> Neo4: you missed this: Thu 17 00:10:44 -!- teward [teward@ubuntu/member/teward] has left #ubuntu-server ["Leaving"]
[00:15] <sarnold> so you kept arguing with someone who wasn't there :)
[00:16] <Neo4> sarnold: I have this, just didn't noticed he left
[00:16] <Neo4> yes I see he has left
[00:16] <Neo4> now
[00:20] <Neo4> sarnold: in this theme in each answer each people offer his regex https://askubuntu.com/questions/59886/how-to-completely-remove-php
[00:21] <Neo4> last guy said all are wrong and need to use "^php*"
[00:21] <sarnold> yes, and note that it's now got a score of 50 instead of 51, I just downvoted him :)
[00:21] <Neo4> ok
[00:21] <Neo4> I know regex
[00:21] <Neo4> just here simple regex
[00:30] <jjuujjuu> anyone have any idea why there are [two] ephemeral block devices mapped in the ubuntu hvm-ssd backed AMIs?
[00:31] <jjuujjuu> i can't seem to update it through the console, awscli, or boto (that's an amazon problem), but i'm curious why it's there in the first place
[00:39] <Neo4> sarnold: it called globing http://mywiki.wooledge.org/glob
[00:40] <sarnold> Neo4: heh, ys, remember my very first message to you tonight? :) < sarnold> be careful with shell globs at the command line
[00:41] <Neo4> sarnold: I first time heard about and didn't understand,
[00:41] <Neo4> will know :)
[00:41] <sarnold> :)
[00:55] <arooni> about to shut down a vps i used as a web app server; i've already checked and backed up all mysql databases id want; looked thru the code /var/www section... and downloads.  trying to think if there might be anything else i need before i shut it down.  am i missing naything?
[00:57] <sarnold> I'm sure you'll remember it around 2am in a cold sweat..
[00:57] <sarnold> uploads? keys?
[05:52] <cpaelzer> good morning
[05:55] <lordievader> Good morning
[10:47] <rbasak> cpaelzer: https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/345498 doesn't have a logical tag. Are you following a different workflow?
[10:54] <cpaelzer> rbasak: I had it pushed ...
[10:54] <cpaelzer> hmm
[10:55] <cpaelzer> paelzer/lp1771061/logical/3.2-4ubuntu4
[10:55] <cpaelzer> rbasak: isn't that available to you
[10:55] <cpaelzer> paelzer is my remote, so that should be good
[10:55] <cpaelzer> are the other tags as they should be?
[10:57] <rbasak> cpaelzer: I'm only seeing three - old/new debian/ubuntu
[10:57] <rbasak> Let me see what the Launchpad UI shows me
[10:57] <rbasak> (or cgit)
[10:58] <rbasak> I see them all at https://git.launchpad.net/~paelzer/ubuntu/+source/chrony/refs/?h=merge-cosmic-3.3-1
[10:58] <rbasak> Not sure why my fetch isn't picking them up
[10:58] <cpaelzer> rbasak: they are all under the lp1771061
[10:58] <rbasak> But you've pushed them, so sorry for the trouble. I'll figure it out.
[10:58] <cpaelzer> I even list the pushed tags every time in a MP, so people know which to fetch if needed
[10:59] <cpaelzer> rbasak: TBH I'm sometimes affected by https://bugs.launchpad.net/usd-importer/+bug/1739000
[10:59] <cpaelzer> rbasak: so sometimes I make some of the tags "on my own"
[10:59] <cpaelzer> rbasak: but they are still pointing to the refs they should as well as that I push them
[11:00] <cpaelzer> rbasak: let me know if there is something on my side that makes you not getting the tags
[11:00] <cpaelzer> IIRC ahasenack and I had such issues when using the --bug namespaces
[11:00] <cpaelzer> but manual fetching made it work
[11:00] <rbasak> cpaelzer: will do. I don't see how it could be anything you're doing. Seems they're on Launchpad but my local git isn't fetching them, so it has to be on my end.
[11:01] <rbasak> cpaelzer: I need to run for an early lunch. Back online later.
[12:17] <ahasenack> cpaelzer: I'm dropping the apache2 upload, it links with libcurl4 (which is fine, as that is the latest and default) but one of its universe modules from another source uses libcurl3, and libcurl3 and 4 cannot be installed at the same time
[12:18] <ahasenack> and we are doing funny things with the curl package, like:
[12:18] <ahasenack> $ cat debian/libcurl3.lintian-overrides
[12:18] <ahasenack> libcurl3: package-name-doesnt-match-sonames libcurl4
[12:28] <cpaelzer> ahasenack: ok, so you'll do another upload then that fixes this up?
[12:28] <ahasenack> no, I don't have a solution
[12:28] <cpaelzer> ahasenack: or how should I think of "dropping" the upload?
[12:29] <ahasenack> cpaelzer: deleting the upload tag
[12:29] <ahasenack> and rejecting the MP (I can't do that, I can only delete it, but I'd rather leave it so we have history/context)
[12:29] <ahasenack> I'm adding some info to the bug
[12:30] <cpaelzer> ahasenack: but the upload is done, you can't reuse the version number
[12:30] <cpaelzer> and the tag matches what was uploaded
[12:30] <ahasenack> cpaelzer: the upload is in proposed and won't migrate
[12:30] <ahasenack> I asked in ubuntu-release to reject it
[12:30] <cpaelzer> doesn't matter
[12:30] <cpaelzer> you can reject it, but in terms of the archive it exists
[12:31] <ahasenack> well, I don't know how that part works
[12:31] <cpaelzer> so you'll have to spin your fix as ubuntu2 on top of what you have
[12:31] <ahasenack> are you sure about that? Isn't the point of proposed to make sure it's ok before making it official?
[12:31] <cpaelzer> rejecting in -unapproved means it never existed from the archives POV
[12:32] <cpaelzer> but if it has been in proposed and failed for whatever reason the version number is still burned
[12:33] <cpaelzer> ahasenack: for example if you fetch in your gu repo
[12:33] <ahasenack> that's not the case for srus, I was told I could either use the previous version number or not
[12:33] <cpaelzer> ahasenack: you'll see a new pkg/import/2.4.33-3ubuntu1
[12:33] <cpaelzer> ahasenack: if the SRU is rejected in -unapproved that is true
[12:33] <cpaelzer> ahasenack: if it reached proposed then LP will later reject uploads od the same version
[12:33] <ahasenack> I see
[12:33] <ahasenack> well, let me finish writing up this blurb
[12:34] <cpaelzer> https://launchpad.net/ubuntu/+source/apache2/2.4.33-3ubuntu1
[12:34] <cpaelzer> there can't be "another" 2.4.33-3ubuntu1
[12:34] <ahasenack> as I said, I don't have a fix. So I either epoch it back to 2.4.29, or leave it like that for someone else to pick it up and come up with a fix
[12:35] <cpaelzer> epoch = URGS, there are better solutions to that
[12:35] <cpaelzer> but lets brainstorm about the issue and what could be done
[12:35] <cpaelzer> or have you evaluated it already and decided there is no way (for now)
[12:36] <cpaelzer> ahasenack: you might throw me a hangout link and explain me which apache module uses the old libcurl and why
[12:36] <cpaelzer> maybe we get an idea how to resolve
[12:36] <cpaelzer> if not I can explain how one would revert this now
[12:37] <ahasenack> it's libapache2-mod-shib2, which needs libxmltooling7, and libxmltooling7 cannot use libcurl4
[12:38] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1770242 commented
[12:38] <rbasak> ahasenack: is the transition completed in Debian? If so, how did they achieve it?
[12:39] <ahasenack> their libcurl is different
[12:39] <ahasenack> irc discussion start: https://irclogs.ubuntu.com/2018/05/16/%23ubuntu-release.html#t16:45
[12:39] <ahasenack> fun fact: "huh, in debian libcurl.so.4 is in the libcurl3 package"
[12:40] <ahasenack> and they do have a libcurl.so.3
[12:40] <ahasenack> we don't
[12:40] <ahasenack> whoever updates apache to even 2.4.30 (we are at 2.4.29) will come across this
[12:41] <rbasak> This sounds like it's going to get very involved to understand :-/
[12:42] <rbasak> Shall I leave it to cpaelzer to help? Or if you prefer I can do it, but it probably would be a waste for both of us to catch up on what is going on.
[12:42]  * rbasak is now regretting sticking his head in
[12:43] <cpaelzer> hehe
[12:43] <cpaelzer> rbasak: leave it with me for now
[12:43] <rbasak> ack
[12:43] <cpaelzer> we can re-sort on the standup later
[12:44] <cpaelzer> ahasenack: sometimes odd issues have rather blunt soltions :-)
[12:44] <cpaelzer> ahasenack: what happens if we just NOT provide the libcurl4 dev libs?
[12:44] <cpaelzer> ahasenack: Debian enabled this in 2.4.33-1
[12:44] <cpaelzer> so it is rather new, maybe it is a new feature and not 100% required?
[12:44]  * cpaelzer readas apache changelog
[12:45] <ahasenack> what is reather new? mod-md?
[12:45] <ahasenack> it's in 2.4.30, but we (and debian) have it in the archive already as its own source, an older version. I think it was finally absorbed by apache upstream
[12:46] <ahasenack> the 2.4.33 pkg now builds a transitional binary for it, as it's in apache2-bin now.
[12:46] <cpaelzer> ahasenack: and that is what needs the new libcurl and for now causes this dependency mess?
[12:47] <ahasenack> I don't know if the older source, if rebuilt now, would also link with libcurl4
[12:47] <ahasenack> which is not really "new", btw
[12:47] <ahasenack> (curl4, that is)
[12:47] <cpaelzer> libcurl3-gnutls is the old one
[12:47] <cpaelzer> lets check how old the libapache2-mod-md we have is
[12:49] <cpaelzer> Apache changelog: "mod_md: new experimental, module for managing ..."
[12:49] <cpaelzer> I think it is fair to disable that for now
[12:49] <cpaelzer> to untangle this
[12:49] <cpaelzer> and revisit after some time to pick up it and libcurl on all parts of this puzzle
[12:51]  * cpaelzer needs to rad through last buildlog and then hopefulyl comes up with an interim solution for now
[12:52] <ahasenack> I can try dropping it, there are some d/control breaks/replaces to take care of because apache 2.4.30 is essentially obsoleting the module from the other source
[12:52] <cpaelzer> yep
[12:52] <cpaelzer> but "for us" that other module exists until you get out of proposed
[12:52] <cpaelzer> so my suggestion would be (for now) drop the libcurl4 build-dep, drop the -md bits in d/rules and d/control
[12:53] <cpaelzer> that should give you a new apache with the old mod-md for now
[12:53] <cpaelzer> you can later on with a bit more patience and time re-evaluate how to get the integrated mod-md
[12:53] <ahasenack> well, with no mod-md
[12:54] <cpaelzer> --disable-md
[12:54] <ahasenack> yes
[12:54] <cpaelzer> hrm did you look at jansson ?
[12:55] <cpaelzer> oh that is no curl||jansson
[12:55] <cpaelzer> to bad
[12:55] <cpaelzer> so I stick with my suggestion above
[12:56] <cpaelzer> ahasenack: if it works it would resolve it for now, but not free you from solving the libcurl3-vs4 puzzle eventually
[12:57] <cpaelzer> never the less if it works IMHO much better than 2.4.33-3ubuntu1+really2.4.29-1ubuntu4.1
[12:57] <ahasenack> ok, thx
[12:58]  * cpaelzer is hooked and needs to check curl libs in Debian vs Ubuntu
[13:05] <ahasenack> cpaelzer: check how xmltooling is built wrt openssl version, and how debian solved the problem of xmltooling only working with openssl 1.0 (not 1.1), I think that is important
[13:05] <cpaelzer> I'm looking at that already
[13:05] <cpaelzer> and the ubuntu delta of "Rename libcurl3 to libcurl4 ..."
[13:06] <cpaelzer> ahasenack: after you have an apache in as-is you might ask slangasek to discuss a valid path out of this
[13:06] <cpaelzer> I'm pretty sure Foundations has already a plan on this
[13:06] <cpaelzer> "this" being the overall transition of curl/ssl
[13:07] <cpaelzer> after it is clear how that applies to apache2 you can lay out the steps you need to do there
[13:07]  * cpaelzer shakes his fist at soname 3 vs 4 while at versions like 7.58.0-2ubuntu2
[13:08] <cpaelzer> consistency FTW
[13:10] <ahasenack> yeah, did you see that lintian override about the soname? :)
[13:10] <cpaelzer> no but I saw your quote above
[13:11] <cpaelzer> I'm convinced trying to read into this on our own can only fail
[13:11] <cpaelzer> try to resolve it as suggested for now
[13:11] <cpaelzer> and then get in touch with the people owning the transition
[13:11] <cpaelzer> seems a much saner approach to me
[13:11] <ahasenack> let's hope it works
[13:12] <ahasenack> finding out problems so late in the upload is disturbing
[13:12]  * cpaelzer feels bad for ahasenack stumbling over stuff like this he didn's cause
[13:12] <ahasenack> thanks for the hug, appreciated
[15:29] <rbasak> ahasenack: I remember that email now. Sorry, I forgot to flag it.
[15:29] <ahasenack> np
[16:01] <hackeron> hi there, I installed ubuntu 18.04 and the commands ifdown and ifup are missing - is there a new way to start and stop a specific network interface using the settings in /etc/network/interfaces?
[16:09] <rbasak> hackeron: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#netplan.io
[16:10] <rbasak> hackeron: and https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Network_configuration
[16:11] <hackeron> rbasak: ah, I see! - is there any way to use the old /etc/network/interfaces file?
[16:12] <rbasak> hackeron: "The ifupdown package remains available and supported in Ubuntu main for users that find netplan does not currently meet their networking needs."
[16:13] <hackeron> rbasak: ah, fantastic, thank you!
[16:22] <rbasak> ahasenack: wrap-and-sort is changing things for me on your nvdimm branches, running on Bionic.
[16:22] <rbasak> I don't know if you haven't run it recently, or if Bionic's wrap-and-sort behaves differently from yours.
[17:30] <ahasenack> rbasak: in what way? I'm building that in cosmic now
[17:33] <ahasenack> rbasak: ppa:canonical-server/nvdimm has the cosmic build
[18:42] <ahasenack> rbasak: also, I ran wrap-and-sort with -a, to wrap even when the line isn't long enough
[19:20] <nikolasc> hi there. My server is always setting ondemand cpufreq with cpufrequtils disabled, tried rc.local but after reboot is always ondemand instead of performance
[19:24] <kiokoman> sudo systemctl disable ondemand
[19:25] <kiokoman> ondemand.service - Set the CPU Frequency Scaling governor
[19:25] <nikolasc> service --status-all does nto show it
[19:27] <nikolasc> kiokoman: worked
[19:28] <nikolasc> thank you
[19:28] <kiokoman> good !
[19:44] <coreycb>  jamespage: do we still bundle boost with pxc 5.7? seems like orig tars don't exist nor does d/bundle-boost.sh.
[20:28] <Ussat> whats the eta on 18.04 release ?
[20:28] <jdr> ?
[20:32] <Pici> ?
[20:32] <sdeziel> Ussat: few weeks *ago*, 18.04 was released on April 26th
[20:33] <Ussat> ahh cool, thanks
[20:33] <Ussat> hows the 16.04LTS --> 18.04 LTS ?
[20:37] <Ussat> guess will fire up a vm and test it
[21:28] <sarnold> Ussat: upgrades are mixed; my laptop upgrade did not go well, but 90% of the upgrade problems I've seen were self-inflicted
[21:28] <sarnold> (there's a decent chance my upgrade problems were self-inflicted, but we never did figure out the cause.)
[21:29] <Ussat> sarnold, I have a vm I spun up to test...gonna test about 4 more times before I attempt to do a prod system
[21:29] <Ussat> plus I have good backups
[21:29] <sarnold> Ussat: be sure to test smething that actually approaches what you use
[21:29] <sarnold> stock install upgrades are probably less interesting / less useful than "we installed a thousand packages for this that and the other thing"
[21:30] <Ussat> sarnold, oh we do, I ahve a full esxi server full of test vm's running the apps I use
[21:30] <Ussat> just pared down resource wise
[21:30] <sarnold> nice nice nice
[21:30] <sarnold> please file bugs as needed :D
[21:31] <Ussat> Work at a hospital...we are paranoid carefull
[21:31] <Ussat> probably wont actually do any prod upgrades for a few months, just want to get ahead of the curve
[21:32] <Ussat> MOstly my labs use Ubuntu, you all have the best bio/genetic packages avaliable
[21:32] <sarnold> :D
[21:32] <Ussat> We are a RHEL/AIX shop, but all our pathology labs/genetic labs run Ubuntu, as well as our genetic torrent servers
[21:33] <Ussat> Ubuntu is VERY big in medical stuff
[21:34] <Ussat> https://www.thermofisher.com/order/catalog/product/4483643
[21:34] <Ussat> we have a lot of these
[21:34] <Ussat> specialised stuff
[21:35] <Ussat> Along with my test lab, I do a lot of preliminary testing on vm's on my mac
[21:36] <sarnold> that was not what I expected from "torrent server" :)
[21:37] <Ussat> heh...yea I know...the name
[21:38] <Ussat> full name is ION-Torrent
[21:38] <Ussat> we have 5 of those along with some 64core 512GB VM's
[21:38] <Ussat> Ubuntu 16.04 LTS
[21:39] <Ussat> in our Molecular Pathology lab
[21:39] <sarnold> hehe, reminds me of running Folding@Home back in the day..
[21:41] <Ussat> OUr lab was a sponsor of that
[21:41] <sarnold> cool! :D
[21:49] <Ussat> Yea we are ultra carefull with updates, full backups, snapshots etc
[21:49] <Ussat> I say we.....I am the Linux guy here
[22:07] <rbasak> ahasenack: ah, that'll be it. No worries.
[23:08] <ahasenack> rbasak: running with -a?
[23:26] <rbasak> ahasenack: yep