=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
Harris | I want to make a custom install of elementary os which is based on ubuntu... is there a ubuntu base file that has 0 programs installed just the os | 03:21 |
---|---|---|
valorie | Harris: there is a mini-iso | 03:45 |
valorie | !mini-iso | 03:45 |
valorie | phooey | 03:46 |
valorie | one can make a custom ISO as well | 03:47 |
valorie | !iso | 03:47 |
ubottu | To mount an ISO disc image, type « sudo mount -o loop <ISO-filename> <mountpoint> » - There is a list of useful cd image conversion tools at http://wiki.linuxquestions.org/wiki/CD_Image_Conversion - Always verify the ISO using !MD5 before !burning. | 03:47 |
valorie | https://help.ubuntu.com/community/Installation/MinimalCD | 03:48 |
valorie | also there is netboot | 03:48 |
valorie | !netboot | 03:48 |
ubottu | Ubuntu can be installed in lots of ways. Please see https://help.ubuntu.com/community/Installation for documentation. Problems during install? See https://wiki.ubuntu.com/CommonProblemsInstall - Don't want to use a CD? See http://tinyurl.com/3exghs - See also !automate | 03:48 |
Harris | i need a base image though | 04:23 |
valorie | the mini-iso, as I said above | 04:28 |
krytarik | Harris: This might be what you're looking for: https://wiki.ubuntu.com/Base | 04:46 |
=== miguel_ is now known as Guest80586 | ||
bdrung_work | Trevinho, ping (regarding #1671432) | 08:27 |
rbasak | cpaelzer: argh. Bileto publishes Zesty at the same time as the SRUs? I was expecting to do Zesty only. Haven't actually reviewed the SRUs yet. | 08:40 |
cpaelzer | cpaelzer: I'd have expected to give some choice which to pub | 08:41 |
cpaelzer | rbasak: ^^ | 08:42 |
cpaelzer | talkign to myself | 08:42 |
cpaelzer | rbasak: but eventually it is not too wrong either, the zesty publish will have to move on and has to pass z-p as usual | 08:42 |
cpaelzer | rbasak: and while doing so the others stick in unapproved until that passed | 08:42 |
rbasak | It's a pain from an SRU processing perspective, because as long as it isn't in the Zesty release pocket the SRU team won't want to release the upload from xenial/yakkety unapproved. | 08:43 |
cpaelzer | rbasak: isn't that what I just said ... rereading ... | 08:44 |
cpaelzer | rbasak: so right now it is in each releases unapproved, due to the freeze on z | 08:50 |
cpaelzer | rbasak: it will stay in all of them, the first to accept at some point should be in Z | 08:51 |
cpaelzer | rbasak: there it will hopefully migrate just fine | 08:51 |
cpaelzer | and after that it is normal SRU/unapproved processing | 08:51 |
rbasak | cpaelzer: yes, I think we agree on the mechanics | 08:51 |
cpaelzer | rbasak: I don't see the extra pain yet? | 08:51 |
rbasak | My complaint was just that it can waste some SRU time, that's all - if the SRU team look to process it before the release team release it from Zesty unapproved and it finishes landing in the release pocket. | 08:52 |
rbasak | Or if there's a problem with the Zesty side, but I hope not as it is more tested by bileto in the correct environment of course. | 08:52 |
cpaelzer | ack | 08:52 |
cpaelzer | thanks to explain the extra SRU concerns | 08:53 |
cpaelzer | let me add a comment to the bug so that SRU members know right away | 08:53 |
cpaelzer | then it should only waste seconds | 08:53 |
cpaelzer | rbasak: Done | 08:58 |
cpaelzer | rbasak: didn't know that it does all-at-once publishes | 08:58 |
cpaelzer | rbasak: will split them up next time | 08:58 |
rbasak | cpaelzer: thanks. I'm not sure that's the right answer, or what the right answer is right now. I just wasn't expecting it, that's all. | 09:12 |
brendand | autopkgtest is spewing: | 10:16 |
brendand | Can't locate Dpkg/Deps.pm in @INC (you may need to install the Dpkg::Deps module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at - line 1. | 10:16 |
brendand | but that appears to be blatantly false | 10:16 |
brendand | $ ls /usr/share/perl5/Dpkg/Deps.pm | 10:16 |
rbasak | rharper: thank you very much for the chart in bug 1649931 - it's very helpful. I'm afraid I still don't follow the details though - it'll take me a disproportionate amount of time compared to the SRU queue in general I think. slangasek, as you're more familiar with this, would it make more sense for you to take care of this please? | 10:18 |
ubottu | bug 1649931 in resolvconf (Ubuntu Yakkety) "systemd-networkd needs to ensure DNS is up before network-online.target" [Medium,Fix committed] https://launchpad.net/bugs/1649931 | 10:18 |
=== Guest80586 is now known as pastillage | ||
arges | rbasak: planing on doing some sru reviews. | 12:44 |
rbasak | arges: ack. I've only been looking at releases so far today. | 12:46 |
rbasak | arges: bug 1656712 currently. | 12:46 |
ubottu | bug 1656712 in ostree (Ubuntu Xenial) "Update flatpak and ostree to 0.8" [Low,In progress] https://launchpad.net/bugs/1656712 | 12:46 |
arges | ok starting with xenial upload queue | 12:48 |
=== _salem is now known as salem_ | ||
am_ | hi all, not sure if i'm in the correct place. I am wondering what happened to dh-make-pecl in 16.04 ? | 13:29 |
am_ | i am tryiing to package up a pecl extension but the dh-make-pecl package doesn't seem to exist | 13:29 |
mterry | infinity: can you promote mediascanner2 and unity-scope-mediascanner? Would help the unity8 scopes to not be so bare | 13:58 |
infinity | mterry: Yup, getting there. | 13:59 |
mterry | Gotcha, thx! | 13:59 |
infinity | pitti: cockpit testsuite fails on armhf | 14:01 |
=== scott is now known as Guest75173 | ||
cpaelzer | I'd need opinion on proper changelog construction for SRUs | 14:12 |
cpaelzer | Example: apache2 in trusty has had a 2.4.7-1ubuntu4.14 in proposed but that failed verification | 14:12 |
cpaelzer | I'm now creating a 2.4.7-1ubuntu4.15 for a different issue and wonder what the right changelog approach is | 14:12 |
cpaelzer | a) mention the changes in the failed-to-verify as reverted in .15 | 14:12 |
cpaelzer | b) not mentioning them in .15 but keeping the .14 version in the history (I'd consider that wrong) | 14:12 |
cpaelzer | c) taking the old .14 OUT of the history so that from a users POV it goes .13 -> -15 | 14:12 |
cpaelzer | I've seen people do a) and c) and I personally would prefer c) | 14:12 |
cpaelzer | rbasak: ^^ | 14:12 |
cpaelzer | moved the discussion to ubuntu-devel | 14:12 |
pitti | infinity: you mean mips? it's fine on https://buildd.debian.org/status/fetch.php?pkg=cockpit&arch=armhf&ver=134-1&stamp=1491261708&raw=0 | 14:25 |
pitti | I'll look at the mipsen failures soon | 14:25 |
infinity | pitti: I mean armhf on Ubuntu. | 14:26 |
infinity | pitti: Note this is #ubuntu-devel :P | 14:26 |
pitti | infinity: oh, wow -- I wasn't aware someone was that trigger happy to sync it to Ubuntu already :) | 14:26 |
infinity | cpaelzer: If you've completely reverted .14, omitting that changelog entry is correct too, IMO. | 14:27 |
pitti | infinity: # assertion failed (keyring >= 0) -- ah, same issue as on mips | 14:27 |
pitti | infinity: I figure our ARM buildd kernel just has kernel keyrings disabled; I'll adjust the tests to skip in that case | 14:28 |
infinity | pitti: jbicha synced it, apparently. | 14:28 |
infinity | pitti: Err, as for kernels missing features, that seems... Wrong. | 14:28 |
infinity | pitti: Which CONFIG is that? | 14:28 |
cpaelzer | infinity: thanks | 14:29 |
pitti | infinity: I haven't looked into that at all yet, not sure | 14:29 |
infinity | CONFIG_SYSTEM_TRUSTED_KEYRING=y maybe? | 14:29 |
infinity | We have tha enforced on in all arches on xenial. | 14:30 |
* infinity scratches head. | 14:30 | |
pitti | infinity: possibly; I wonder if "keyctl list @u" works there | 14:30 |
pitti | I'll try and find a Debian porter mips box to reproduce it (but not today) | 14:30 |
pitti | also, I would have thought FF and all that, I was aiming for the adventurous aardvark | 14:31 |
infinity | pitti: Yeah, FF doesn't really apply to new universe packages. | 14:31 |
Trevinho | bdrung_work: sorry, I've been notified... Please let's get in touch tomorrow, as it's too late for me now... | 14:33 |
Trevinho | I've *not* been | 14:33 |
bdrung_work | Trevinho, no problem. just ping me tomorrow | 14:34 |
Trevinho | ack | 14:35 |
=== Guest44125 is now known as smb | ||
=== smb is now known as Guest92937 | ||
sil2100 | doko: hey! Looking at the FTBFS from the test-rebuild - is there a way to easily re-run a failed build to check if it wasn't just a transient failure? | 14:48 |
doko | sil2100: just tell me which ones to retry | 14:49 |
bdmurray | jbicha: https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1656712/comments/3 does that indicate the possibility of a regression if we release flatpak and ostree? | 15:11 |
ubottu | Launchpad bug 1656712 in ostree (Ubuntu Xenial) "Update flatpak and ostree to 0.8" [Low,In progress] | 15:11 |
jbicha | bdmurray: no, that's not a regression but a missing feature and that comment was about xenial not yakkety | 15:16 |
jbicha | bdmurray: but rbasak said he was looking at the yakkey part of that bug today | 15:16 |
rbasak | I was almost about to release that (Yakkety), but I got distracted, sorry. | 15:17 |
jbicha | currently, I have ostree and flatpak in the new queue for xenial but I didn't package xdg-desktop-portal (and -gtk) for xenial | 15:17 |
rbasak | I'll try to look again today. | 15:18 |
jbicha | thanks | 15:18 |
rbasak | jbicha: released. Sorry for the delay. | 15:20 |
jbicha | bdmurray: thanks for the ping though, I'm following up with the person that left the flatpak comment to make sure I understood correctly | 15:35 |
sil2100 | doko: I'd like to see if zeromq3 would fail again after a re-run | 15:56 |
sil2100 | doko: I vaguely remember the test-suite wasn't too solid | 15:56 |
nacc | rbasak: how is the unapproved functionality looking? | 17:29 |
rharper | slangasek: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606 ; resolvconf change got tagged in this bug; but I don't believe it's related; one user mentioned they had to downgrade, but another only had to downgrade network-manager; the change in question to resolvconf has to do with unit start up sequence and does not affect any runtime behavior (ie, resolvconf service is already active/running | 18:20 |
rharper | when encountering the issue). I'd like to mark the resolvconf task as invalid; does that seem reasonable? (and I'll include my logic for doing so ) | 18:20 |
ubottu | Launchpad bug 1671606 in resolvconf (Ubuntu) "DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1" [High,Confirmed] | 18:20 |
slangasek | rharper: sure | 18:22 |
slangasek | rharper: especially as NM+dnsmasq+resolvconf == 127.0.1.1 in /etc/resolv.conf and that shouldn't have changed | 18:22 |
rharper | slangasek: thanks! | 18:32 |
barry | bdmurray: python-babel ftbfs looks even more interesting in a local build test due to dst issues. there's no bug # atm, but i'm investigating | 18:38 |
nacc | xit | 18:39 |
nacc | bah | 18:39 |
rbasak | nacc: I haven't touched it in a while. It basically seems to work fine, though I'd like to tweak the CLI | 18:41 |
rbasak | I want it to autodetect the package name from debian/changelog so it doesn't need to be specified | 18:41 |
rbasak | And then replace the existing "usd queue <package>" with "usd queue sync". Then I think it'll be ready to land. | 18:41 |
nacc | rbasak: ok, i can probably do that locally if you want to propose a MR? | 18:41 |
rbasak | Sure, thanks! | 18:41 |
nacc | rbasak: would like to get that in the latest snap just so i can document it on the wiki too :) | 18:43 |
rbasak | nacc: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/322042 | 18:44 |
rbasak | nacc: the intention of "usd queue sync" is that then things like "usd queue approve" and "usd queue reject" will become possible. IOW, "usd queue" should take subcommands. | 18:44 |
nacc | rbasak: ack | 18:45 |
nacc | rbasak: any reason for USDQueueImporter rather than USDQueue ? (to match the others)? | 18:46 |
rbasak | No, feel free to change | 18:46 |
rbasak | It predates me deciding what to call the subcommand | 18:46 |
nacc | thanks! | 18:46 |
pfsmorigo | there is something wrong with https://insights.ubuntu.com/ | 19:30 |
sarnold | pfsmorigo: yes. it's under investigation now. | 19:31 |
pfsmorigo | sarnold, ok | 19:31 |
sarnold | thanks pfsmorigo :) | 19:31 |
wxl | probably because everyone's hitting it hard in disbelief that unity's on its way out :) | 19:31 |
pfsmorigo | wxl, yeah, I'm one of them! | 19:32 |
pfsmorigo | wxl, since it's close to april 1st I was afraid that was a lie | 19:32 |
wxl | hah it might be | 19:32 |
wxl | but i don't think so | 19:32 |
slangasek | rharper: looks like the submitter disagrees with your analysis on resolvconf | 20:07 |
rharper | I replied | 20:07 |
slangasek | ok :) | 20:07 |
rharper | I Think we need a dnsmasq task there | 20:07 |
rharper | at least if the analysis in the RH bugzilla is correct | 20:08 |
rharper | in general, a change to the unit file on when resolvconf starts doesn't impact it at runtime; no code changes to resolvconf so whatever one sees on 1.78ubuntu2 should be also seen on 178ubuntu4; I think some folks aren't aware of the 'task' to package mapping and thought I was marking the bug invalid | 20:09 |
rharper | I've invited the user to supply further details on "resolvconf not tracking interfaces" in case there is an element in resolvconf here; but that doesn't seem to be the case when pointing to an upstream fix for dnsmasq | 20:09 |
slangasek | he specifically claimed that new NM exposed a bug in the behavior of resolvconf; anyway, I just wanted to draw it to your attention since I knew you had unassigned yourself | 20:09 |
slangasek | right | 20:10 |
rharper | slangasek: cool; yeah I'm still subscribed to the bug; I appreciate the ping and advice; thanks! | 20:12 |
nacc | rbasak: i think i've got everything working with queue -- i will push it up and can you test with master? | 21:56 |
slangasek | huh, what happened on 31Jul2014 that created a bunch of backup files of .pyc on my system | 22:07 |
* mwhudson checks his diary | 22:12 | |
dasjoe | sarnold: probably better over here | 22:44 |
sarnold | ohai a second dasjoe :) | 22:45 |
sarnold | nacc: here? | 22:45 |
sarnold | dasjoe: normally you'd file a bug report with the template in the wiki; fill out the bits you can; attach a debdiff, describe how you tested | 22:45 |
nacc | sarnold: works for me | 22:45 |
dasjoe | HELO | 22:46 |
nacc | dasjoe: is there a bug filed? | 22:46 |
dasjoe | So rbasak asked for a proper SRU in https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193 and I'm trying to fulfil his request | 22:46 |
ubottu | Launchpad bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Medium,Confirmed] | 22:46 |
nacc | dasjoe: ok, so you confirmed it's fixed in zesty? | 22:47 |
dasjoe | nacc: well, I'm in the process of doing so. Haven't booted zesty yet, but manually installing zesty's debs in xenial fixes the not-appearing part of the bug | 22:48 |
nacc | um, that's probably not the right way to test | 22:49 |
nacc | hopefully that was in a removable VM :) | 22:49 |
dasjoe | It's not a VM but a sandbox laptop ;) | 22:49 |
nacc | oh ok | 22:50 |
nacc | so presuming you do verify the fix in zesty, update the bug to fix released (if you can, or just put a comment in) | 22:50 |
nacc | i just created tasks for x & y | 22:50 |
dasjoe | So, the "fix" required two updated packages, network-manager-strongswan and strongswan-nm. I would have created a new bug in LP and marked both packages as affected | 22:52 |
sarnold | dasjoe: so... what's the goal? move the packages from https://launchpad.net/~raharper/+archive/ubuntu/bugfixes/+packages to the main archive? have you tested those? or is another goal? | 22:52 |
nacc | dasjoe: no, you can create tasks against multiple source packages in one bug | 22:52 |
dasjoe | sarnold: the easiest goal would be to simply copy network-manager-strongswan, strongswan-nm from z to x & y | 22:53 |
sarnold | dasjoe: aha :) | 22:53 |
dasjoe | I haven't looked at raharper's PPA | 22:53 |
nacc | dasjoe: taht won't happen | 22:54 |
nacc | dasjoe: SRUs need to be small and self-contained | 22:54 |
nacc | ideally | 22:54 |
nacc | z is several minor version bumps | 22:54 |
dasjoe | Yeah, I thought so | 22:54 |
nacc | well, i should say, that won't happen normally | 22:54 |
nacc | and certainly not in the context of this bug which seems to be for only one specific issue with one specific fix | 22:55 |
dasjoe | It's just that the package in x does not work *at all* so there would be no harm in upgrading to a fresher upstream version | 22:55 |
sarnold | heh, sounds persuasive to me :) | 22:56 |
dasjoe | It's the one thing that's holding back a VPN rollout for a customer, so I'm looking to get IKEv2 usable via nm without having to build stuff by hand ;) | 22:57 |
dasjoe | Oh well, time to a) build a IKEv2 VPN gateway VM and b) get and boot zesty. I'll be back… tomorrow, hopefully | 23:03 |
sarnold | dasjoe: the backportpackage command may make it easy to test building the zesty pacakge against xenial | 23:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!