| mwhudson | doko: yes | 00:14 |
|---|---|---|
| cyphermox | nacc: cool, ta | 00:20 |
| mwhudson | doko: also does https://launchpadlibrarian.net/318956988/buildlog_ubuntu-artful-amd64.gpgme1.0_1.8.0-3ubuntu2_BUILDING.txt.gz mean anything to you? | 00:20 |
| mwhudson | it fails in the archive the same way, some bizarro interaction between pie/pic things | 00:21 |
| mwhudson | the rules file says | 00:21 |
| mwhudson | export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie,+pic | 00:21 |
| mwhudson | which seems a bit crazy | 00:21 |
| jbicha | mwhudson: could you check if we can remove the ",-pie,+pic" diff from Debian there now that we have a newer dpkg, etc.? | 00:24 |
| mwhudson | oh is that delta? | 00:38 |
| mwhudson | that would explain a lot :) | 00:38 |
| nacc | rbasak: i think the above paste has git-clone matching the spec (and I guess we'll want another option to git-clone like --add-remote or something for adding a colleague's remote?) | 00:42 |
| mwhudson | does the ben output at https://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html come in any other formats? | 02:48 |
| mwhudson | AssertionError: "year is out of range" does not match "year 0 is out of range" | 03:20 |
| mwhudson | yay | 03:20 |
| arune_ | hello, regarding https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1641203/comments/14 | 06:55 |
| ubottu | Launchpad bug 1641203 in sssd (Ubuntu Xenial) "SSSD can't process GPO from Active Directory when it contains lines with no equal sign" [Medium,Triaged] | 06:55 |
| arune_ | I need sssd 1.13.5 to test ding-libs from proposed | 06:55 |
| arune_ | are sssd 1.13.5 also in proposed? (where can I see that?) | 06:56 |
| infinity | arune_: sssd hasn't been uploaded yet, no. | 07:00 |
| arune_ | infinity, ok, thanks | 07:00 |
| Unit193 | Though sssssssd might have. >_> | 07:05 |
| mwhudson | doko: some of the bad things on https://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html have been rebuilt now | 07:26 |
| mwhudson | doko: i guess that means the packaging screws up depends? | 07:26 |
| mwhudson | or possibly the packaging fails to build for all supported python versions somehow | 07:26 |
| arune_ | infinity, where can I watch if new version of sssd gets uploaded? | 08:20 |
| infinity | arune_: The bug you referred to will get a comment when the sssd that references it is uploaded. | 08:20 |
| arune_ | infinity, thanks | 08:21 |
| sil2100 | bdmurray: hey! Once you're up: I wanted to review your apport SRUs just now but none of the bugs comply to the SRU procedures | 09:51 |
| sil2100 | bdmurray: the changes themselves look good and I guess me as a reviewer understands all the implications, but I don't know if I can legally accept this without any of the formalities fullfilled | 09:53 |
| sil2100 | bdmurray: I guess I could get it in if you'll be the one doing the verification | 09:55 |
| sil2100 | bdmurray: anyway, I'll leave it for now until you pop up | 09:56 |
| brainwash | systemd 233 was built with +IMA, but there is no /etc/ima/ima-policy or /etc/default/ima-policy | 11:49 |
| brainwash | bug? | 11:49 |
| brainwash | >Unable to open file: /etc/ima/ima-policy (-2) | 11:51 |
| brainwash | >IMA: policy update failed | 11:51 |
| infinity | brainwash: It's not a bug that we don't ship a policy, no. | 11:57 |
| infinity | brainwash: It might be a minor upstream cosmetic bug that systemd is whiny about it when the file isn't there. | 11:57 |
| brainwash | infinity: alright. thanks | 11:57 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| bdmurray | sil2100: You shouldn't just accept it, that'd be a double standard on our part! I'll add the stuff today. | 14:14 |
| sil2100 | bdmurray: thanks! Give me a quick poke once done, I'll re-review them then | 14:15 |
| nacc | rbasak: i'm around now, if you want to discuss my laundry list from yesterday :) | 14:42 |
| rbasak | Sure. Give me ten minutes? | 14:44 |
| doko | mwhudson: looks like you got some help from somebody ... | 14:45 |
| nacc | rbasak: yep | 14:45 |
| doko | mwhudson: looking at libxml2 ... this should be worth a bug report, or a fix. | 14:47 |
| doko | xnox: boost1.62 and .64 still in artful? | 14:48 |
| doko | .64 | 14:48 |
| doko | .63 even | 14:48 |
| xnox | yeah.... | 14:50 |
| doko | mwhudson: did you already file debian bugs for the 3.6 transition? If not, please could you use user tagging, python3.6 / debian-python@lists.debian.org? | 15:00 |
| infinity | doko: libxml2 is a mess. That debian/rules made my eyes bleed. | 15:23 |
| infinity | doko: I feel like the right fix will be someone submitting a whole new version of the debian/ directory. :P | 15:24 |
| doko | well, happyaron packaging ;p | 15:24 |
| infinity | doko: FWIW, if you feel the urge to look, it actually *does* build for all python versions. Then installs them all over each other, and the default wins. | 15:26 |
| infinity | (derp) | 15:26 |
| doko | yes, there is a prename call in between, which is now deprecated. thanks for the dpkg maintainer to break things ... | 15:26 |
| doko | I really love this behaviour | 15:27 |
| infinity | How is that the dpkg maintainer's fault? :P | 15:27 |
| infinity | But also, the prename is just for the -dbg stuff, it looks like. | 15:27 |
| infinity | There's no way that rule file would have ever worked right for multiple versions of python3. | 15:28 |
| infinity | (Which makes sense, as it was introduced with py3.5, and never tested with multiple) | 15:28 |
| doko | not for 3.4? | 15:29 |
| infinity | * add python3 support (Closes: #737774) | 15:30 |
| infinity | -- Aron Xu <aron@debian.org> Mon, 12 Sep 2016 02:57:02 +0800 | 15:30 |
| doko | looks like some of the rebuilds were done before the new python3-defaults was published. at least the protobuf package now fails in the tests instead of the build | 15:30 |
| doko | happyaron: ^^^ | 15:30 |
| happyaron | doko: I took the package from mike miller IIRC | 15:34 |
| happyaron | when he doesn't have enough time to make security updates | 15:35 |
| infinity | python-traits is hung up because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846771 | 15:35 |
| ubottu | Debian bug 846771 in src:python-traits "python-traits: FTBFS randomly (failing tests)" [Important,Open] | 15:35 |
| infinity | I've retried it repeatedly, no luck. | 15:35 |
| infinity | Might just want to carry a delta to ignore those two tests for the short term. :/ | 15:36 |
| happyaron | infinity: so what's the problem you have with libxml2? | 15:37 |
| infinity | happyaron: The attempt to build for multiple python3 versions doesn't work. | 15:38 |
| infinity | happyaron: Unless you wanted a larger review of debian/rules than that, but I'm tired. :P | 15:38 |
| happyaron | I had a hard time understanding the d/rules when I took the package, :D | 15:40 |
| happyaron | mind to send a bug report? I'll give it a poke. | 15:41 |
| infinity | happyaron: I'm about to go to bed. If this verbal bug report isn't enough, I can follow up later. | 15:41 |
| happyaron | good night, please do drop something to the bug tracker so that it's easier to track... | 15:43 |
| doko | mwhudson: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.6;users=debian-python@lists.debian.org | 16:09 |
| doko | xnox: boost doesn't like to build for multiple python versions? | 16:17 |
| xnox | doko, it does not | 16:21 |
| doko | xnox: b-d: python-3-all-dev | 16:21 |
| doko | maybe change to python3-dev, python-dev | 16:22 |
| doko | but it builds for 3.6 ... | 16:22 |
| xnox | doko, ok. | 16:23 |
| xnox | but everything links against boost_python3.so or what not. | 16:23 |
| xnox | thus things rebuild against the boost-python will still be using only the default python3. | 16:23 |
| doko | so you are just lucky that it builds 3.5 after 3.6 and overriding the 3.6 binaries ... | 16:25 |
| === alan_g is now known as alan_g|EOW | ||
| bdmurray | sil2100: apport X and Y SRUs are all set | 17:09 |
| sil2100 | \o/ | 17:14 |
| sil2100 | bdmurray: on it | 17:15 |
| bdmurray | sil2100: Actually I meant Y and Z - X is still coming. | 17:15 |
| bdmurray | sil2100: I also just uploaded whoopsie to the yakkety queue | 17:20 |
| tsimonq2 | Is there a reason why pull-ubuntu-source is not symlinked to pull-lp-source in ubuntu-dev-tools? | 17:45 |
| tsimonq2 | It would make sense, in my opinion. | 17:45 |
| infinity | tsimonq2: Because lp is shorter to type? :P | 17:46 |
| infinity | tsimonq2: Alternate answer "because it's not". I don't think there's a conspiracy afoot, just no one thought/cared to do so. Which probably indicates how often we're asked (never), which probably means you could just alias it locally and be happy. | 17:47 |
| tsimonq2 | infinity: Fair. :) | 17:48 |
| sil2100 | bdmurray: accepted, I'll also accept whoopsie for xenial even without the apport part as it doesn't hurt anyone | 18:05 |
| nacc | slangasek: are you available for a quick question? (beyond this one :) | 18:22 |
| slangasek | nacc: yah | 18:22 |
| nacc | slangasek: rbasak and i were discussing earlier today about what you'd expect the default behavior of `git clone lp:...` to be. Would you want us to checkout to the patches-applied ubuntu/devel branch? The reason *not* to do that is there is no .pc directory. So things like `dpkg-buildpackage` and `dpkg-source --commit` don't work without .pc. But the lack of .pc is for dgit compatibility. | 18:24 |
| nacc | slangasek: vs. what we currently do, which is put you in the patches-unapplied ubuntu/devel | 18:25 |
| nacc | slangasek: just trying to capture different use-cases/expectations, at least at first | 18:25 |
| slangasek | nacc: fwiw I'm pretty sure dpkg-buildpackage does work with patches-applied and without .pc | 18:25 |
| slangasek | nacc: but I figured I'd leave it up to you guys what the default branch checkout should be :) | 18:26 |
| nacc | slangasek: oh i wonder if it might, because i think it might do a parallel extraction to see if there are local cahgnes? | 18:26 |
| nacc | slangasek: if dpkg-bp does 'just work', then maybe it's less of a concern. The `dpkg-source --commit` problem is why dgit (afaict) has this quilt-fixup mode | 18:27 |
| slangasek | nacc: MoM for example always gives you a patches-applied, no-.pc tree | 18:27 |
| nacc | slangasek: sorry, you're right, dpkg-bp probably does work | 18:28 |
| nacc | slangasek: the issue is how to make changes to that tree that are capture-able in the src package | 18:28 |
| nacc | it feels like dgit's model is you use dgit and only dgit :) | 18:28 |
| nacc | slangasek: but that's good feedback, i'll make some notes | 18:29 |
| nacc | slangasek: totally unrelated question (now that I remember it). I'm trying to add the open-isns self-tests at build-time (for its MIR). Is there a typical way to specify to use the package build directory as LD_LIBRARY_PATH (or maybe some subdir of the build directory)? As the tests need to load the library built by the package during the tests. | 18:30 |
| slangasek | nacc: I don't think there's any way of doing this that's more typical than just constructing and exporting LD_LIBRARY_PATH yourself | 18:31 |
| slangasek | if upstream were using libtool, there would be wrappers galore | 18:31 |
| nacc | slangasek: ok, i wasn't sure, thanks! | 18:31 |
| nacc | slangasek: yeah they're not :) | 18:31 |
| nacc | slangasek: does debhelper provide a variable containing the build_dir? Or is it safe to use '.' in d/rules? | 18:32 |
| slangasek | nacc: I don't think there's a variable for build dir, no | 18:32 |
| gsilvapt | Hello everyone | 20:03 |
| gsilvapt | I need help updating a Debian repository with a newer release version from upstream, using gbp | 20:04 |
| gsilvapt | Can someone guide me through the process? I'm not 100% how that works from the docs because the covered processed seems to be the opposite | 20:04 |
| nacc | gsilvapt: do you need to use gbp? | 20:09 |
| gsilvapt | I'd like to because the upstream is a Git repo | 20:09 |
| nacc | gsilvapt: but you're using an upstream release, right? not from an arbitrary git commit? | 20:10 |
| nacc | gsilvapt: just use `uscan` and `uupdate` | 20:10 |
| gsilvapt | no, it's an upstream release | 20:10 |
| gsilvapt | But how do I take care of things? Get both sources and use those commands to update the Debian package? | 20:11 |
| nacc | gsilvapt: i don't know what you mean | 20:11 |
| nacc | gsilvapt: `uscan` will download new upstream releases based upon debian/watch | 20:11 |
| nacc | gsilvapt: `uupdate` will take the existing debian/ and use the provided orig tarball you obtained via `uscan` | 20:12 |
| gsilvapt | So I do pull-debian-source and then do those commands? | 20:12 |
| nacc | gsilvapt: you want to update a debian version's release? | 20:12 |
| nacc | gsilvapt: that is typically a task for the debian maintainer | 20:12 |
| gsilvapt | I can still propose him, right? | 20:13 |
| gsilvapt | or ask him for sponsorship on that | 20:13 |
| nacc | gsilvapt: i guess so, not very typical IME | 20:13 |
| gsilvapt | after uupdate, what is next? | 20:13 |
| nacc | gsilvapt: this seems contradictory to what you suggested was your goal -- to learn development/fix bugs, etc | 20:14 |
| gsilvapt | Also included maintaining packages | 20:14 |
| nacc | it seems way more useful to learn the first ones first then work on maintaining packages | 20:14 |
| nacc | but your choice, of course | 20:14 |
| nacc | gsilvapt: have you run `uupdate`? | 20:14 |
| nacc | gsilvapt: with an appropriate path to a tarball | 20:14 |
| nacc | gsilvapt: it tells you what to do, it will create a ../<srcpkg>-<newversion> directory with the srcpkg contents | 20:15 |
| nacc | you'll need to update d/changelog, make sure the d/patches apply/need refreshing etc, check that everything is building as expected and test it | 20:15 |
| gsilvapt | This was a suggestion from the mentor I talked about. He mentioned I should use gbp specifically but I'm kind of stuck because the only material I found has the reverse process (debian to upstream and not upstream to debian). Didn't want to mess that up. | 20:16 |
| gsilvapt | Not sure if he wants to actually submit that but it can still work as a project to learn how things work | 20:16 |
| gsilvapt | I'm guessing messing around with local repositories will not damage the original ones | 20:16 |
| gsilvapt | No, I haven't done a thing | 20:17 |
| gsilvapt | Still trying to figure out the process in my head before doing stuff | 20:17 |
| nacc | gsilvapt: presumably you will need to use `gbp-import-orig` if you want to use gbp | 20:17 |
| nacc | i don't personally use gbp, so i can't help more with that | 20:17 |
| nacc | gsilvapt: it feels like you should just ask your mentor | 20:18 |
| gsilvapt | Okay, thanks anyway! I'll keep trying to look out for gbp docs | 20:18 |
| nacc | gsilvapt: the manpages are pretty complete iirc | 20:18 |
| gsilvapt | Alright, thanks! | 20:24 |
| === CRogers_________ is now known as crogers | ||
| === JanC_ is now known as JanC | ||
| rbasak | slangasek: nacc: http://people.canonical.com/~cjwatson/dpkg-quilt-setup | 21:26 |
| rbasak | MoM does break dpkg-buildpackage, at least some of the time. | 21:26 |
| rbasak | That script (IIRC, it may be some other script) fixes it up | 21:27 |
| rbasak | I don't like this general approach though. There's more scope that an edge case will not put you exactly back. | 21:28 |
| slangasek | you can have an MoM tree for which the patches don't actually unapply cleanly; but that's separate from .pc being absent | 21:29 |
| rbasak | Ah, I see. | 21:29 |
| rbasak | Even so, can we perhaps consider what would happen if we did keep .pc in our trees, and if that breaks dgit, if we can make dgit cope with that situation? | 21:29 |
| slangasek | (and, to be clear, really annoying to manually unwind when it happens :) | 21:30 |
| rbasak | Then we both get what we want, I think. All tooling, including quilt, will all work at any step. | 21:30 |
| slangasek | hmm but storing .pc means lots of extra delta in the history | 21:30 |
| rbasak | The history is fake anyway. | 21:31 |
| rbasak | If you want real history, look at the patches unapplied branch and the quilt patches, since that's what's really there. | 21:31 |
| slangasek | anyway, I'm not fussed about lp:ubuntu/$pkg pointing to patches-unapplied | 21:31 |
| rbasak | I am. I appreciate Ian's "drive by contributor" use case. | 21:32 |
| Unit193 | Why would one want .pc applied? | 21:32 |
| rbasak | Unit193: so that "quilt pop -a" still works. | 21:32 |
| rbasak | It's just a matter of deciding what the patches-applied commits should look like exactly. | 21:32 |
| rbasak | But I think I've become convinced that it's the patches-unapplied that really matters to Ubuntu. That's what we'll be uploading. Until one day everyone's using git-dpm or something similar. | 21:33 |
| rbasak | Just adding commits onto patches-applied means that we'll be losing sight of our delta. | 21:34 |
| rbasak | I want a rich patchset, as well as a rich history. | 21:34 |
| sladen | yup | 21:35 |
| nacc | quilt pop -a and `dpkg-source --commit` | 21:43 |
| nacc | i think the latter is most relevant for our drive-by case | 21:43 |
| sladen | if one wants this illusion of reality, by all means write a wrapper | 21:46 |
| gsilvapt | nacc, could you give me a hand using uupdate? | 21:46 |
| nacc | gsilvapt: sure, what's up? | 21:46 |
| gsilvapt | so, I ran uscan and it found the tarballs for a new version. | 21:47 |
| gsilvapt | now running uupdate isn't that straightforward x) | 21:47 |
| nacc | gsilvapt: uscan, without args, i think runs uupdate itself | 21:48 |
| nacc | gsilvapt: what src package? | 21:48 |
| gsilvapt | it says no archive given | 21:48 |
| gsilvapt | it says no archive given if I run uupdate* | 21:48 |
| nacc | gsilvapt: well you didn't give it an archive | 21:49 |
| nacc | gsilvapt: as i said earlier, you need to pass it the new upstream tarball | 21:49 |
| nacc | gsilvapt: did you read `man uupdate`? | 21:49 |
| gsilvapt | yes, I have it opened but still can't run the commands | 21:49 |
| nacc | gsilvapt: what src package? | 21:49 |
| gsilvapt | what do you mean? The name of the program? | 21:51 |
| nacc | gsilvapt: what source package are you trying to update? very basic question | 21:52 |
| gsilvapt | pandas | 21:52 |
| viju | Hi, if I rebuild the package from sources, will it replace the original package installed before? | 21:52 |
| nacc | viju: rebuilding a package just builds a pacakge | 21:53 |
| nacc | viju: it doesn't install it | 21:53 |
| viju | I mean if I make install it. | 21:53 |
| nacc | gsilvapt: http://paste.ubuntu.com/24563342/ | 21:55 |
| nacc | viju: if you build from source, you're not using a package | 21:56 |
| gsilvapt | I was using the wrong command to show where the file was. Sorry and thanks for the help! | 21:56 |
| nacc | viju: so i'm not sure what you mean | 21:57 |
| viju | nacc: I am trying to tinker with some application, just change something and build-install it to see how it works, so that next time I can add small feature for my own use. However I am a beginner when it comes to building anything on Ubuntu. | 22:02 |
| tsimonq2 | I want to work on (release a new version) a package that's in Main. Is there anything special for finding out who to check with if that's OK? Isn't that a bit different from getting things in Universe? | 22:03 |
| nacc | viju: if it's an application, you probably dont' actually need to build install it | 22:03 |
| nacc | tsimonq2: is it sync'd currently? | 22:03 |
| nacc | tsimonq2: and/or which pkg? | 22:03 |
| nacc | viju: that is just build it locally and then run the local binary | 22:04 |
| tsimonq2 | nacc: I was looking at libreoffice | 22:04 |
| tsimonq2 | nacc: No, it's not synced | 22:04 |
| nacc | heh | 22:04 |
| nacc | there's a snap now! :) | 22:04 |
| tsimonq2 | Bah | 22:04 |
| tsimonq2 | :P | 22:04 |
| nacc | tsimonq2: i'd probably check in with the last uploader | 22:04 |
| tsimonq2 | nacc: Ah ok, so just like in Universe? | 22:04 |
| nacc | tsimonq2: yeah, i mean, (IMO) packages in main/universe is a support statement (security and canonical), less deterministic about how the package is maintained | 22:05 |
| nacc | others may disagree | 22:05 |
| nacc | but i've not treated them differently in that regard so far | 22:05 |
| viju | nacc: so if I place it in /opt/gcalculator, I can run it from the same location, right? | 22:06 |
| tsimonq2 | nacc: Which is why I want to be very careful that I don't duplicate work if I want something in Main because there's likely a Canonical person working on it, iirc. | 22:06 |
| nacc | tsimonq2: yeah, i see what you mean -- i'd contact the last uploader still | 22:06 |
| tsimonq2 | nacc: Ok, thanks. :) | 22:07 |
| nacc | viju: i mean, why put it in /opt? just build it from somewhere and run it from there? | 22:07 |
| nacc | s/from somewhere/somewhere/ | 22:07 |
| spencerb | with unity 8 officially abandoned, are the dconf bindings for qt still being developed? | 23:04 |
| tsimonq2 | Hmmmm, good question... | 23:05 |
| tsimonq2 | mitya57: ^ | 23:06 |
| nacc | rbasak: ok, i have pushed up the rename to git-ubuntu, and will give you a MP for the namespace changes as they are now | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!