| Delemas | On LTS anyone else having issues with the most recent linux-firmware update trying update-initramfs a 3.19.0-21 kernel they haven't had in years? I don't get where it is coming from. | 01:02 |
|---|---|---|
| TJ- | Delemas: check under "ls /var/lib/initramfs-tools/" for a directory for that version | 01:13 |
| Delemas | Oh bingo that shouldn't be there... | 01:15 |
| Delemas | TJ- Thanks | 01:15 |
| Delemas | Great! That fixed it. Thanks. :) | 01:17 |
| cpaelzer | snowy morning everybody | 06:44 |
| lordievader | Good morning | 07:16 |
| cpaelzer | gm lordievader | 07:23 |
| lordievader | Hey cpaelzer | 07:23 |
| lordievader | How are you doing? | 07:23 |
| cpaelzer | great - and you? | 07:24 |
| lordievader | Doing okay here, haven't had coffee yet though | 07:27 |
| ahasenack | rbasak: good morning/afternoon | 11:04 |
| ahasenack | rbasak: did you see the ping on the zstd bug? The packages should be in the sru queue, I wonder if you saw them in your sru day yesterday | 11:04 |
| rbasak | ahasenack: I didn't yesterday, but I'll look at that next today | 11:09 |
| ahasenack | ok, thanks | 11:10 |
| Isla_de_Muerte | Heya guys, is there a specific amount of free RAM I should keep on the server? I did some apache changes and free -ht shows free mem down from 1.9GB to 600mb | 11:11 |
| rbasak | Isla_de_Muerte: https://askubuntu.com/a/116359/7808 | 11:12 |
| Isla_de_Muerte | rbasak, tyvm | 11:13 |
| Isla_de_Muerte | It seems like almost 8GB is free to use | 11:14 |
| hateball | unused RAM is wasted RAM :p | 11:14 |
| Isla_de_Muerte | total used free shared buffers cached | 11:15 |
| Isla_de_Muerte | Mem: 16006 15285 721 1020 0 7425 | 11:15 |
| Isla_de_Muerte | -/+ buffers/cache: 7858 8147 | 11:15 |
| Isla_de_Muerte | I was only watching the first line :P Oh well tyvm for the help guys | 11:15 |
| lordievader | !free | 11:16 |
| ubottu | freedom is important. Ubuntu is as free as we can make it, which means mostly free software. See http://www.gnu.org/philosophy/free-sw.html and http://www.ubuntu.com/project/about-ubuntu/licensing | 11:16 |
| lordievader | !ram | 11:16 |
| ubottu | If you are wondering why some tools report your system has very little free memory, have a look at http://www.linuxatemyram.com/ | 11:16 |
| lordievader | That's the one | 11:16 |
| lordievader | But as hateball says, unused ram is wasted ram. Unless you frequently reload programs which swap a lot of ram. | 11:17 |
| rbasak | cpaelzer, ahasenack: I'm a bit confused as to why https://code.launchpad.net/~ahasenack/ubuntu/+source/libzstd/+git/libzstd/+merge/336258 is showing as Merged | 11:18 |
| rbasak | I can ignore that and proceed anyway. I'm just wondering if that's a workflow issue or consequence of something | 11:18 |
| ahasenack | rbasak: I think cpaelzer changed that once it was uploaded to proposed | 11:18 |
| rbasak | Ah. Because he pushed an upload tag perhaps? | 11:19 |
| ahasenack | he did that too | 11:19 |
| ahasenack | but I'm also confused by the mp status in general | 11:19 |
| ahasenack | I would think that lp would detect it as such once the importer imported the uploaded package the next time | 11:19 |
| rbasak | It's not good whichever way we do it for SRUs :-/ | 11:19 |
| rbasak | Since the uploader (or sponsor) has the upload tag but does not know if the SRU will be accepted. | 11:19 |
| ahasenack | since srus can take months, setting the mp to merged is a cheap way to get it out of our view I guess | 11:20 |
| rbasak | OK. Let's just keep doing that for now, and we'll deal with it individually if something goes wrong. | 11:20 |
| ahasenack | we should talk about it in the sprint | 11:20 |
| ahasenack | (yeah, it's that time of the year again :) | 11:20 |
| rbasak | ahasenack: we're deferring workflow stuff in favour of getting all the packages imported first | 11:22 |
| ahasenack | ok | 11:23 |
| cpaelzer | rbasak: ahasenack: so far I handled it as tag-push=>dput=>merged | 11:45 |
| cpaelzer | but reading through your discussion it seems you in general agree | 11:45 |
| cpaelzer | until we have worked on the improved workflows | 11:45 |
| rbasak | Yeah | 11:45 |
| ahasenack | and yes, we have had cases where the package was not used, like ubuntu-fan, where smb (I think) took over that sru | 11:46 |
| rbasak | It's probably the least worst answer right now | 11:46 |
| ahasenack | at worst we lose rich history, right? | 11:46 |
| rbasak | If the SRU isn't accepted, the upload tag will need removing or superseding | 11:46 |
| rbasak | Or it'll be present, wrong, but not adopted | 11:46 |
| cpaelzer | yep | 11:46 |
| cpaelzer | essentially we (tag pushers) need to be informed if it was rejected | 11:47 |
| jamespage | coreycb: nearly there with heat - tripped over a python-tz issue this morning :-) | 13:25 |
| coreycb | jamespage: oh interesting. | 13:26 |
| jamespage | coreycb: its fixed in debian - just pending a sync to happen | 13:26 |
| jamespage | syncpackage: Error: Debian version 2018.3-2 has not been picked up by LP yet. Please try again later. | 13:26 |
| coreycb | jamespage: ok. i need to figure out some failures with neutron-vpnaas. | 13:27 |
| coreycb | jamespage: qemu is fixed up in ocata-proposed btw | 13:28 |
| jamespage | coreycb: awesome-o | 13:28 |
| jamespage | what was the problem? | 13:28 |
| coreycb | jamespage: one of the spectre patches was causing a segfault | 13:29 |
| coreycb | jamespage: there were 2 approaches to the patch so i went with the alternative used in xenial | 13:30 |
| jamespage | ok | 13:35 |
| ahasenack | rbasak: I have the changes you requested for the livepatch motd in the ubuntu-advantage-tools | 13:48 |
| ahasenack | rbasak: a process question now (as in procedure) | 13:48 |
| ahasenack | rbasak: in upstream (github), I usually just do a new release | 13:48 |
| ahasenack | rbasak: in this case, what you reviewed in that MP was upstream release v14 | 13:48 |
| ahasenack | rbasak: I would normally now do an upstream v15, with the requested changes, and that update the MP with that | 13:49 |
| ahasenack | rbasak: end result is that v14, albeit released upstream (github) and in some ppas, was never in ubuntu | 13:49 |
| rbasak | ahasenack: it's a Debian native package, isn't it? | 13:49 |
| ahasenack | rbasak: do you have an issue with that? Assuming you would approve this v15 MP, that d/changelog would mention both v14 and v15 | 13:49 |
| ahasenack | rbasak: it is | 13:50 |
| rbasak | You may have to skip this time. | 13:50 |
| ahasenack | not my call, but somebody made it native some time ago | 13:50 |
| rbasak | But normally you should be testing with things like 15~ppa1 | 13:50 |
| ahasenack | I do | 13:50 |
| ahasenack | the daily build ppa uses git revnos even | 13:50 |
| ahasenack | and they are using 14 | 13:51 |
| ahasenack | but 14+ I think | 13:51 |
| ahasenack | yeah, 14+stuff | 13:51 |
| rbasak | Github "releases" make no sense here. I wouldn't do them. | 13:51 |
| ahasenack | I need a tarball | 13:51 |
| ahasenack | and github releases make them for me | 13:51 |
| rbasak | "git archive" | 13:51 |
| ahasenack | "button" | 13:51 |
| rbasak | "script" :) | 13:51 |
| ahasenack | github will eventually need a release | 13:52 |
| ahasenack | it's a matter of ordering | 13:52 |
| rbasak | How so? | 13:52 |
| ahasenack | release in ubuntu first, then make mps to release in github, since I need to change d/changelog | 13:52 |
| ahasenack | or release in gh first, with the mps over there, then make an mp in launchpad for the ubuntu release | 13:52 |
| ahasenack | I can't commit without mps, and I also can't upload it to ubuntu | 13:53 |
| ahasenack | I personally don't mind having the d/changelog mention v14 and v15 | 13:53 |
| ahasenack | they were releases | 13:53 |
| ahasenack | one just never made it into the *archive* | 13:54 |
| rbasak | They weren't releases. | 13:54 |
| rbasak | There is no upstream here. | 13:54 |
| ahasenack | there is, and ubuntu isn't it | 13:54 |
| rbasak | If it didn't get published in Ubuntu, it wasn't "released", despite what you want to call it. | 13:54 |
| rbasak | Are you publishing this anywhere apart from Ubuntu? | 13:54 |
| ahasenack | ubuntu ppas | 13:55 |
| ahasenack | and github tarballs | 13:55 |
| rbasak | For development and test, or actual use by anyone else? | 13:55 |
| ahasenack | it's a public ppa, the url was used in document specs for people to see what's coming up | 13:55 |
| ahasenack | built via a recipe | 13:55 |
| rbasak | It seems to me that you (collectively) are making this far more complicated than it needs to be. | 13:56 |
| rbasak | What you're doing (maintaining a git tree in Github) is fine, but is really no different than any Debian packaging maintenance team maintaining a native package in alioth (now salsa). | 13:57 |
| ahasenack | it's a bit different | 13:57 |
| rbasak | Stop doing tarball releases in Github. Use Launchpad build recipes for your test/preview PPAs. | 13:58 |
| ahasenack | the debian team make a release in salsa and upload right away | 13:58 |
| rbasak | Not necessarily | 13:58 |
| rbasak | Treat the Github master as the place to prepare Ubuntu uploads. | 13:58 |
| ahasenack | when they are happy with a salsa tree, they update d/changelog there and upload | 13:58 |
| ahasenack | when I'm happy with my gh tree, I need to make an MP for an ubuntu reload, which may or may not be accepted | 13:58 |
| rbasak | Prepare d/changelog in Github if you wish, with MPs. | 13:58 |
| ahasenack | if changes are requested, I need to make PRs in github to land those, which may or may not be accepted | 13:59 |
| rbasak | But at that stage, you can edit the latest entry in d/changelog as you wish, including retrospective changes. | 13:59 |
| rbasak | Because nothing is "released" | 13:59 |
| ahasenack | ok, you are saying treat ubuntu as the source of truth | 13:59 |
| rbasak | Yes. | 13:59 |
| rbasak | Because it has to be _a_ source of truth. | 13:59 |
| rbasak | By not making it the _only_ source of truth, you're making everything difficult. | 14:00 |
| ahasenack | I'm seeing ubuntu jsut as the delivery mechanism | 14:00 |
| ahasenack | the archive, specifically | 14:00 |
| ahasenack | some releases make it there, some don't | 14:00 |
| rbasak | I think that's where the complication arises. | 14:01 |
| rbasak | If you want to treat it that way, then it'll be easier to switch to a non-native package, and use a separate packaging branch. | 14:01 |
| ahasenack | I don't see having entries in d/changelog that never made it to the archive as a complication, but I'm asking because I know others do | 14:01 |
| rbasak | That's more effort than it's worth if the only production consumption of this work is via the Ubuntu archive. | 14:01 |
| rbasak | Having entries in d/changelog that never made it to the archive is wrong. | 14:02 |
| ahasenack | ok, that settles it then | 14:02 |
| rbasak | At upload time, d/changelog should be summarising the changes made in that upload only, so the debdiff going "in" to the archive matches the changelog. | 14:03 |
| ahasenack | well, we have ton of entries in d/changelog that never existed in the ubuntu archive: debian releases | 14:03 |
| ahasenack | but that's a specific case I suppose | 14:03 |
| rbasak | True. That's a wart we have to live with. | 14:03 |
| ahasenack | and dpkg-genchanges has -v to grab multiple d/changelog releases in one upload | 14:04 |
| rbasak | d/changelog is linear, and that doesn't work well with Ubuntu being a derivative leading to non-linear history. | 14:04 |
| ahasenack | so the changes file would grab v14 and v15, in this example | 14:04 |
| ahasenack | it's my understanding packages in proposed that were superseeded also trigger this case | 14:05 |
| rbasak | Packages in proposed have been "published" | 14:05 |
| rbasak | They are published in Launchpad forever. | 14:05 |
| ahasenack | but if they never migrated to proposed actual (srus, for example), then nobody could get them | 14:06 |
| rbasak | Oh | 14:06 |
| ahasenack | or even if stuck in excuses | 14:06 |
| ahasenack | for the devel release | 14:07 |
| rbasak | For stuff not accepted by the queue (eg. an SRU rejection), we don't "burn" version numbers. | 14:07 |
| rbasak | Let me try and simplify this a little. | 14:07 |
| ahasenack | what if it was just not looker at yet, and somebody else starts a new sru, including the changes from the previous unapproved one? | 14:07 |
| ahasenack | I'm hunting down corner cases now, I know | 14:08 |
| ahasenack | there is what is possible to do, and what is best :) | 14:08 |
| rbasak | If the goal is to have the previous unapproved SRU rejected from the queue | 14:08 |
| rbasak | Then the replacement should use the same version number. | 14:08 |
| ahasenack | ok | 14:08 |
| rbasak | Version numbers are in flux until Launchpad accepts an upload and publishes it in the archive. | 14:09 |
| rbasak | Regardless of pocket. | 14:09 |
| rbasak | As soon as that happens, the version number is "burned". | 14:09 |
| rbasak | The changelog should reflect published versions only. | 14:09 |
| rbasak | The changelog in published versions should not skip version numbers. | 14:10 |
| rbasak | As you say there are exceptions. Perhaps there has to be an exception for you this time. But your workflow in general should not need any exceptions. If necessary, we need to fix your workflow :) | 14:10 |
| ahasenack | it's weird for me to consider myself as upstream when I can't "commit" to upstream, if ubuntu is the upstream | 14:11 |
| ahasenack | I can behave as a proper upstream in github | 14:11 |
| ahasenack | but not in ubuntu | 14:12 |
| ahasenack | that's what lead me to consider github the upstream, and ubuntu as just one delivery mechanism | 14:12 |
| ahasenack | which gets a curated set of the upstream releases | 14:12 |
| rbasak | There is no upstream. It's all Ubuntu here. You are an Ubuntu developer. You just need a "reviewer" to "commit", that's all. | 14:12 |
| ahasenack | I'll continue with v14 and just amend d/changelog with the changes, let's see how it goes | 14:13 |
| ahasenack | but first, lunch | 14:14 |
| rbasak | I think that'll be fine - thanks! | 14:14 |
| ahasenack | thanks for the talk | 14:14 |
| rbasak | ahasenack: yw. Another thought: if you had an ~ubuntu-core-dev approve every MP, then getting a successful upload into Ubuntu would be a no-op. | 14:19 |
| rbasak | And you need to do that anyway, so perhaps bringing that closer into your workflow would smooth things out. | 14:20 |
| rbasak | In Launchpad I'd suggest just maintaining the repo in lp:~ubuntu-core-dev/ubuntu-advantage-tools; then any core dev sponsor can verify it's already reviewed just looking at the repo permissions. | 14:21 |
| rbasak | I'm not sure how that might work in GitHub. | 14:21 |
| coreycb | jamespage: looks like we can drop neutron-vpn-agent binary package and init scripts - https://bugs.launchpad.net/neutron/+bug/1692128 | 14:24 |
| ubottu | Launchpad bug 1692128 in neutron "VPNaaS stuff should load inside of an l3 agent extension mechanism" [Undecided,Fix released] | 14:24 |
| jamespage | coreycb: awesome | 14:25 |
| rh10 | guys, how can i more handy ping a lot of servers simultaneously? | 14:42 |
| lordievader | rh10: Fping was more suited for that, I believe: https://fping.org/ | 14:45 |
| coreycb | jamespage: i'm not sure where to put strongswan and keepalived deps now. python-neutron-vpnaas or neutron-l3-agent. | 14:45 |
| rh10 | lordievader, got it! thanks | 14:46 |
| Neo4 | what is read about ssl? | 14:46 |
| Neo4 | I'm going to read something about ssl and mail server | 14:47 |
| Neo4 | I wish I had read something about ssl and mail server... | 14:47 |
| Neo4 | any suggestions? | 14:47 |
| Neo4 | :) | 14:47 |
| Neo4 | I've read there exists also corier and exem... | 14:49 |
| Neo4 | this is read about ssl? https://www.openssl.org/ | 14:52 |
| Neo4 | about mail I know, What would you suggest to learn about ssl? | 14:52 |
| coreycb | jamespage: mind reviewing this when you have a sec? https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/neutron-vpnaas/log/ | 14:58 |
| jamespage | coreycb: what do we do with config files etc for neutron-fwaas? | 15:03 |
| jamespage | this kinda puts vpnaas on the same footing I think | 15:03 |
| coreycb | jamespage: they get installed in /etc/neutron | 15:04 |
| coreycb | jamespage: let me revisit configs, vpn_agent.ini is gone | 15:05 |
| jamespage | coreycb: I'm going todo something a little different with the pxc-5.7 orig.tar.gz | 15:09 |
| jamespage | no reason why we can't repack it with the required minimal boost headers - I got some info of the oracle guys as to what they do for mysql-boost-* | 15:10 |
| jamespage | thus not requiring an each 80MB of upload | 15:10 |
| jamespage | and an extra tarball | 15:10 |
| coreycb | jamespage: sounds good | 15:11 |
| coreycb | jamespage: onovy pointed me to autopkgtest-pkg-python | 15:23 |
| jamespage | coreycb: oh yes? | 15:23 |
| coreycb | jamespage: very nice, didn't know about it | 15:23 |
| coreycb | jamespage: tests basic import of python modules for dep8 | 15:23 |
| jamespage | coreycb: yeah I contributed a fix to make it work with the oslo packages towards the start of the cycle | 15:23 |
| coreycb | jamespage: cool | 15:23 |
| jlacroix | I noticed on the tutorial page for LXD (https://tutorials.ubuntu.com/tutorial/tutorial-setting-up-lxd-1604#1) is having the user install LXD via Apt. Isn't the Snap version of LXD preferred currently? | 15:56 |
| marsje | I just found out my Ubuntu 16.04.3 LTS instances don't automatically sync time with NTP servers. How can I fix this? | 17:34 |
| nacc | jlacroix: i think so, but relatively recently | 17:36 |
| rbasak | They should be. | 17:36 |
| nacc | jlacroix: possibly the tutorial has not been updted | 17:36 |
| nacc | dpb1: --^ fyi ? | 17:36 |
| rbasak | (syncing with timeservers) | 17:36 |
| dpb1 | jlacroix: both are supported currently, stgraber, do you want the tutorial to prefer snaps? | 17:36 |
| rbasak | marsje: systemd-timesyncd is enabled by default on 16.04. You'll need to debug that. | 17:37 |
| marsje | rbasak: I did install upstart, so not sure if that automatically gets rid of systemd and the default services? | 17:37 |
| stgraber | dpb1: yeah, we should prefer snaps in instructions in general these days, it's more future proof | 17:37 |
| rbasak | marsje: yeah, that'll do it. Using upstart on 16.04 is not supported. | 17:37 |
| nacc | and seems like a ... bad idea? | 17:38 |
| marsje | rbasak: I had some dependency on upstart and figured it didn't matter much...... | 17:38 |
| rbasak | It absolutely matters. | 17:38 |
| marsje | I think I found out just now | 17:39 |
| marsje | anyway, all I did was something like apt-get install upstart | 17:40 |
| rbasak | It's your system so you can do what you want, but you'll be mostly broken and on your own if you carry on down that path. | 17:40 |
| marsje | hmm, not sure if it can be easily fixed now... | 17:41 |
| * marsje is AFK | 17:41 | |
| Secutor | I'm trying to add rdiff-backup to zesty server. Apparently rdiff-backup is in universe. But sudo apt-get install rdiff-backup is failing. Any suggestions? | 18:35 |
| nacc | Secutor: zesty is eol | 18:36 |
| nacc | Secutor: please upgrade | 18:36 |
| Secutor | OK thanks. | 18:36 |
| ptx0 | mason: whatever happened to you :P | 19:00 |
| mason | ptx0: I ran out of linespace on my first line, where #zfsonlinux was. I might put it back. Too many IRC channels... | 19:01 |
| ptx0 | mason: weird, irssi has 5 rows of channels here | 19:01 |
| mason | Eight here at present. :P | 19:02 |
| ptx0 | got 79 windows open, wonder what happened, i used to be in 188 channels.. | 19:02 |
| ptx0 | was gonna tell you to check out nohidea | 19:02 |
| ptx0 | basically any/all of their stuff <3 | 19:03 |
| ptx0 | it's all creative commons too | 19:03 |
| mason | Yar, that's too much to keep up. That said, I was thinking of jumping back into a couple channels. I'll just add them to the end. | 19:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!