=== ezri is now known as rww | ||
doko | meh, just molds built. anything else fails on powerpc | 00:00 |
---|---|---|
nacc | slangasek: ok, i think i updated all the debdiffs | 00:12 |
nacc | slangasek: also posted a v3 of my sequence | 00:13 |
=== salem_ is now known as _salem | ||
=== balloons16 is now known as balloons | ||
sarnold | slangasek,cyphermox, 1544809 is currently filed against 'linux' but grub or grub2 may be more appropriate | 02:22 |
cyphermox | ack reassigning to grub2... I'll look tomorrow | 02:33 |
sarnold | thanks cyphermox :) | 02:33 |
happyaron | bdmurray: the open-gram upload is for LP: #1361764 | 02:55 |
ubottu | Launchpad bug 1361764 in open-gram (Ubuntu Trusty) "Update sunpinyin-data to >=20130220" [Medium,In progress] https://launchpad.net/bugs/1361764 | 02:55 |
PovAddict | who do I contact regarding blatant misuse of the ubuntu logo? | 04:01 |
PovAddict | https://twitter.com/actoresargok | 04:01 |
sarnold | wow | 04:02 |
sarnold | that's not even close to right ;) | 04:02 |
PovAddict | they have absolutely nothing to do with software, they found something that looked nice and slapped it there | 04:02 |
PovAddict | they even put it on all photos they upload, so it's not just a matter of changing the twitter profile picture | 04:04 |
slangasek | lolwut | 04:04 |
slangasek | I think there's a contact address for Canonical Legal you can use to report this | 04:04 |
slangasek | though fwiw, trademark law in most countries limits trademarks by field of endeavor; so /because/ it's not for software, it probably doesn't infringe Canonical's trademark | 04:05 |
slangasek | PovAddict: http://www.ubuntu.com/legal/terms-and-policies/contact-us | 04:05 |
slangasek | ok that's meant to be requests to use the trademark instead of requests to enforce the trademark, but I think it'll get to the right people ;) | 04:06 |
PovAddict | could still be a copyright violation if they didn't draw the logo from scratch | 04:07 |
tumbleweed | looks like they've been misusing it for a few years (based on the vintage of that ubuntu logo) | 04:08 |
PovAddict | tumbleweed: or what their random logo search found happened to be old? | 04:08 |
tumbleweed | yeah, or that | 04:09 |
PovAddict | "Are you making the request on behalf of a company?" "No" and then the company website and street are required fields, wonderful | 04:10 |
sarnold | haha | 04:10 |
slangasek | PovAddict: how would it be a copyright infringement when the logos are under a free license? | 04:10 |
PovAddict | what license lets them get away without even attribution? | 04:11 |
slangasek | yes, perhaps there's an attribution problem | 04:11 |
sarnold | I'll mail the lawyers, i can't find them on irc (go figure..) | 04:11 |
PovAddict | just sent the form | 04:12 |
sarnold | ah, thanks PovAddict, then i'll skip the email :) | 04:12 |
kirkland | doko: thanks for the heads up; I think (hope?) I just uploaded the right fix | 04:27 |
pitti | Good morning | 06:18 |
ginggs | doko: well done! getdp failed because petsc hasn't built yet, which others did you try with -Og ? pochu add some info to the bug, could be a PPC970FX vs POWER7/8 thing | 06:30 |
highvoltage | 9/win 27 | 06:31 |
=== ljp is now known as lpotter | ||
dholbach | good morning | 08:16 |
slangasek | nacc: sorry, I've just now had a chance to look at your guide. what's not clear to me in this is what the sequence points are. I don't want to be building one package at a time, waiting for completion before starting on the next; I want to be able to throw these packages out there in parallel as much as possible. Do you have this kind of information available? | 08:23 |
doko | ginggs, <doko> meh, just molds built. anything else fails on powerpc | 08:55 |
doko | liggghts built on a porter box | 08:56 |
ginggs | doko: anything special about that porterbox? BTW i did try petsc 3.6.3 but not change. I did get petsc 3.6.2 to build by patching the tests to only run on one process (but that's defeating the point of MPI) | 09:09 |
doko | ginggs, it's a POWER7+ machine, running qemu | 09:11 |
ginggs | I did find this issue upstream that sounded vaguely similar https://github.com/open-mpi/ompi/issues/874 | 09:13 |
ginggs | endianness, -np 1 works, -np 2 fails - but apparently those patches have been included (and i can't even find those files) | 09:13 |
doko | the test cases really should be turned on in the openmpi package itself | 09:16 |
ginggs | doko: i think they are | 09:17 |
ginggs | at least it says so in the changelog for 1.10.2-6 | 09:18 |
doko | ginggs, hmm, the files in the patch don't exist :-/ | 09:21 |
opny | hello, I would like to run xenial armhf on qemu. Do you think is feasible? | 09:26 |
doko | kirkland, I hope you saw the build failure yourself this time ;p | 09:29 |
ginggs | doko: btw should https://launchpadlibrarian.net/237705769/vtk6_6.2.0+dfsg1-7ubuntu1_6.2.0+dfsg1-7ubuntu2.diff.gz go to debian? | 09:37 |
doko | ginggs, wouldn't hurt, I assume | 09:42 |
ginggs | ok, i'll forward it, gladk's going to include our other delta as well | 09:44 |
doko | pitti, http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/amd64/ looks like a valid test results is superseded by an invalid one ... | 10:00 |
doko | sil2100, ^^^ | 10:00 |
sil2100 | doko: yeah, I actually re-ran those in the morning, I see 2 of them still fail | 10:01 |
doko | hmm, looks like some autopkg test results are not picked up since midnight | 10:06 |
Laney | doko: what's the actual problem? | 10:07 |
doko | sil2100, no wonder if the tests are run with the wrong versions... I'm wondering where pitti even gets this version from | 10:07 |
Laney | Tests try to minimise their use of proposed | 10:07 |
Laney | the order of things on autopkgtest.u.c doesn't really matter, britney doesn't just take the latest | 10:08 |
rbasak | caribou: o/ | 10:10 |
caribou | rbasak: o/ | 10:10 |
caribou | rbasak: so I rebuilt a new repo starting from the original merged version | 10:11 |
rbasak | So for when Ubuntu pull in a new upstream, I'm breaking down the logical commit as follows. For each Ubuntu upload, there will be one commit that pulls in the new upstream, but no changes in debian/*, and subsequent commits only change debian/* | 10:11 |
rbasak | Then one commit per logical change, which is generally one per changelog entry but a little subjective. | 10:11 |
rbasak | That should be it. | 10:12 |
rbasak | Before I get there the reconstruct stage additionally has one commit for all of debian/changelog changes per upload, and potentially another commit for update-maintaner/ubuntu-meta. | 10:12 |
rbasak | Sorry, that's really the reconstruct. | 10:12 |
rbasak | The logical then drops the upstream changes, changelog and ubuntu-meta. | 10:13 |
rbasak | So you end up with logical only changing things in debian/* that are logical parts of the Ubuntu delta, so excluding upstream changes and meta-changes in debian/changelog, update-maintainer, etc. | 10:13 |
doko | Laney, well, for a transition, this assumption is wrong | 10:15 |
rbasak | caribou: here's a summary I wrote yesterday, but haven't finalised yet: http://paste.ubuntu.com/15023270/ | 10:16 |
doko | Laney, http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/i386/ shows a successful test, which is overridden by a bad one | 10:16 |
Laney | it is not overridden | 10:16 |
Laney | you need to look on excuses | 10:16 |
doko | Laney, I did, libjsoncpp still lists these as fail | 10:19 |
pitti | doko: WDYM with "invalid version"? 0.1.1+16.04.20160210-0ubuntu1 is -proposed | 10:23 |
Laney | I think I retried those with the new -scope-click now | 10:23 |
rbasak | caribou: minor updates in http://paste.ubuntu.com/15023288/ - I clarified logical/<version> wrt. your new upstream case. | 10:23 |
Laney | pitti: It's a transition but retried with the non rebuilt -scope-click I think | 10:24 |
caribou | rbasak: looking | 10:24 |
pitti | Laney: ah, that again -- they don't have versioned Depends:, thus they need the old "rerun with both triggers" trick again? | 10:24 |
Laney | well they have Depends on the old and new versioned packages | 10:24 |
caribou | rbasak: so basically, when a new upstream is merged in as an ubuntu delta (my 0.98-7 case), you would lump all of the 'upstream' changes in one commit & the debian specific things in other logical commits ? | 10:28 |
rbasak | caribou: right. And then for the "logical", I drop the commit containing all of the upstream changes. | 10:28 |
caribou | rbasak: ah ok, got it. I'll rebuid my git repo according to this (mostly done) & will resubmit | 10:29 |
rbasak | Since when later rebasing, the upstream changes will be present anyway, since we'll always be rebasing onto a newer upstream. | 10:29 |
rbasak | caribou: OK. Thanks! | 10:29 |
Saviq | pitti, hey, got two Qs about silo 51 excuses; 1: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html (just updated a few minutes ago) says "in progress" for a lot of items, but running.html shows none of them... 2: https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-051/excuses.html has ♻ for qtmir-gles that tell sil2100 that it has no tests, so can't re-run ¿? | 10:30 |
pitti | Saviq: hm, I had to kill ppc64el runs this morning as the lcoud was broken again | 10:40 |
pitti | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-051?format=plain does have a qtmir result from this morning, though | 10:40 |
pitti | Saviq: for 2. indeed http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/ does not yet have any results for vivid | 10:43 |
pitti | Saviq: we currently check that to determine whether a package name is valid and has tests, to fend off invalid retries | 10:44 |
pitti | (we need to be rather strict there as this quickly becomes a resource DoS) | 10:44 |
pitti | Saviq: can you please file a bug report about that, with a summary of that (against auto-package-testing) | 10:44 |
Saviq | pitti, ok, thanks | 10:44 |
pitti | I need to think about how we can allow that without openign the floodgates | 10:44 |
pitti | Saviq: I'll retry the tests in the meantime | 10:45 |
Saviq | pitti, thank you | 10:45 |
pitti | does anyone else than robru have access to the production CI train? | 10:45 |
pitti | would be much easier to rm pending.json for that xenial silo than crafting the retry commands by hand | 10:46 |
Mirv | I don't think sil2100 has either the access | 10:46 |
Mirv | I don't at least | 10:46 |
Saviq | pitti, I could toggle the lander ack there, that (I *think*) would retry the whole suite? | 10:47 |
pitti | vivid retried | 10:48 |
Saviq | pitti, bug #1544917 | 10:50 |
ubottu | bug 1544917 in Auto Package Testing "Retry says "does not have any test results" on reported Regressions" [Undecided,New] https://launchpad.net/bugs/1544917 | 10:50 |
pitti | Saviq: thanks, updated | 10:52 |
pitti | robru (CC: Saviq): Can you please remove pending.json for this silo? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html | 10:54 |
pitti | to get the tests re-ran? | 10:54 |
pitti | run | 10:54 |
robru | pitti: nope you need webops | 10:54 |
pitti | (scalingstack glitch this morning, sorry) | 10:54 |
robru | pitti: would be like /tmp/britney_data/landing-051-xenial/autopkgtests/pending.json or so | 10:56 |
pitti | robru: what does "webops" translate to? | 10:58 |
robru | pitti: talk to the vanguard in #webops | 10:58 |
Saviq | pitti, re: qtmir-gles - it has tests since October, and somehow britney has decided that it was a regression, so ¿? | 11:02 |
pitti | Saviq: within the silo, yes, but apparently it never ran in Ubuntu in vivid? | 11:03 |
pitti | Saviq: xenial-051 sohuld now retry the missing tests on the next run | 11:03 |
Saviq | pitti, hmm right, that makes sense | 11:04 |
LocutusOfBorg | ginggs, I syncd scalapack and blacs-mpi from Debian | 11:11 |
LocutusOfBorg | mapreri fixed all the delta there | 11:12 |
ginggs | LocutusOfBorg: thanks | 11:12 |
LocutusOfBorg | just a little change has been left out (adding fort to the linker flags), because he is pretty sure the fix has been in another package (pkg-config wasn't giving all the flags) | 11:12 |
LocutusOfBorg | so that delta has been removed | 11:12 |
LocutusOfBorg | don't remember where, but in a package I remember I syncd yesterday | 11:14 |
LocutusOfBorg | let me know if I broke anything, and I'll bother mapreri to fix it :) | 11:19 |
LocutusOfBorg | actually I think powerpc is the most important problem | 11:20 |
=== _salem is now known as salem_ | ||
caribou | doko: remember the reason why clamav was 'forced' to use LLVM 3.5 ? | 11:47 |
doko | caribou, because it needs porting? | 11:50 |
caribou | doko: yeah, I get clamav build failures with 3.7 & 3.8 | 11:50 |
doko | caribou, yes, the server team told me that they will port it | 11:53 |
doko | rbasak, ^^^ | 11:53 |
caribou | doko: hmm, that means me | 11:53 |
doko | caribou, forwarding you email | 11:53 |
caribou | doko: thanks | 11:54 |
doko | caribou, you might ask ScottK; he once cared about clamav | 11:59 |
LocutusOfBorg | caribou, according to debian logs it should build fine with 3.6 | 12:14 |
caribou | LocutusOfBorg: yes, that's what they build with | 12:16 |
rbasak | doko: when did we say that? Or did you just ask us to port it? | 12:26 |
doko | rbasak, see email | 12:28 |
ScottK | caribou: Every single llvm update seems to need a new patch for clamav. | 12:30 |
ScottK | rbasak: If you are going to port it, you also really want to update to 0.99 first. | 12:31 |
ScottK | Please send us (Debian) the patch if you come up with something. | 12:31 |
pitti | Mirv: vivid is ok now (except for the unity8 NBS), xenial re-ran and now just has one regression | 12:34 |
ricotz | hello developers | 12:35 |
ricotz | doko, hi, please don't forget aptitude | 12:35 |
caribou | ScottK: porting would be part of the 0.99 merge | 12:40 |
ScottK | OK. | 12:40 |
caribou | ScottK: right now, it doesn't like the fact that I'm using 3.8 (testing for 3.7) | 12:40 |
caribou | ScottK: configure complaining | 12:41 |
ScottK | I'm sure it doesn't. The only reason it works with 3.6 is a Debian patch. | 12:41 |
ScottK | I'm sure it'll need additional something for newer. | 12:41 |
caribou | ScottK: ok, I'll look at what was done on the debian side | 12:42 |
doko | ricotz, would like to wait until apt gets in | 12:43 |
ScottK | Specifically debian/patches/add-LLVM-3.6-support.patch | 12:43 |
Mirv | pitti: you mean Saviq? | 12:43 |
pitti | Mirv: yes, I do, sorry :) | 12:43 |
Mirv | np :) | 12:43 |
ScottK | caribou: You can discuss what needs doing on pkg-clamav-devel@lists.alioth.debian.org. | 12:43 |
* ScottK isn't the right person to answer any details. | 12:43 | |
caribou | ScottK: ok, thanks | 12:43 |
cjwatson | pitti: could you add an "easy click/0.4.43+16.04.20160203-0ubuntu2 python-click/6.2-2ubuntu1" hint for me? it's not going to work yet because of reverse dependencies, but those two will eventually need to go in together | 12:44 |
ricotz | doko, alright | 12:44 |
cjwatson | pitti: (renaming python3-click -> python3-click-package and also python{,3}-click-cli -> python{,3}-click) | 12:44 |
Mirv | Saviq: rerunning the one remaining failed at http://autopkgtest.ubuntu.com/running.shtml#pkg-qtmir | 12:45 |
Saviq | Mirv, thanks! | 12:45 |
Saviq | Mirv, we should be rid of these soon, hopefully | 12:46 |
Saviq | (flaky ones I mean) | 12:46 |
pitti | cjwatson: committed (without knowing what I'm doing :) ) | 12:47 |
cjwatson | heh, thanks | 12:48 |
rbasak | doko: thanks | 12:56 |
doko | rbasak, also saw that the merged ntp is dep-wait | 13:00 |
rbasak | doko: I emailed ubuntu-devel about that. I guess we'll MIR pps-tools. | 13:01 |
rbasak | caribou: can I suggest that you merge and build against llvm 3.6 for now, since that's the easiest path? Then we'll at least be further forward. | 13:05 |
caribou | rbasak: that was my idea | 13:05 |
rbasak | If we can fix in a later upload to use a newer llvm then we can do that separately, but that realistically sounds unlikely to me to happen before FF. | 13:06 |
rbasak | doko: ^ | 13:06 |
caribou | ScottK: the only delta left with debian then would be an override for armhf tests | 13:06 |
caribou | ScottK: would that be accepted in Debian ? | 13:06 |
seb128 | doko, slangasek, would foundation like to subscribe to fonttools bugs (bug #1538173)? graphite2 is depwaiting on it and you probably know better about fonts than us | 13:28 |
ubottu | bug 1538173 in fonttools (Ubuntu) "[MIR] fonttools" [Undecided,Incomplete] https://launchpad.net/bugs/1538173 | 13:28 |
cyphermox | good morning! | 13:40 |
seb128 | hey cyphermox, happy friday! | 13:41 |
cyphermox | hey, you too | 13:41 |
=== cherylj_ is now known as cherylj | ||
ginggs | doko: are the powerpc openmpi builds working now? | 14:36 |
cjwatson | ginggs: https://launchpad.net/ubuntu/+source/aces3/3.0.8-5build2/+build/8974836 managed to pass, which is a good sign I guess | 14:39 |
doko | ginggs, cjwatson yes, this one and molds. the others still stuck, however there seems to be a bit more output | 14:44 |
doko | seb128, isn't font stuff desktopish? ;) | 14:44 |
seb128 | doko, I don't think so ;-) | 14:45 |
seb128 | you have fonts on command lines as well :p | 14:45 |
Mirv | mterry: LP chat is slow, would you want for me to consider another team for the foma or create a new team? | 14:49 |
ginggs | doko, cjwatson: weird, aces3 is one that failed on the debian buildds. aster, getdp and slepc all depend on petsc, so if we can shoehorn petsc in, it would be good | 14:50 |
mterry | Mirv, creating a new team seems like a hassle, is there another good team fit? It just seemed odd to have a team responsible that was really just you :) | 14:51 |
Mirv | mterry: I responded to the bug now once though, explaining how the team was the best fit of the existing teams I could think of - that is, it has at least two other active Ubuntu (technical) contributors that care about the package or the functionality it provides | 14:52 |
ginggs | this should make petsc build https://launchpadlibrarian.net/237387369/petsc_3.6.2.dfsg1-3_3.6.2.dfsg1-3ubuntu1~ppa1.diff.gz (it skips the 2 process test) | 14:52 |
ginggs | although the changelog entry is rubbish, i think we've established it isn't about ram | 14:53 |
mterry | Mirv, oh didn't read bug comment | 14:54 |
mterry | Mirv, that's fine then. I just wanted to raise the point. If you like that team, it's good enough for me | 14:55 |
Mirv | mterry: ok then. thank you for raising it, it's always good to ask. | 14:55 |
doko | ginggs, disable the tests on powerpc ;p | 14:56 |
ginggs | doko: this version worked on a porterbox, shall i just upload it and see what happens? | 14:57 |
doko | ginggs, how does it differ? | 14:58 |
ginggs | err look at the diff? what do you mean? | 14:59 |
doko | cjwatson, thanks for fixing the click mess =) | 15:00 |
cjwatson | doko: Rather belatedly :) | 15:01 |
cjwatson | I think it's mostly out of the way now but will probably require an adjustment to the p-m hint. | 15:01 |
doko | pitti, python-numpy/pynfft is red, but the test is green | 15:15 |
ginggs | doko: just to be clear, shall i upload petsc with the 2 process test disable? it is ready to go | 15:16 |
doko | ginggs, but just disable it on powerpc. I fear at some point we'll have to remove the powerpc builds again | 15:17 |
doko | pitti, looks like adt doesn't understand "Test-Command" on it's own? see python-pywcs | 15:20 |
ginggs | doko: i can't think of an easy way to selectively apply a patch by arch. i did post a link to the diff if you scroll up a bit. this version i have tested on a porterbox, any big changes and i'd need to start from scratch | 15:22 |
doko | ginggs, repaste? | 15:24 |
ginggs | doko: [17:01:01] <ginggs> this should make petsc build https://launchpadlibrarian.net/237387369/petsc_3.6.2.dfsg1-3_3.6.2.dfsg1-3ubuntu1~ppa1.diff.gz (it skips the 2 process test) | 15:24 |
pitti | doko: pynfft> I'll try to re-run proposed nfft against proposed numpy | 15:30 |
doko | ginggs, is it really limited ram? | 15:31 |
GunnarHj | mapreri: Hi Mattia, any thoughts on my latest comment on bug #1510198? | 15:32 |
ubottu | bug 1510198 in libreoffice-dictionaries (Ubuntu) "Rebase/Reimplement Ubuntu changes upon Debian (possibly upstream them)" [Low,Triaged] https://launchpad.net/bugs/1510198 | 15:32 |
ginggs | doko: no no, i explained earlier the changelog entry is rubbish, it is fixed in the version ready to upload (along with removal of ~ppa from the version) | 15:32 |
doko | ginggs, then go ahead | 15:34 |
ginggs | doko: roger roger | 15:34 |
pitti | doko: adt does understand Test-Command:; but as the log says, python-pywcs does't have any tests in xenial-release | 15:36 |
pitti | that's indeed a nasty case which britney can't detect by herself, re-running | 15:37 |
caribou | rbasak: I can't push my new clamav git repo to the previous one, the tags will collide | 15:42 |
caribou | rbasak: want me to delete the previous one & recreate ? | 15:42 |
bdmurray | happyaron: I figured out what bug it fixes my point was the upload was generated incorrectly, probably not on Ubuntu, so there is not a Launchpad-Bugs-Fixed field in it. Subsequently, the SRU report won't link to the bug, tools won't comment on it and the LP janitor won't close it. | 15:46 |
nacc | slangasek: let me rewrite it in a better form for you! | 15:47 |
nacc | slangasek: i apologize, i'll break it up by where the sync points are | 15:48 |
rbasak | caribou: feel free to force push the tags. I would just do that. | 15:49 |
rbasak | caribou: it only matters to those following the tags, and that's just us right now. | 15:49 |
rbasak | Or if you like append .v2 onto the collided tags or something. | 15:49 |
nacc | slangasek: cjwatson: infinity: for the purposes of php5 -> php7, are you ok if i send a merge proposal to demote/promote appropriately in the seeds now (as opposed to once the bootstrap and side builds are done) (with an eventual bug to altogether remove php5* from the archive?) | 15:49 |
caribou | rbasak: want me to push it to a new branch ? or just force overwrite everything ? | 15:50 |
rbasak | caribou: you can force overwrite everything if that's easiest. | 15:50 |
caribou | rbasak: since I restarted from scratch | 15:50 |
nacc | rbasak: can you (i should have emailed, sorry!) put up git trees for numactl and logwatch (so i can send the former's merge request and eventually logwatch's)? | 15:50 |
rbasak | caribou: or just push to a new "repo". Anything you want :) | 15:50 |
caribou | rbasak: fine | 15:50 |
nacc | slangasek: also, i probably will need to update all the debdiffs to have the latest pkg-php-tools and php-pear versioned deps (to force the php7 versions) | 15:52 |
rbasak | nacc: sorry, I'll do that now. | 15:52 |
nacc | rbasak: no need to apologize! | 15:52 |
rbasak | nacc: I've done numactl, I think. Please could you check that my tags and branches match our current expectations? I've also documented what I think is our current status in https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION | 15:58 |
rbasak | I haven't imported the Ubuntu branches. I could, but I think it'd be easier if you did that. It won't matter that we won't have an official import/... tag for our process I think. | 15:59 |
nacc | rbasak: looks right to me | 16:05 |
caribou | rbasak: I pushed a new merge-v2 branch & updated the tags towards it | 16:10 |
rbasak | Argh, I just screwed it up. | 16:11 |
rbasak | Will fix in a moment. | 16:11 |
rbasak | (numactl) | 16:12 |
rbasak | nacc: numactl fixed, and I've pushed logwatch. I can't delete the master branch (as it's HEAD, and there's no protocol way for me to change that), but pretend it doesn't exist. | 16:23 |
rbasak | nacc: apart from that I updated logwatch to fit our workflow for merge number 2 - you should be able to rebase the old logical delta as expected. | 16:23 |
doko | pitti, openmpi/esys-particle: again, the version from testing is tested, not the fixed one in proposed. what's the rationale for testing with the release pocket first? | 16:26 |
doko | openmpi/liggghts the same | 16:26 |
doko | openmpi/lammps the same | 16:27 |
doko | I assume, just retrying won't help here | 16:28 |
doko | sil2100, please could you chase https://bugs.launchpad.net/ubuntu/+source/libgee/+bug/1502094 we really should that get fixed before the release. now having two versions ... | 16:35 |
ubottu | Launchpad bug 1502094 in unity-scope-home (Ubuntu) "libgee-0.8-dev should be used, libgee-dev will be removed from the archive" [Undecided,New] | 16:35 |
* rbasak figured out out to delete master | 16:37 | |
doko | sil2100, also https://bugs.launchpad.net/ubuntu/+source/unity-lens-video/+bug/1545078 | 16:58 |
ubottu | Launchpad bug 1545078 in unity-lens-video (Ubuntu) "unity-lens-video fails to build from source (using deprecated vala)" [Critical,Confirmed] | 16:58 |
rharper | it is considered bad form to leave an ADT test program (shell) with execution tracing on? when/if the test fails the log with the trace would be most useful to avoid having to run it again to debug the failure | 17:01 |
rharper | jderose: thanks! Nice write up | 17:04 |
sil2100 | doko: hmmm, thanks, let me pick that up | 17:04 |
doko | sil2100, attaching patches | 17:04 |
jderose | rharper: my pleasure, thanks again for the help! | 17:04 |
rbasak | rharper: I think it's good to leave it on. Similarly we try to do builds with (reasonable) verbosity on. | 17:05 |
rbasak | rharper: you may need "allow-stderr" defined on the test though. I don't remember if "set -x" writes to stdout or stderr. | 17:05 |
rharper | rbasak ok; I do have that | 17:05 |
rbasak | (IMHO, allow-stderr should have been the default) | 17:06 |
rharper | one more todo on strongswan; dropping lfcgi and clearsilver-dev | 17:06 |
rharper | oh, another question | 17:06 |
rharper | a few of the plugins extend /usr/lib/ipsec/charon binary's required access to files and capabilities that aren't in the default apparmor profile | 17:07 |
rbasak | We've hit this sort of thing before. It seems to be acceptable to add stuff to the default apparmor profile even if it isn't used by default. | 17:07 |
rharper | the plugin that does this isn't installed by default; how best to append these additional requests in the apparmor profile for only when the plugin is installed | 17:07 |
rharper | rbasak: ok | 17:07 |
rharper | one other thought was the include a #include libstronswan-plugin | 17:08 |
rbasak | (it might be worth leaving a comment or two explaining the use though) | 17:08 |
rharper | hrm | 17:08 |
rharper | rbasak: right, in the changelog as well as the profile | 17:08 |
rbasak | That might work too. I've done it the former way. I'd ask the security team for their thoughts on the latter way. | 17:08 |
rharper | ok, I'll likely follow the former with comments in the profile; they may suggest the alternative then | 17:09 |
tyhicks | I wouldn't add a new libstrongswan-plugin abstraction if the default strongswan profile is going to be the one and only consumer of that abstraction | 17:09 |
tyhicks | just document that the group of added rules are for certain plugins | 17:10 |
rbasak | Thanks tyhicks! | 17:10 |
tyhicks | no problem | 17:10 |
rharper | tyhicks: thanks! | 17:11 |
rbasak | lamont: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-February/016214.html | 17:13 |
cjwatson | pitti,infinity: Could you apply http://paste.ubuntu.com/15027019/ to my hint file? Won't quite work yet but hopefully will soon | 17:15 |
infinity | cjwatson: Sure. | 17:26 |
ginggs | doko, cjwatson: petsc, slepc and aster built successfully, now retrying getdp | 17:32 |
doko | ginggs, you have to wait until it's published | 17:32 |
ginggs | doko, itchy trigger finger :) | 17:33 |
cjwatson | infinity: thanks | 17:36 |
infinity | cjwatson: I assume this is the "rename click, so we don't have to keep renaming click" transition? | 17:36 |
cjwatson | Yay, that worked. | 17:36 |
infinity | cjwatson: If so, thanks! | 17:36 |
cjwatson | infinity: Yup | 17:36 |
=== mako_ is now known as mako | ||
ginggs | how can i tell when something is really published? I must be looking in the wrong place on launchpad. Also, why don't things fail with dep-wait any more? | 18:01 |
cjwatson | ginggs: rmadison is the safest check; LP itself can only tell you when something is committed at the start of a publisher run, not when it hits disk | 18:02 |
cjwatson | ginggs: and things do dep-wait, but there have always been exceptions that are hard to analyse correctly. do you have an example? | 18:02 |
ginggs | cjwatson: thanks - well i'm looking at https://launchpad.net/ubuntu/+source/getdp/2.7.0-0ubuntu2 | 18:03 |
nacc | rbasak: ok, thanks! | 18:04 |
ginggs | powerpc shows the red failed build icon | 18:04 |
ginggs | i seem to recall a yellow icon for dep-wait, or am i just confused? | 18:05 |
cjwatson | ginggs: right, that's a case where we can't dep-wait; libslepc3.6.1-dev is available on powerpc but uninstallable, and as far as LP knows that could be resolved in any of various ways | 18:05 |
cjwatson | ginggs: you get a dep-wait if the build-dep is just outright missing | 18:06 |
ginggs | ah ok, that explains it | 18:06 |
lamont | rbasak: yeah yeah | 18:19 |
nacc | slangasek: how do i do the versioned dep for php-pear? the old binary package (built from src:php5) had versions like 56.11+dfsg-1ubuntu3. The new package (built from src:php-pear) has versions like 1.10.1. Should I do an exact match (meaning only in the 1.10.1 family? >= won't work, because i think the older package will match, if I understand it right? | 18:20 |
lamont | rbasak: amusingly, that's what I'm working on right now | 18:21 |
=== wendar_ is now known as wendar | ||
lamont | nacc: I suspect that the new version is actually 1:1.10.1, since the archive would reject it if it had a binary package of a higher version in the archive... (without looking at the details myself) | 18:29 |
nacc | lamont: ah! that's what i was missing. so they bumped, the epoch, basically? | 18:30 |
nacc | lamont: and the old package had an implicit 0: epoch? | 18:30 |
lamont | if not specified, it's (effectively) 0:. and the UI hides it most everywhere | 18:31 |
nacc | lamont: does that mean i can specify my build-dep as 'php-pear (>= 1:)' ? | 18:31 |
lamont | generally, one would want >= 1:1.10.1 or such | 18:31 |
nacc | i guess that's true, the first officially released version | 18:32 |
nacc | lamont: thanks! | 18:32 |
lamont | apt-cache policy php-pear <-- shows epoch, and there are other ways to see | 18:32 |
lamont | heh. starting with dpkg -l :( | 18:32 |
bdmurray | kenvandine: Will you have a look at https://code.launchpad.net/~vorlon/lxc-android-config/apport-job-cleanup/+merge/285016? | 18:35 |
kenvandine | bdmurray, i have that in a silo | 18:40 |
kenvandine | haven't had a chance to test it though | 18:40 |
kenvandine | bdmurray, but i should have it ready for qa early next week | 18:41 |
bdmurray | kenvandine: okay, thanks! | 18:41 |
kenvandine | bdmurray, thx for nagging me :) | 18:41 |
kenvandine | i don't pay much attention to lxc-android-config, not sure if anyone is these days | 18:42 |
=== Elimin8er is now known as Elimin8or | ||
Pharaoh_Atem | nacc: have you been updating the etherpad on the php stuff that's succeeded/failed? | 18:56 |
Pharaoh_Atem | I don't see anything there | 18:56 |
nacc | Pharaoh_Atem: no, i need to go and do that | 18:57 |
nacc | the bug has been where i've been trying to document | 18:58 |
slangasek | seb128: ummmm. I'm maintainer of freetype because it was a library that needed attention, I know almost nothing about fonts ;) | 19:13 |
slangasek | nacc: MP for the seeds> fine to have that in advance. php-pear versioned deps> the 1: at the front of that version number shown in the changelog is called an epoch, it matters for versioned comparisons and is a reset button on the version numbering. So you want >= 1:1.10.1 for your versioned dep | 19:15 |
nacc | slangasek: great, thanks! | 19:15 |
nacc | slangasek: i put out a debdiff for pkg-php-tools, if that looked right to you, i'll update the other debdiffs to version php-pear and pkg-php-tools correclty | 19:16 |
nacc | and i apologize for that, nuance i missed in working with just my PPA | 19:16 |
slangasek | nacc: pkg-php-tools is already uploaded; I didn't think any further changes were needed on that one? it's already dep-wait in xenial-proposed | 19:17 |
nacc | slangasek: ah ok, you're right, sorry ... | 19:18 |
nacc | slangasek: but if i do the versioning right, then, they will all just dep-wait in -proposed until php-pear gets fixed? | 19:18 |
nacc | "they" => the other packages | 19:18 |
slangasek | nacc: yes | 19:18 |
nacc | slangasek: can i ask you to review the seed merge for the php migration? | 19:20 |
slangasek | nacc: juggling a couple of other critical things at the moment; if you drop me the URL to the MP I'll pick it up | 19:22 |
nacc | slangasek: sure, i can also ask smoser or someone else, but figured you'd have the most context right now | 19:22 |
nacc | slangasek: https://code.launchpad.net/~nacc/ubuntu-seeds/ubuntu.xenial/+merge/285931 | 19:23 |
smoser | nacc, i just loaded that page and it says conflicts all over it | 19:24 |
smoser | i assume that is not intended | 19:25 |
nacc | smoser: hrm! | 19:25 |
nacc | no not intended at all! | 19:25 |
nacc | let me look at what i did wrong | 19:25 |
nacc | smoser: argh! lp automatically chose to use platform.xenial again! fixing up | 19:26 |
smoser | :) | 19:26 |
nacc | smoser: slangasek: https://code.launchpad.net/~nacc/ubuntu-seeds/ubuntu.xenial/+merge/285932 | 19:27 |
nacc | sorry again! | 19:27 |
smoser | well, that one looks better | 19:30 |
nacc | :) | 19:30 |
smoser | it looks generally sane to me. i'd really rather hvae slangasek do it, although its jsut about as straight forward as could be. s/5// | 19:30 |
nacc | smoser: right, and i think the result (if i understand it right) is that both php-defaults and php7.0* will be in main ... but not sure how that all works (it's all still in the realm of 'magic' to me) | 19:31 |
lamont | when did we change it so that non-root can reboot the box with simply 'reboot' | 21:10 |
nacc | slangasek: ok, updated instructions posted at: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1522422/+attachment/4570466/+files/php7-archive-admins.howtov4 | 21:14 |
ubottu | Launchpad bug 1522422 in php5 (Ubuntu) "Update to php 7.0" [Wishlist,Triaged] | 21:14 |
nacc | slangasek: i'll work on updating the debdiffs to version the deps now | 21:14 |
nacc | slangasek: hrm, should i be submitting debdiffs even for the "rebuild" packages? since they will only rebuild properly if we use the version of pkg-php-tools and php-pear that support php7? | 21:16 |
infinity | lamont: I think physical console users have been able to do that for quite a while. | 21:19 |
lamont | ok | 21:23 |
lamont | I guess I've always thrown an sudo in front of it... | 21:24 |
slangasek | lamont, infinity: that would have to be when we switched to systemd, because the upstart implementation didn't hook into policykit etc | 21:30 |
rharper | non-root on systemd says permission denied to /dev/initctl | 21:30 |
rharper | when attempting reboot | 21:30 |
rharper | ssh login; but doubt that local console will give access to /dev/initctl ; which is a link to/run/systemd/initctl/fifo; which is prw------- 1 root root 0 Feb 12 21:29 /run/systemd/initctl/fifo; | 21:31 |
cjwatson | I think that's only if it can't contact systemd using dbus | 21:31 |
cjwatson | on a local console, I'd expect dbus to be available | 21:31 |
rharper | huh | 21:31 |
* rharper doesnt' really want to try on his laptop | 21:32 | |
rharper | but I'm terribly interested | 21:32 |
cjwatson | /dev/initctl is definitely fallback code in systemd | 21:32 |
rharper | it tries others | 21:32 |
rharper | first, Interactive authentication, logind, and then reboot.target; which all require interactive authentication; | 21:33 |
infinity | Anyhow, it makes sense as a console policy, given we let people reboot from the display manager and the desktop sessions. | 21:33 |
rharper | yeah | 21:33 |
lamont | slangasek: ah! | 21:33 |
infinity | Though I think we also block users from rebooting if *other* users are also logged in. | 21:33 |
infinity | IIRC. | 21:33 |
lamont | this was a window on the desktop | 21:33 |
nacc | infinity: i think i need to transfer my discussions of the php5 -> php7 migration from slangasek to you or another admin :) | 21:46 |
infinity | nacc: Indeed, slangasek is about to be attacked by babies. | 21:46 |
nacc | infinity: :) i'm working on updating my debdiffs to version depend on the right pkg-php-tools package (which is already in dep-wait in proposed) | 21:47 |
teward | cjwatson: can I pick your brain on sbuild, for a minute, in case you know the answer to my question? I'm happy to go to an offtopic channel or PM to ask if you'd prefer, as it's not 100% an Ubuntu-related question | 22:18 |
nacc | infinity: so i have a couple of questions i posed to slangasek earlier, that i'd like to ask you if you don't mind? | 22:20 |
=== salem_ is now known as _salem | ||
ilhami | hey guys. | 22:29 |
ilhami | when will Ubuntu allow non-canonical apps to run in the background? | 22:36 |
sarnold | ilhami: try #ubuntu-touch | 22:37 |
ilhami | sarnold, I can't. | 22:38 |
sarnold | ilhami: why not? | 22:38 |
ilhami | banned. | 22:38 |
infinity | nacc: Sorry, a bit in and out right now. | 23:05 |
infinity | nacc: If you're around later, perhaps. Or tomorrow? Or Monday? | 23:05 |
nacc | infinity: sure, i'll do my best. it's a holiday here on monday, but i might be able to check in at least a bit | 23:10 |
nacc | infinity: i've done my best to update the instructions at https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1522422/+attachment/4570466/+files/php7-archive-admins.howtov4 | 23:11 |
ubottu | Launchpad bug 1522422 in php5 (Ubuntu) "Update to php 7.0" [Wishlist,Triaged] | 23:11 |
nacc | which should get the b-d loops closed off in a side build (with sequence points) | 23:11 |
mapreri | GunnarHj: my thoughts are that most of the requests are reasonable. I'll consider them better once the last upload of a couple of days ago get out of NEW (due to new dictionary=>new binary). | 23:30 |
mapreri | I'd really love if Sweetshark (=> Björn, current owner of that bug) would comment on #1510198 :\ | 23:31 |
mapreri | ginggs: btw, if you have something to say about stuff I do in debian and then get synced here feel free to nag me ;) (though I'm not connected on freenode as often as on OFTC, I have my bouncer here too :P) | 23:32 |
GunnarHj | mapreri: Sounds great. I think that some of the proposed changes in debian/control are important to allow for a pure sync, while others are 'negotiable'. I'm not an expert on the exact meaning of those fields. | 23:40 |
GunnarHj | Yeah, a comment from Sweetshark would be great. OTOH I can't think of a reason why he would keep hesitating. | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!