| Pharaoh_Atem | nacc: well, I ruled out the upcoming pcre-8.38-7.fc23 update pending as a potential solution | 00:02 |
|---|---|---|
| Pharaoh_Atem | I just checked it, and I still get the same backtrace | 00:02 |
| nacc | Pharaoh_Atem: thanks for doing that | 00:06 |
| nacc | Pharaoh_Atem: yeah, I think it's a *new* bug, but i'm not sure; I believe i at one point in a sbuild env, built upstream pcre directly from source and it also segfaulted | 00:07 |
| Pharaoh_Atem | nacc: I figured that this is a new bug | 00:08 |
| Pharaoh_Atem | but with how hairy libpcre is, you never know | 00:08 |
| nacc | so if i've got a fix, knowing we're past FF, for an actual bug (already filed), do i subscribe sponsors or release at this point? as i can't upload myself? | 00:26 |
| nacc | rbasak: can you update usd with logwatch 7.4.2 from debian/unstable? I'll merge and post the debdiff to get that sync'd | 00:31 |
| nacc | slangasek: php-imagick fixes (final ones) posted | 00:38 |
| nacc | that shoudl free up php7.0 and php-defaults | 00:38 |
| nacc | slangasek: i'll look at symfony and php-proxy-manager next, after i file a few non-php bugs :) | 00:39 |
| infinity | nacc: Bugfixes don't break Feature Freeze, the key word there is "feature". | 00:44 |
| nacc | infinity: yep, understood, just wasn't sure who to subscribe to the bug, exactly | 00:45 |
| nacc | infinity: from what you said, it sounds like i should still subscribe sponsors? | 00:45 |
| infinity | nacc: Same workflow as pre-FF, unless it needs an exception (which it doesn't sound like it does). | 00:45 |
| nacc | infinity: ok, thanks! | 00:46 |
| infinity | nacc: (ie: If you had upload rights, you should just be firing bugfixes at the archive without asking, without upload rights, find a sponsor, only bug the release team if you're breaking the freeze) | 00:46 |
| nacc | infinity: right, makes sense to me! | 00:46 |
| nacc | infinity: thanks again | 00:47 |
| smoser | hey. | 01:26 |
| smoser | so cloud-inti writes a bunch of systmed .service files. | 01:26 |
| smoser | in /lib/systemd/system/ | 01:26 |
| smoser | and i've moved those to /root/store (random directory, pretty sure systemd isn't looking there) | 01:26 |
| smoser | then rebooted | 01:26 |
| smoser | systemd-analyze dump | 01:27 |
| smoser | ^ that still knows about these jobs. | 01:27 |
| smoser | how ? | 01:27 |
| smoser | what do i have to do? i've told it 'systemctl daemon-reload' | 01:27 |
| smoser | which i wouldnt have thought mattered across a reboot | 01:27 |
| sarnold | smoser: try systemctl list-unit-files ? | 01:28 |
| smoser | that doesnt show them. | 01:29 |
| smoser | ah | 01:30 |
| smoser | /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cloud-config.service | 01:30 |
| smoser | hm.. well then. | 01:30 |
| smoser | thank you deb-systemd-helper-enabled for being so... helpful | 01:30 |
| smoser | thanks sarnold | 01:39 |
| Pharaoh_Atem | smoser: black magic is fun :( | 01:40 |
| smoser | and now, my friend 'Hash sum mismatch' has come to visit while i'im trying to sbuild. | 01:41 |
| smoser | thanks to you too | 01:41 |
| smoser | anyone have an idea on how i'd convince dh_systemd_enable to disable the jobs it previously enabled . | 01:50 |
| smoser | upgrade i no longer want them there. | 01:50 |
| smoser | well, filed bug. | 02:05 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1552999 | 02:05 |
| ubottu | Launchpad bug 1552999 in init-system-helpers (Ubuntu) "dh_systemd_enable not able to disable on upgrade" [Undecided,New] | 02:05 |
| smoser | if anyone wants to add some help. please feel free. | 02:05 |
| === robert_ancell_ is now known as robert_ancell | ||
| === juliank_ is now known as juliank | ||
| === pepee- is now known as pepee | ||
| Mirv | pitti: the s390x karchive seem stuck forever at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src | 05:19 |
| infinity | Mirv: Retried. | 05:34 |
| Unit193 | infinity: Oh say, think those crazy archive admins would merge irssi? :P | 05:37 |
| infinity | Unit193: Not really the responsibility of archive admins to do merges. | 05:38 |
| Unit193 | No, but they'd approve or reject after FF. | 05:39 |
| Unit193 | FF not being Firefox. | 05:39 |
| infinity | Unit193: That would be the release team. And I'd probably allow it, if I had more info. | 05:39 |
| infinity | Unit193: Like, what's changed, do all the rdeps work with it, etc. | 05:39 |
| cpaelzer | good morning | 05:46 |
| Mirv | infinity: thank you | 05:47 |
| pitti | Good morning | 05:47 |
| Mirv | good morning | 05:47 |
| Unit193 | New upstream release, always great to get the latest (when it's had quite a few bug fixes even more so) before something's to be supported for a few years. ;) | 05:49 |
| Unit193 | https://sigma.unit193.net/source/irssi_0.8.18-1ubuntu1.dsc looks like it, I believe. | 05:51 |
| infinity | Mirv: Looks like that did the trick, you're migrating. | 05:59 |
| pitti | superm1: thanks, so we still use wl; it appears that the brcmfmac firmware is reasonably free even? (it's in linux-firwmare) | 06:16 |
| pitti | nacc: right, apparently dpkg-source spits out some unexpected jitter on stdout; I'll see if I can reproduce this | 06:17 |
| pitti | Mirv: ah, some remaining fallout from yesterday's infra problems; next britney run will catch u | 06:18 |
| pitti | p | 06:18 |
| pitti | nacc: or just sign your .dsc to avoid the error :) | 06:22 |
| pitti | nacc: but indeed this should be filtered out | 06:22 |
| Mirv | yes it did indeed migrate just minutes after infi_nity's restart | 06:28 |
| pitti | nacc: also, which runner is that? lxc? qemu? | 06:28 |
| pitti | nacc: can you please file a bug with the full log and invocation? I can't reproduce this even with an unsigned package, this must be something more subtle | 06:30 |
| pitti | nacc: ah, LXC runner? indeed I get something there, apparently still a regression with lxc-attach stream handling (~rc1 still works) | 06:46 |
| superm1 | pitti: yes, it works pretty well overall too | 07:10 |
| pitti | robru, Mirv: FYI, we can now easily mass-retry failed or stuck "in progress" tests in silos; retry-autopkgtest-regressions --silo 050 --state RUNNING | 07:20 |
| pitti | so no need to fiddle around with request.cgi URLs if it happens for more than three or so packages | 07:20 |
| pitti | or no need to remove pending.json | 07:20 |
| robru | pitti: how is "silo" determined? is that just a reference to the PPA name? | 07:21 |
| pitti | robru: it determines the landing-XXX bit in https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-036/excuses.yaml | 07:21 |
| robru | pitti: is it hardcoded to key off "landing-" specifically? I'm currently working on a total rewrite of how the train handles PPAs (creating them dynamically rather than allocatinng from a pool), and the new way is to have them simply numbered. can your script cope with this change? | 07:22 |
| pitti | robru: not right now, but it can be adjusted trivially | 07:22 |
| pitti | robru: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1002 | 07:23 |
| robru | pitti: ok, look for that in a month or two ;-) | 07:23 |
| pitti | robru: this was a quick hack to salvage landing 036 and 050 which fell victim to yesterday's infra work | 07:23 |
| pitti | and writing this 10-line patch was way faster (and more satisfying) than cobbling together the right commands manually :) | 07:23 |
| robru | pitti: no worries, just be aware that "landing-%s" will eventually need to be just "%s" | 07:24 |
| pitti | robru: yep, and then we'll just update it in the script | 07:24 |
| pitti | robru: probably it'll become --ci-train then, and you are expected to specify the full name | 07:24 |
| robru | cool | 07:24 |
| pitti | robru: I suppose we could alredy do this right now | 07:25 |
| pitti | robru: as long as the bit in the URL and the actual PPA name match | 07:25 |
| robru | pitti: well if you do it now then everybody will have to type landing- all the time | 07:25 |
| robru | pitti: yeah that's the plan | 07:25 |
| pitti | robru: well, we expect this to get run less than once a month, and I don't want many people to actually run it :) | 07:25 |
| robru | pitti: heh, then I guess it doesn't matter | 07:26 |
| pitti | ./retry-autopkgtest-regressions --ci-train landing-050 --state RUNNING | 07:28 |
| robru | pitti: looks good | 07:28 |
| pitti | robru: ^ ok, it's like that now; that shoudl be compatible with the future | 07:28 |
| robru | perfet | 07:28 |
| robru | perfect | 07:28 |
| pitti | http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1002 | 07:28 |
| robru | pitti: did you just --overwrite a publicly-pushed commit? naughty! | 07:29 |
| pitti | *shrug*, it was there for like 10 seconds | 07:29 |
| tjaalton | my kvm hosts have lost network for some reason, but only those that use dhcp | 07:40 |
| tjaalton | err guests | 07:40 |
| tjaalton | dunno if kicking the bridge around might break them, or if it's just the router dchp acting funny | 07:45 |
| === dgadomski_ is now known as dgadomski | ||
| tjaalton | looks like the bridge doesn't work at all.. | 08:00 |
| Mirv | pitti: I just noticed there is indeed such a script in my ubuntu-archive-tools folder :) | 08:19 |
| pitti | Mirv: right, you can run it, and it'll dutifully spit out the run-autopkgtest commands; but you can't run *those* | 08:21 |
| pitti | (as they need to be run on snakefruit) | 08:21 |
| Mirv | ah | 08:21 |
| pitti | r-a-r just downloads excuses.yaml and generates commands on stdout, it's harmless | 08:21 |
| rbasak | nacc: logwatch> done, I think. | 09:12 |
| pitti | nacc: workaround to unblock you: adt-run -l /dev/null; I filed this a bug 1553097 | 09:19 |
| ubottu | bug 1553097 in lxc (Ubuntu) "latest LXC breaks autopkgtest's LXC runner" [Undecided,New] https://launchpad.net/bugs/1553097 | 09:19 |
| pitti | nacc: ok, got it, iz lxc bug; so use that workaround, or the lxd runner, or downgrade lxc | 09:31 |
| LocutusOfBorg | is xorg 1.18 in 16.04 rootless? | 09:40 |
| pitti | tseliot: ah, ubuntu-drivers-common tests fail now because they test fglrx; I'll change them to something else, like wl or nvidia | 09:42 |
| pitti | tseliot: however, there's also a lot of fglrx code i gpu-manager which should be dropped; can you please do that, as you are much more familiar with that? | 09:42 |
| LocutusOfBorg | tjaalton, ^^^ | 09:43 |
| seb128 | pitti, tseliot, is there anything replacing fglrx? or opensource drivers better now and doing everything the ati ones were doing? | 09:44 |
| tjaalton | LocutusOfBorg: rootless? | 09:44 |
| * seb128 just curious | 09:44 | |
| tjaalton | LocutusOfBorg: it's supported, needs *dm support (lightdm doesn't have it) | 09:44 |
| pitti | seb128: I was asked to remove fglrx yesterday, as it doesn't get updates any more and doesn't work with the new X.org ABI; and allegedly the FOSS drivers are now good enough | 09:45 |
| tjaalton | yes | 09:45 |
| seb128 | good enough or as good? | 09:45 |
| tjaalton | define "as good" | 09:45 |
| tjaalton | foss stack is much better in some areas | 09:46 |
| LocutusOfBorg | so tjaalton this change has no effect on ubuntu? https://packages.qa.debian.org/x/xorg-server/news/20150821T010032Z.html | 09:46 |
| seb128 | dunno, start a good recent games and get as many fps | 09:46 |
| tjaalton | there will be a GL blob for that | 09:46 |
| pitti | power management is an important point too | 09:46 |
| LocutusOfBorg | I mean the xorg-legacy package | 09:46 |
| tjaalton | yeah tseliot is backporting a lot for amdgpu kernel driver, including power management.. will be in 4.4.0-11 or such | 09:46 |
| seb128 | k, so there still are going to be binary parts shipped by amd? | 09:46 |
| tjaalton | at some point | 09:46 |
| tjaalton | LocutusOfBorg: no, nvidia does pull it in though, so once lightdm does support rootless, nvidia would still work | 09:47 |
| tjaalton | or gdm | 09:47 |
| tjaalton | seb128: amdgpu performance is quite close to fglrx though | 09:48 |
| seb128 | cool | 09:48 |
| tjaalton | and mesa 11.2 has a FFE | 09:48 |
| seb128 | tjaalton, I guess we should have something in the 16.04 notes | 09:48 |
| tjaalton | so I guess we'll be in a good position with 16.04, just have to be a bit aggressive.. | 09:48 |
| seb128 | and maybe an email on ubuntu-devel | 09:48 |
| tjaalton | yeah | 09:49 |
| seb128 | because usersa re going to wonder where is their fglrx drivers | 09:49 |
| seb128 | even if they don't need it, if we don't explain why it's missing it's going to create confusion | 09:49 |
| tjaalton | sure | 09:49 |
| tjaalton | the transition is still blocked by two MIR's | 09:50 |
| tjaalton | new deps on s390x & arm | 09:50 |
| tjaalton | (drivers) | 09:50 |
| tjaalton | hmm or was it the virtualbox tests, xorg meta package is probably separate | 09:50 |
| smb | tjaalton, dunno, I'd be somewhat surprised to find s390x blocking something graphical... | 09:52 |
| ogra_ | pitti, fyi bug 1553110 | 09:52 |
| ubottu | bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110 | 09:52 |
| ogra_ | infinity, ^^^ you might be interested | 09:52 |
| tjaalton | smb: it's the addition of xserver-xorg-input-void to x-x-input-all on s390x | 09:52 |
| pitti | ogra_: wow | 09:52 |
| smb | tjaalton, ah ok. yeah "void" describes the graphical experience there... | 09:53 |
| pitti | tseliot: autopkgtest fix pushed, but I don't upload yet as the cleanup should be done too | 09:53 |
| tjaalton | another option is to just drop it, but arm probably still wants -freedreno in main | 09:53 |
| pitti | tsdgeos: xserver-xorg-input-mouse | 09:55 |
| pitti | erk | 09:55 |
| pitti | tsdgeos: sorry, wrong ping | 09:55 |
| pitti | tjaalton: xserver-xorg-input-mouse | 09:55 |
| tjaalton | can be removed | 09:55 |
| pitti | tjaalton: ... wants to go to universe, can you confirm? | 09:55 |
| pitti | replaced by -evdev I suppose | 09:55 |
| tjaalton | like others on https://bugs.launchpad.net/ubuntu/+source/fglrx-installer-updates/+bug/1541369 | 09:56 |
| ubottu | Launchpad bug 1541369 in xserver-xorg-video-s3 (Ubuntu) "remove stale xorg drivers from the archive" [Wishlist,New] | 09:56 |
| pitti | tjaalton: ah, thanks; will do now | 09:56 |
| pitti | tjaalton: will they be removed in debian too, or is that ubuntu specific somehow? | 09:56 |
| tjaalton | vmmouse used to depend on -mouse, but that dep was actually removed upstream six years ago | 09:56 |
| tjaalton | gone from debian already | 09:56 |
| tjaalton | not mouse, since it had the dependency not too long ago | 09:57 |
| tjaalton | yeah we've used -evdev for years, and next up will be -libinput | 09:57 |
| pitti | -keyboard is also still in debian | 09:57 |
| tjaalton | hmm | 09:57 |
| tjaalton | I'll check | 09:57 |
| tjaalton | because they have kfreebsd | 09:58 |
| tjaalton | actually mouse for the same reason | 09:58 |
| tjaalton | but we don't have !linux | 09:59 |
| pitti | ah | 09:59 |
| pitti | *zap* | 09:59 |
| tseliot | pitti: define clean-up please? | 10:00 |
| pitti | tseliot: git grep fglrx | 10:00 |
| tseliot | seb128: do we have a draft of the release notes? If so, I can write a few lines about it | 10:01 |
| pitti | tseliot, tjaalton: actually, what happens on upgrades of systems that have fglrx currently installed? does ubuntu-drivers set an xorg.conf which forces the driver, or does it just configure it and retains auto-detection? | 10:01 |
| tjaalton | good point | 10:01 |
| pitti | gpu-manager does quite a bit on such systems (I have no idea what exactly, though) | 10:01 |
| seb128 | tseliot, I don't know, I would expect that be a section on the wiki that is updated during the cycle ... let me find it | 10:02 |
| tseliot | pitti: when users upgrade to the new X, fglrx will be removed, gpu-manager will detect that, and remove the xorg.conf | 10:02 |
| tjaalton | oh | 10:02 |
| pitti | ah, good | 10:02 |
| pitti | tseliot: so I suppose some gpu-manager code for fglrx will still be necessary, just not all of it (the setup part) | 10:02 |
| LocutusOfBorg | thanks tjaalton | 10:03 |
| tseliot | pitti: yes, I'd rather not remove that code yet, as it would make backports to previous Ubuntu releases harder than they need to be | 10:03 |
| pitti | tseliot: ah, ok; then I guess I should keep the fglrx support in UbuntuDrivers/detect.py as well for the time being | 10:04 |
| pitti | tseliot: good, then I'll upload this to fix the tests | 10:04 |
| pitti | tseliot: unless you still have something? | 10:04 |
| tseliot | pitti: yes, please, let's keep the code there for now. I have nothing to upload ATM | 10:06 |
| pitti | apw: OOI, what happened to the seeding of the linux-meta packages? | 10:06 |
| tseliot | pitti: BTW, if you could approve my nvidia packages in Xenial NEW, that would be very welcome ;) | 10:06 |
| seb128 | tseliot, I don't find a wikipage :-/ | 10:07 |
| seb128 | Laney, do you know if there is already a wikipage somewhere for release notes? | 10:08 |
| seb128 | I though we had one through the cycle | 10:08 |
| seb128 | adding infos during alpha/beta/etc | 10:08 |
| seb128 | but I can't find it | 10:08 |
| apw | pitti, i thought we were making that use a * thing, and i actually thought you'd already done it:) | 10:09 |
| Laney | seb128: not one that I know of - probably one will be created for Beta 2 though | 10:09 |
| seb128 | tseliot, ^ I guess need to wait a bit then | 10:09 |
| seb128 | Laney, thanks | 10:09 |
| pitti | apw: no, I understood it like you were going to double-check and update the seeds, but they are still on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; misunderstanding? | 10:09 |
| Laney | seb128: IIRC the ubuntu-release-notes project is for this | 10:09 |
| Laney | or someone could start the page I suppose | 10:10 |
| tseliot | seb128: ok, I'll be waiting for that then | 10:10 |
| Laney | XenialXerus/ReleaseNotes | 10:10 |
| seb128 | tseliot, or create the page | 10:10 |
| pitti | tseliot: no nvidia stuff in https://launchpad.net/ubuntu/xenial/+queue?queue_state=0 | 10:10 |
| Laney | tseliot: I would create it now so that nobody forgets | 10:11 |
| pitti | tseliot: nevermind, saw it now, scrolled off | 10:12 |
| tseliot | Laney, seb128: err... https://wiki.ubuntu.com/XenialXerus/ReleaseNotes | 10:14 |
| seb128 | tseliot, yeah, I think that Laney was just hitting the url and suggesting creating it | 10:15 |
| tseliot | no need for me to create it then :) | 10:15 |
| seb128 | ? | 10:16 |
| seb128 | it doesn't exist yet | 10:16 |
| pitti | cit does | 10:16 |
| pitti | just still for wily | 10:16 |
| Laney | tseliot: I just made it | 10:17 |
| Laney | you can go fill in your section now | 10:18 |
| tseliot | Laney: yep, thanks | 10:18 |
| === marcusto_ is now known as marcustomlinson\ | ||
| === marcustomlinson\ is now known as marcustomlinson | ||
| oSoMoN | Mirv, I’m looking into bug #1342031 (for webbrowser-app), and I have a doc package named qtdeclarative5-ubuntu-web-plugin-doc, should that one be renamed too, and if so do I add a transitional dummy package? | 10:27 |
| ubottu | bug 1342031 in unity-action-api (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Medium,Triaged] https://launchpad.net/bugs/1342031 | 10:27 |
| tseliot | pitti: thanks a lot! | 10:30 |
| oSoMoN | Mirv, note that qtdeclarative5-ubuntu-web-plugin-doc doesn’t have any rdepends, it looks safe to not make a transitional dummy package for it | 10:44 |
| Mirv | oSoMoN: yes to both | 10:44 |
| oSoMoN | Mirv, even considering the above? | 10:44 |
| Mirv | oSoMoN: still, for people who have it currently installed to get the new one | 10:44 |
| oSoMoN | ok, got it | 10:44 |
| Mirv | oSoMoN: and thanks for the MIR, looks good! | 10:45 |
| oSoMoN | Mirv, what section does the -doc dummy package belong to? doc, or oldlibs? | 10:45 |
| Mirv | oSoMoN: that's an excellent question, I think I've seen that used, maybe because there is no other "old*" section. anyone on the channel with better knowledge please enlighten. | 10:47 |
| oSoMoN | Mirv, according to https://wiki.debian.org/Renaming_a_Package, setting the section to oldlibs allows tools like deborphan to suggest removal of the package once there aren't any more reverse-dependencies installed | 10:49 |
| Mirv | oSoMoN: right, the only thing I haven't seen explicitly said is "please use oldlibs section for all transitional packages", but I indeed have thought that is the case | 10:58 |
| Mirv | oSoMoN: thanks for starting that btw, we can get rid of more old names and transitional packages in 2 months then | 10:59 |
| Mirv | since there is upgrade path for 14.04 LTS -> 16.04 LTS upgraders | 10:59 |
| oSoMoN | Mirv, yeah, it had been on my backlog for a long time, I thought it’d be good to get it done in time for 16.04 | 11:00 |
| tseliot | seb128, Laney: ok, I've added a few lines about fglrx in the release notes | 11:07 |
| seb128 | tseliot, looks good, thanks! | 11:08 |
| jamespage | barry, hey - just tripped over an interesting niggle - pip includes a vendored pkg_resources (v19.4) which behaves a little differently to the pkg-resources in packages (20.1.1) | 11:42 |
| jamespage | barry, https://github.com/openstack/ceilometer/blob/master/ceilometer/tests/unit/meter/test_notifications.py#L274 works ok with 19.4, but not with 20.1.1 (always uses the full, not relative paths...) | 11:43 |
| jamespage | anyway I patched into ceilometer... | 11:43 |
| jamespage | I guess that would need to happen in pip itself otherwise xenial will have different pip to the rest of the world.... | 11:43 |
| oSoMoN | Mirv, https://code.launchpad.net/~osomon/webbrowser-app/qml-module-naming/+merge/288080 | 11:50 |
| === _salem is now known as salem_ | ||
| barry | jamespage: pip isn't supposed to contain any vendored packages. we strip out the _vendor directory | 14:11 |
| jamespage | barry, hmm where is that coming from then | 14:12 |
| * jamespage looks some more | 14:13 | |
| jamespage | barry, oh its quite possible that when tox creates the venvs, it installs pip from pypi which brings that in | 14:13 |
| * jamespage checks... | 14:13 | |
| barry | jamespage: also, just syncpackaged new version of pip to xenial. shouldn't change this bit of it, but just fyi | 14:13 |
| barry | jamespage: oh yeah, it'll do that if you don't tell tox otherwise! | 14:14 |
| jamespage | barry, my god this is confusing.,.. | 14:14 |
| jamespage | barry, I think that's what it is | 14:14 |
| barry | jamespage: you can set sitepackages=True and install the debs. also, i think there are ways to tell tox never to download from pypi. check the docs (something like setting the indexserver to the discard port on localhost) | 14:15 |
| barry | (that'll likely error out if you don't have a distro package installed) | 14:15 |
| jamespage | barry, indeed | 14:15 |
| xnox | barry, you are assuming i understood the structure i was dereferencing..... i tried combos until it worked ;-) | 15:08 |
| * xnox <3 TDD | 15:08 | |
| barry | xnox: tried and true method :) | 15:08 |
| Saviq | xnox, any idea about bug #1552914 ? | 15:12 |
| ubottu | bug 1552914 in boost-defaults (Ubuntu) "Can't install libboost-dev:armhf in a cross-build environment" [Undecided,New] https://launchpad.net/bugs/1552914 | 15:12 |
| xnox | Saviq, yes, doko broke things =) | 15:15 |
| oSoMoN | Mirv, https://code.launchpad.net/~osomon/webbrowser-app/qml-module-naming/+merge/288080 updated | 15:15 |
| Saviq | xnox, half a year ago and noone noticed? ;) | 15:15 |
| xnox | Saviq, i was not working on ubuntu half a year ago.... | 15:16 |
| Saviq | xnox, but you were working on it since! ;D | 15:16 |
| Saviq | canfix? ;) | 15:16 |
| barry | pitti: ree bug 814115 - thanks! it would really help for debugging failures | 15:17 |
| ubottu | bug 814115 in OpenQuake (deprecated) "Celery worker fails to send result message" [Critical,Fix released] https://launchpad.net/bugs/814115 | 15:17 |
| barry | debian bug 814115 | 15:17 |
| ubottu | Debian bug 814115 in autopkgtest "autopkgtest: $ADTTMP does not survive until --shell-fail/-s" [Normal,Open] http://bugs.debian.org/814115 | 15:17 |
| pitti | barry: yep, looking into it now | 15:17 |
| barry | \o/ | 15:17 |
| pitti | stgraber: what's the word on indicator-datetime pulling in obsolete deps? | 15:18 |
| pitti | barry: ok, got it :) | 15:30 |
| barry | pitti: awesome! | 15:32 |
| stgraber | pitti: no response from the merge proposal, I think I'll just upload it and they'll deal with merging things later | 15:37 |
| smoser | hey. | 15:56 |
| nacc | rbasak: thanks! wil merge today | 15:58 |
| nacc | pitti: thanks! | 15:58 |
| smoser | i have a stupid question. | 16:00 |
| smoser | file in debian/ gets installed by dh_install. debian/open-iscsi.install | 16:01 |
| smoser | what is the right way to ensure its installed executable ? | 16:03 |
| rbasak | Make sure it is executable to start off with? | 16:04 |
| smoser | is that right ? | 16:04 |
| rbasak | You can chmod it in d/rules if needed. | 16:04 |
| rbasak | (usually only if upstream have it wrong) | 16:04 |
| smoser | well its debian/ | 16:04 |
| smoser | so , its ours | 16:04 |
| rbasak | Ah. Is it a "3.0 (quilt)" source package? | 16:04 |
| smoser | no. its a file in debian/ | 16:04 |
| smoser | debian/iscsi-network-interface.rules => /lib/udev/rules.d/70-iscsi-network-interface.rules | 16:05 |
| rbasak | What does debian/source/format say? | 16:05 |
| smoser | quilt 3.0. but its dh_install from ^ | 16:05 |
| rbasak | Then you can mark it executable in the source package. | 16:05 |
| rbasak | And it should end up executable on the installed system. | 16:05 |
| smoser | yeah. that just felt brittle | 16:05 |
| nacc | smoser: does it not automatically? i'm reading the debian manual about it ... it probably doesn't hurt to mark it executable in the source | 16:05 |
| nacc | https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install | 16:06 |
| smoser | it does not do it automatically. | 16:06 |
| nacc | ok | 16:06 |
| xnox | smoser, debian.rules files should not be executable. | 16:06 |
| xnox | smoser, sorry, .rules files under debian. | 16:06 |
| cjwatson | If you're concerned about things not working otherwise then it's fine to override_dh_install | 16:06 |
| smoser | xnox, its not that style of rules. | 16:06 |
| nacc | it's a udev rule, right? | 16:06 |
| smoser | yeah. its a udev rule | 16:06 |
| nacc | namespace collision :) | 16:07 |
| xnox | smoser, i think then you want to e.g. | 16:07 |
| xnox | override_dh_installudev: | 16:07 |
| nacc | smoser: it seems "better" to override dh_install, but i'm not sure | 16:07 |
| xnox | dh_installudev | 16:07 |
| xnox | chmod +x debian/$pkg/lib/udev/rules.d/*.rules # or some such | 16:08 |
| nacc | smoser: rather than assuing te permissions in the tarball are maintained, etc | 16:08 |
| rbasak | I prefer to keep the permission in one place and think the source package chmod is fine. That keeps d/rules smaller, which I prefer. | 16:08 |
| nacc | heh | 16:08 |
| xnox | nacc, i think dh_installudev will strip the permissions anyway, and/or dh_fixperms thing. | 16:08 |
| rbasak | But no harm in doing it explicitly in the rules file. | 16:08 |
| xnox | smoser, if dh_fixperms "reverts" the chmod+x you'll need to override that too, with e.g. dh_fixperms -X | 16:09 |
| nacc | xnox: yeah, that's what I guess I meant ... not sure what the other commands do to the file during install | 16:09 |
| rbasak | If dh_fixperms reverts it, then maybe worth looking into why you need it that way? | 16:09 |
| nacc | also fair :) | 16:09 |
| rbasak | BTW, while we're asking this sort of question... | 16:09 |
| xnox | smoser, usually people place "binaries" into /lib/udev and just rules in the rules.d directory.... | 16:10 |
| nacc | I didn't think udev.rules needed to be exec | 16:10 |
| xnox | smoser, but i know that you are not a "usual" person. | 16:10 |
| smoser | bah | 16:10 |
| smoser | sorry | 16:10 |
| smoser | fail | 16:10 |
| nacc | none of them are exec on my system, at least | 16:10 |
| smoser | debian/net-interface-handler /lib/open-iscsi | 16:10 |
| smoser | that one is the file | 16:10 |
| nacc | ah | 16:10 |
| rbasak | I'd like to use dh_install --fail-missing to manage a complex package (mysql). But then how do I maintain a list of excludes? With -X, or is there a better way for a larger list? | 16:11 |
| rbasak | And, why is dh_install --fail-missing complaining about manpages installed using dh_installman and specified in a .manpages file, and is it right to have to exclude those specifically or is there something else that should be going on? | 16:11 |
| cjwatson | dh_install doesn't have a built-in way to maintain more excludes, but you could always generate the options using shell command substitution. | 16:12 |
| rbasak | cjwatson: that's a good idea. I just wanted to check that there wasn't some better way I was missing. Thanks! | 16:12 |
| nacc | rbasak: is that dh_install complaining or dh_installman | 16:19 |
| smoser | rbasak, so http://paste.ubuntu.com/15281670/ look ok ? | 16:21 |
| smoser | i also chmod 755 on the file, but that does not show up in debdiff (which is kind of why i find it brittle) | 16:21 |
| rbasak | nacc: dh_install complaining using --fail-missing about manpages installed by dh_installman (not sure what order but the dh sequencer order) | 16:23 |
| rbasak | smoser: IMHO, it's debdiffs that are brittle! | 16:23 |
| rbasak | git manages it fine. | 16:23 |
| smoser | well, yes. | 16:23 |
| rbasak | $(CURDIR)/ is a little redundant but I guess that pattern comes from Debian and you didn't want to deviate? Assuming that works, it looks fine. | 16:24 |
| smoser | yeah, the ones above use CURDIR | 16:24 |
| rbasak | s/needs to be/is/ if you like. | 16:25 |
| rbasak | And if you want me to be really pedantic, you're adding an unnecessary blank line in line 24 :-P | 16:25 |
| smoser | cyphermox, http://paste.ubuntu.com/15281670/ | 16:25 |
| smoser | indeed i am. | 16:25 |
| nacc | rbasak: hrm, that seems odd ... does that mean you're specifying the manpage to be installed then? (I don't know what the dh_install line looks like) | 16:25 |
| smoser | i will dlean that. | 16:25 |
| rbasak | nacc: https://git.launchpad.net/~racb/ubuntu/+source/mysql-5.7/tree/debian/mysql-server-5.7.manpages?h=5.7v3_pre2 is what dh_installman picks up | 16:27 |
| rbasak | nacc: but then dh_install --fail-missing (if we switch to that in d/rules) complains about all those manpages again. | 16:27 |
| rbasak | (I'm told) | 16:27 |
| nacc | rbasak: hrm, interesting -- that doesn't seem like it should be on my reading ofthe manapges, but you certainly know more than I do :) | 16:30 |
| rbasak | nacc: I only know as much as the manpages :) | 16:31 |
| rbasak | Thanks for looking. I could file a bug at some point I guess. | 16:31 |
| nacc | rbasak: :) it seems like it might be an ordering thing, but it's hard to say, and given you do have a workaroudn presuming it's an issue | 16:34 |
| rbasak | nacc: yeah we can just use dh_install --fail-missing -X ... | 16:49 |
| mitya57 | cjwatson, rbasak: I think modern debhelper versions can read list of excluded files from debian/not-installed | 17:00 |
| mitya57 | ≥ 9.20151004 according to the changelog | 17:00 |
| mitya57 | (never tried that myself) | 17:00 |
| rbasak | mitya57: ah, neat! Thanks. Any idea where that is documented? Google doesn't find anything. | 17:00 |
| mitya57 | It's documented in dh_install(1) here | 17:01 |
| rbasak | Thanks again! | 17:01 |
| nacc | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436240 | 17:02 |
| ubottu | Debian bug 436240 in debhelper "debhelper: exclude file for dh_install --list-missing" [Wishlist,Fixed] | 17:02 |
| mitya57 | Yw! | 17:02 |
| rbasak | http://manpages.ubuntu.com/manpages/xenial/en/man1/dh_install.1.html has it | 17:02 |
| rbasak | Skuggen: ^^ | 17:02 |
| xnox | in moinmoin how do i type CamelCase word without it generating a link to CamelCase page? | 17:02 |
| nacc | rbasak: and seems to be referring to exactly your issue in one of the comments :) | 17:02 |
| Skuggen | Ah, nice | 17:03 |
| mitya57 | xnox, try an exclamation sign, i.e. !CamelCase | 17:04 |
| xnox | mitya57, thanks! | 17:04 |
| mitya57 | that was from https://moinmo.in/HelpOnLinking#Preventing_Automatically_Generated_Links | 17:06 |
| cjwatson | mitya57: So it does! Not sure how I missed that. | 17:09 |
| mterry | seb128, hello! Is a11y-profile-manager a package the desktop team is OK with owning / subscribing to? (in the context of MIR bug 1552507) | 17:12 |
| ubottu | bug 1552507 in a11y-profile-manager (Ubuntu) "[MIR/FFE] Promoting a11y-profile-manager to main." [Undecided,Incomplete] https://launchpad.net/bugs/1552507 | 17:12 |
| infinity | ogra_: Commented. | 18:27 |
| ogra_ | infinity, i'm batteling other issues too here ... | 18:27 |
| ogra_ | OOOH ! | 18:28 |
| ogra_ | lol | 18:28 |
| ogra_ | infinity, my other issue is that despite linbudev being in that ldd output, i dont end up with it inside the initrd | 18:28 |
| infinity | ogra_: Curious. Is that also unique to running under fakechroot? | 18:29 |
| ogra_ | definitely, since normal built initrds used to work | 18:29 |
| * infinity nods. | 18:29 | |
| ogra_ | other hooks all get their libs just fine too | 18:30 |
| infinity | ogra_: Of course, you say that copy_exec fail because of the ld.so issue. It's possibly it's aborting before getting to libudev. | 18:33 |
| infinity | s/fail/fails/ | 18:33 |
| ogra_ | well, my outer build script now has a mkdir /lib64 and i copy the linker there | 18:33 |
| infinity | Oh. Gross. ;) | 18:33 |
| ogra_ | so mkinitramfs moves on without error | 18:33 |
| infinity | Right. Hrm. | 18:33 |
| ogra_ | yeah ... i have worse hacks in the making currently though :P | 18:34 |
| infinity | If you didn't, it wouldn't be you. | 18:34 |
| ogra_ | (all stuff i hope to drop once fakechroot works again :) | 18:34 |
| infinity | The best part about that ldd wrapper is that it fails to do the one useful thing that a wrapper SHOULD do in that situation (filter out libfakechroot!) | 18:36 |
| ogra_ | yeah, totally | 18:36 |
| ogra_ | root@localhost:/# grep touch initramfs-tools-ubuntu-core-0.7.28/build-initrd.sh .... touch $ROOT/usr/lib/$DEB_HOST_MULTIARCH/fakechroot/libfakechroot.so | 18:37 |
| ogra_ | touch $ROOT/usr/lib/$DEB_HOST_MULTIARCH/libfakeroot/libfakeroot-sysv.so | 18:37 |
| ogra_ | works but makes a lot of noise about "library to short" in the build logs ... | 18:37 |
| ogra_ | hmm, so now i have an initrd with libudev ... but my hack to add it actually spilled errors ... that doesnt really help :P | 18:39 |
| * ogra_ starts over without the hack ... perhaps i'm hllucinating now ... it shouldnt be there | 18:39 | |
| ogra_ | building again ... perhaps that libudev thing was a red herring | 18:48 |
| * zyga hugs ogra_ and initrd hacking | 18:51 | |
| zyga | how come other OSes don't have initrds :P | 18:51 |
| ogra_ | they are not as cool | 18:52 |
| ogra_ | zyga, usually i dont need to hack actually ... if the tools work :) | 18:53 |
| ogra_ | wow, so with my linker hack libudev actually ends up where it should ... now thats weird | 19:02 |
| ogra_ | argh ! | 19:15 |
| ogra_ | initramfs-tools-ubuntu-core_0.7.29_source.changes | 19:15 |
| ogra_ | err | 19:15 |
| ogra_ | /usr/share/initramfs-tools/hooks/zz-fix-arm64-linker ignored: not executable | 19:15 |
| ogra_ | ogra@styx:~/Arbeitsfläche$ abootimg-unpack-initrd initrd.img-core-0.7.30 | 19:26 |
| ogra_ | 10730 Blöcke | 19:26 |
| ogra_ | ogra@styx:~/Arbeitsfläche$ ls ramdisk/lib/aarch64-linux-gnu/|grep udev | 19:26 |
| ogra_ | ogra@styx:~/Arbeitsfläche$ | 19:26 |
| ogra_ | WTF ! | 19:26 |
| ogra_ | why does it work if i run the build script in a chroot but not on the buildd | 19:26 |
| ogra_ | i clearly have libudev in my local build | 19:27 |
| === ejat_ is now known as ejat | ||
| nacc | rbasak: sent a merge requst for logwatch to get us up to 7.4.2-1 | 19:53 |
| === pepee- is now known as pepee | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!