| mdeslaur | nacc: I haven't had time to look at it yet | 02:25 |
|---|---|---|
| mdeslaur | nacc: I have to basically modify the tool to use the main/universe split instead of looking at the support period listed in the Packages files | 02:26 |
| mwhudson | oh heh i made some uploads just after a kde update | 03:03 |
| mwhudson | so i'll get my autopkgtest results next week then | 03:03 |
| lathiat | e | 07:14 |
| === CRogers_________ is now known as CRogers | ||
| === CRogers_________ is now known as CRogers | ||
| jamespage | any arm* linker guru's able to help my understand why I see this linker failure on armhf only - https://launchpadlibrarian.net/323794587/buildlog_ubuntu-artful-armhf.ceph_12.0.3-0ubuntu1~ubuntu17.10.1+ppa11_BUILDING.txt.gz | 12:24 |
| jamespage | ? | 12:24 |
| seb128 | hum | 13:19 |
| ginggs | jamespage: i recognize the compiler warning, but can't see what the actual linker error is. where can i find the source package? | 13:20 |
| jamespage | ginggs: you can pull it from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2779/+packages | 13:21 |
| ginggs | jamespage: ta | 13:21 |
| seb128 | the urls to download the debs from https://launchpad.net/ubuntu/artful/+queue?queue_state=0&queue_text= don't work | 13:21 |
| seb128 | they lead to "Lost something?" launchpad pages | 13:22 |
| seb128 | e.g libebook-1.2-19_3.24.2-0ubuntu2_amd64.deb (69.7 KiB) NEW | 13:22 |
| seb128 | -> https://launchpad.net/ubuntu/artful/+upload/15539512/+files/libebook-1.2-19_3.24.2-0ubuntu2_amd64.deb | 13:22 |
| seb128 | cjwatson, wgrant, hey, do you know if that's a launchpad bug/known issue? | 13:31 |
| cjwatson | seb128: https://bugs.launchpad.net/launchpad/+bug/1697680 - reported by Didier earlier today and I pushed an MP to fix it | 13:33 |
| ubottu | Launchpad bug 1697680 in Launchpad itself "Can't access binaries in NEW queue (source packages assets are fine though)" [Critical,In progress] | 13:33 |
| seb128 | thanks | 13:33 |
| seb128 | sorry for not checking launchpad reported bugs first, I should know better | 13:33 |
| cjwatson | seb128: interesting that we rolled out the change that caused that regression on 2017-05-11 and you both noticed it within hours of each other :) | 13:33 |
| seb128 | (I had IRC closed during lunch so didn't notice that didrocks hit that earlier) | 13:33 |
| seb128 | hehe, yeah | 13:34 |
| cjwatson | (it was a consequence of the fix for bug 1663334) | 13:34 |
| ubottu | bug 1663334 in Launchpad itself "make queue files dget'able" [Low,Fix released] https://launchpad.net/bugs/1663334 | 13:34 |
| seb128 | archive admin reviews are not going strongly nowadays :-/ | 13:34 |
| cjwatson | seb128: (you can use queue fetch as a workaround) | 13:34 |
| seb128 | ah, nice to see those becoming dget compatible! | 13:34 |
| seb128 | I did get the binaries from the build page | 13:34 |
| cjwatson | or that, yes | 13:35 |
| seb128 | they are just not marked as New so a bit of forth and back but it was ok :-) | 13:35 |
| seb128 | thanks! | 13:35 |
| cjwatson | np | 13:35 |
| ginggs | jamespage: i'm gonna try building with --no-parallel in case that makes the build log easier to follow | 13:37 |
| jamespage | ginggs: ok it will take some time... | 13:37 |
| jamespage | ginggs: thanks for the help | 13:37 |
| ginggs | doko and infinity know of that warning. I started a wiki page to keep track of affected packages https://wiki.ubuntu.com/GCC7#arm_gcc_7_abi_transition . ceph is the first build failure I've seen, the others fail autopkgtests because of the warning | 13:41 |
| ginggs | jamespage: ^ | 13:41 |
| === Tm_K is now known as Tm_T | ||
| rbasak | cyphermox: please see bug 1624519 - I pinned it down. I think it's related to your merge of tasksel 3.34ubuntu1. | 14:35 |
| ubottu | bug 1624519 in tasksel (Ubuntu) "Debian-defined tasks override Ubuntu-defined ones" [Undecided,Triaged] https://launchpad.net/bugs/1624519 | 14:35 |
| nacc | mdeslaur: yep, just checking, we had one user respond in a different bug (php7.0-fpm MIR) and referred to that bug as to why the status is what it is. Presumably it's a cherry-pick(s) back from the yakkety version? | 15:29 |
| mdeslaur | nacc: no, yakkety doesn't contain a fix....the tools needs to work around the fact that the Support tag wasn't updated correctly in previous releases | 15:34 |
| mdeslaur | right now yakkety is ok, just because it's not an LTS release | 15:34 |
| mdeslaur | actually, I'm not even sure if yakkety is ok | 15:35 |
| nacc | mdeslaur: oh! :) it's marked fix released by bdmurray | 15:35 |
| mdeslaur | yeah, it's complicated...some of the yakkety universe packages have "Supported: 9m" | 15:36 |
| mdeslaur | when in fact...they probably shouldn't | 15:37 |
| nacc | mdeslaur: ok, it seems like you have a solid handle on it :) | 15:37 |
| mdeslaur | kind of :P | 15:37 |
| kyrofa | Hey infinity, I've got a click patch for xenial that works, and I figured I should just bump the ubuntu2 to ubuntu3. However, there is no debian/patches currently, and I'm not sure how to build a source deb using the 0.4.43 orig tarball without debian/patches | 15:53 |
| kyrofa | (my debian packaging chops need some work, so I'm pleased I'm getting exposed to this, but I could use some guidance) | 15:54 |
| nacc | kyrofa: d/p only exists if there are patches to apply? | 15:59 |
| nacc | kyrofa: that is, if it's an upstream source change | 15:59 |
| nacc | kyrofa: is it? (or what is the patch specifically) | 15:59 |
| cjwatson | kyrofa: click is a native package. don't use debian/patches/ | 15:59 |
| cjwatson | kyrofa: just apply the thing directly | 16:00 |
| cjwatson | well, its versioning isn't technically native, but still | 16:00 |
| nacc | cjwatson: ah, makes sense | 16:00 |
| kyrofa | cjwatson, yeah the versioning was throwing me off. I tried applying directly, but of course when I use the 0.4.43 orig tarball I get complaints of local changes. Should I not be using that orig? | 16:01 |
| cjwatson | kyrofa: I would be inclined to construct a version along the lines of 0.4.43+16.04.20170613-0ubuntu1. bileto should be able to do that for you if you give it the right input | 16:01 |
| cjwatson | kyrofa: e.g. an MP that's based on the correct starting point | 16:01 |
| cjwatson | kyrofa: "Revert to r606" in your MP - why? Why not just branch from r606 in the first place? | 16:02 |
| kyrofa | cjwatson, ah, which would be a new tarball, that does make things easier. infinity just asked for a debdiff, I shouldn't need to make a new MP unless you want me to? | 16:02 |
| cjwatson | well, your branch, not your MP | 16:02 |
| kyrofa | cjwatson, because I don't know bzr :P . If I was to make a MP it would of course be cleaned up | 16:03 |
| cjwatson | kyrofa: It would be preferable to figure out how to land this using bileto if possible | 16:03 |
| kyrofa | cjwatson, okay | 16:03 |
| cjwatson | kyrofa: I've pushed lp:~click-hackers/click/xenial, which should help you; it should be possible to branch that and use it as the target for an MP | 16:04 |
| kyrofa | cjwatson, excellent, I'll do that, thank you | 16:04 |
| rbasak | xnox, slangasek, rharper: do we have a bug tag for the netplan server iso related work? Bug 1697730 is a candidate I think. | 16:29 |
| ubottu | bug 1697730 in systemd (Ubuntu) "Long boot time due to systemd-networkd-wait-online.service failure" [Undecided,New] https://launchpad.net/bugs/1697730 | 16:29 |
| slangasek | rbasak: bugs are being linked from the blueprint https://blueprints.launchpad.net/ubuntu/+spec/foundations-aa-migrating-to-netplan | 16:31 |
| slangasek | rbasak: also, cyphermox | 16:31 |
| rbasak | Linked, thanks. | 16:32 |
| ogra | wow, you re-vived blueprints ? | 16:32 |
| slangasek | they've never been dead | 16:34 |
| ogra | well, others said differently :) | 16:34 |
| ogra | good to see someone still uses them | 16:34 |
| === zyga is now known as zyga-fedora | ||
| tdaitx | bdmurray, to enable staging it's enough to just add a 'staging' in the crashdb-conf's ubuntu entry, right? after that, how do I access the staging error tracker? | 17:01 |
| bdmurray | tdaitx: No - that's for apport. To switch whoopsie you'd do stop the whoopsie service and manually start it via 'sudo CRASH_DB_URL=https://daisy.staging.ubuntu.com'. Then go to errors.staging.ubntu.com/OOPS/$OOPS_ID. | 17:03 |
| kyrofa | cjwatson, so do I target xenial in bileto, then? | 17:04 |
| bdmurray | sudo CRASH_DB_URL=https://daisy.staging.ubuntu.com whoopsie -f' | 17:04 |
| bdmurray | tdaitx: ^^ that's what I really meant | 17:04 |
| tdaitx | bdmurray, right, thanks, I will check why it is duplicating the tag, it shouldn't... I used the same logic from other places and there was no duplication check, I might have missed something | 17:05 |
| cjwatson | kyrofa: I believe | 17:07 |
| cjwatson | so | 17:07 |
| kyrofa | cjwatson, alright, build is running. That MP is very nearly a clean backport of the MP you already reviewed if you have time to take a look | 17:09 |
| cjwatson | kyrofa: which MP? I thought I just approved one | 17:11 |
| bdmurray | tdaitx: well if 'tag' not in report['Tags'] would avoid it | 17:11 |
| tdaitx | bdmurray, sure, I know, but does that mean that the other reports also duplicate the tag? | 17:12 |
| bdmurray | tdaitx: I don't know. Maybe apport should review the tags for duplicates or something. Its really not a big deal though. | 17:13 |
| tdaitx | bdmurray, if the tag is being added twice then all that hs_err logic is also being run twice, I would like to understand why - and yeah, I can cut it at the very first if (no need to run all that again) | 17:14 |
| kyrofa | cjwatson, oh you were fast, thank you! | 17:16 |
| === JanC_ is now known as JanC | ||
| tdaitx | bdmurray, alright, no duplication on staging, I believe it was the way I ended up running stuff... for some reason the update-notifier-crash service is not detecting my X session, so the service wont activate (not even manually) | 17:28 |
| tdaitx | I ended up running apport-cli and then also installed apport-noui | 17:28 |
| tdaitx | as I was doing stuff in parallel apport might have run through the report twice or something | 17:29 |
| tdaitx | starting update-notifier-crash manually send the report to staging and there was no tag duplication, as expected | 17:30 |
| tdaitx | now I need to check why that service believes there is no X session =/ | 17:30 |
| bdmurray | tdaitx: That seems like a special corner case. | 17:31 |
| fossfreedom | Hi all - our package budgie-desktop was sync from debian/experimental today - but it failed to build. It builds successfully in pbuilder and also in our PPA. Any guidance that you can give me why buildd would produce a different build result? | 18:03 |
| nacc | fossfreedom: in https://launchpadlibrarian.net/323780787/buildlog_ubuntu-artful-amd64.budgie-desktop_10.3.1-2_BUILDING.txt.gz search for FAILED | 18:06 |
| nacc | Unknown option -lm | 18:06 |
| nacc | Run 'valac --help' to see a full list of available command line options. | 18:06 |
| nacc | fossfreedom: is that why? | 18:06 |
| fossfreedom | yup - but I'm struggling why buildd is failing but the same source builds in an artful PPA and also artful pbuilder | 18:07 |
| nacc | fossfreedom: does your PPA have proposed enabled? or your pbuilder? | 18:08 |
| jbicha | when did you build it in your artful ppa? | 18:08 |
| fossfreedom | no | 18:08 |
| nacc | fossfreedom: the builder does | 18:08 |
| nacc | fossfreedom: and there is a new valac in artful-proposed :) | 18:09 |
| fossfreedom | about 10 minutes ago jbicha | 18:09 |
| nacc | fossfreedom: 0.34.7-1 (a) and 0.36.3-1~gi1 (a-p) | 18:09 |
| fossfreedom | ahhh | 18:09 |
| nacc | fossfreedom: so presumably the new valac has changed flags somehow? | 18:09 |
| nacc | fossfreedom: but enablign proposed should make it reproducible | 18:09 |
| jbicha | valac is stricter so I expect several packages to FTBFS :( | 18:10 |
| fossfreedom | okey dokey - will try that. | 18:10 |
| nacc | jbicha: ah, interesting | 18:10 |
| jbicha | valac 0.36 is the same vala released with GNOME 3.24 a few months ago | 18:10 |
| jbicha | there was also a glib2.0 update this morning | 18:11 |
| jbicha | the glib update is still in -proposed | 18:12 |
| fossfreedom | ok - thanks. Yeah - enabling proposed killed the build. | 18:16 |
| nacc | fossfreedom: gl! :) | 18:16 |
| infinity | fossfreedom: Looks like a meson/ninja (well, somewhere in the build system) bug to me. | 19:11 |
| infinity | fossfreedom: That -lm should be passed to the cc call, but not the valac call. | 19:11 |
| infinity | fossfreedom: Or maybe it's self-inflicted. src/lib/meson.build has "meson.get_compiler('c').find_library('m', required: false)," which seems to be to be forcing it to add C-style linking to a vala project. | 19:20 |
| fossfreedom | infinity, agreed. very odd. Upstream confirms that they are using the same valac compiler version as in proposed. | 19:20 |
| jbicha | fossfreedom: you could try disabling -proposed in your PPA and selectively copying packages into the PPA to see which ones fails the build | 19:21 |
| jbicha | for instance, upstream is likely not using the latest glib development release | 19:22 |
| infinity | Based on the error, it can really only be meson or valac. | 19:22 |
| infinity | Either valac stopped ignoring the incorrect option or meson started injecting it into the valac call. | 19:22 |
| infinity | Both are new in -proposed. | 19:22 |
| jbicha | oh I forgot that meson was stuck in -proposed too | 19:23 |
| kyrofa | infinity, that xenial click SRU MP has been approved and bileto is all green. I'm nervous to hit "publish" though given that I'm targeting xenial. Is that the next step? | 19:55 |
| kyrofa | (cc cjwatson, although I expect you're asleep) | 19:56 |
| slangasek | that is the next step. hopefully the ticket was set up correctly to target xenial, and not xenial overlay? | 19:56 |
| kyrofa | slangasek, indeed, xenial: https://bileto.ubuntu.com/#/ticket/2812 | 19:57 |
| infinity | Oh joy, a bileto SRU. My favourite. | 19:59 |
| kyrofa | infinity, join the club man :P | 19:59 |
| kyrofa | Alright I hit publish | 20:04 |
| kyrofa | slangasek, I'm getting a "packaging diff requires ACK" even though I checked the ACK box... does someone else need to do that? | 20:12 |
| slangasek | kyrofa: you must have upload rights on the package to ack the packaging changes | 20:12 |
| kyrofa | Yep, not me then | 20:12 |
| kyrofa | Is that not redundant given an approved MP? | 20:13 |
| slangasek | no, it is not | 20:13 |
| kyrofa | I guess given the fact that multiple MPs could be included makes it possible to get weird results | 20:13 |
| slangasek | there is no guarantee that the people approving the MPs on the upstream project have upload rights to Ubuntu either | 20:14 |
| kyrofa | Ah of course | 20:14 |
| slangasek | in this case if it was approved by cjwatson, then yes - but bileto doesn't try to discover that | 20:14 |
| slangasek | publish clicked to publish click | 20:15 |
| kyrofa | Haha, thanks slangasek | 20:15 |
| kyrofa | What's next regarding the actual SRU process? I've never SRUd with bileto before | 20:16 |
| slangasek | next it goes into the unapproved queue for the release, and one of the SRU team members grumbles at having to review a package copy in the queue as it forces them to do a full download | 20:16 |
| kyrofa | Okay good deal | 20:17 |
| nacc | anyone have a suggestion on a python packaging question? dep8 tests are failing with the new celery, but I think the underlying issue is actually that the tests are no longer packaged in python{,3}-celery, because they moved from (in the upstream src) celery/tests to t/. So the python debhelper doesn't see them as being part of the celery/ directory and doesn't include them. Is it appropriate for me to | 20:19 |
| nacc | override the build step for this? Or is it ok to skip installing the tests (they are run at build time and pass) | 20:19 |
| slangasek | nacc: we do not normally expect tests to be packaged in order to be used for autopkgtest; they're usually run from the source tree of the package in question | 20:20 |
| nacc | slangasek: right, i think the old dep8 test used the as-installed version. So it'd be ok to, in theory, run them from the src tree using the as-installed package | 20:21 |
| slangasek | nacc: yes, that would be preferred | 20:21 |
| nacc | slangasek: ok, i'll work on tweaking those around, thanks! | 20:21 |
| nacc | slangasek: hrm, i think i'm seeing a broken pattern in dep8 python tests using pytest. A lot of packages do (roughly): for p in python-versions; do $p -m pytest tests/; done | 20:58 |
| nacc | slangasek: but that (per the upstream and manpage) adds '.' to the PYTHONPATH | 20:58 |
| nacc | slangasek: so it ends up, depending on the package layout, testing the source contents, not hte as-installed python lib | 20:58 |
| slangasek | score | 20:58 |
| nacc | slangasek: if instead, one does pytest or (pytest-3) tests/, the tests use the system python as-installed libs | 20:59 |
| nacc | slangasek: but then you can't make it a pretty loop (since the invocation name is different) | 20:59 |
| nacc | slangasek: i'm not sure if i'm right, but i definitely see different behavior with celery based upon how in invoke pytest | 20:59 |
| kyrofa | bdmurray, the newly patched click is now in the unapproved queue for xenial | 21:01 |
| nacc | mdeslaur: rbasak: fyi, upstream apache has unmarked http/2 as experimental in 2.4.26 | 22:23 |
| nacc | https://httpd.apache.org/docs/2.4/howto/http2.html#comments_section and https://httpd.apache.org/docs/2.4/mod/mod_http2.html | 22:23 |
| sarnold | sweet | 22:23 |
| nacc | and that version *should* be coming out soon, and i'm happy to update us to it this cycle for security team's comfort | 22:24 |
| nacc | sarnold: --^ just fyi | 22:24 |
| Unit193 | That's also the first version with openssl 1.1 support. | 22:24 |
| nacc | Unit193: good to know | 22:24 |
| nacc | slangasek: --^ i guess you'd also be interested then :) | 22:24 |
| Unit193 | (Though of course I'd prefer it not, because that'd hold Ubuntu back from switching this cycle.) | 22:25 |
| sarnold | hasn't debian done the work to transition all but three or four packages to openssl 1.1? | 22:26 |
| gsilvapt | Has anyone ever experienced issues with descripts' wrap-and-sort? When I run the command it does nothing and there are stuff to be organized | 22:26 |
| gsilvapt | And I'm running in the right directory | 22:26 |
| Unit193 | sarnold: They have libssl1.0-dev. | 22:26 |
| nacc | gsilvapt: it's python :) should be easy to debug? | 22:27 |
| gsilvapt | nacc, the problem is that I get literally nothing | 22:27 |
| gsilvapt | I run wrap-and-sort and nothing. even using the verbose option | 22:27 |
| Unit193 | nacc: If that's the case, I have another python breakage that I'd love to know what'sgoing on. :> | 22:27 |
| nacc | Unit193: :) | 22:28 |
| nacc | gsilvapt: which srcpkg (is it in the archive)? | 22:28 |
| gsilvapt | what do you mean? What package I'm trying to sort debian/control? | 22:28 |
| nacc | gsilvapt: yeah | 22:28 |
| Unit193 | sarnold: For kicks, http://paste.openstack.org/show/612474 | 22:29 |
| gsilvapt | I've tried in several but the one I'm currently trying to work on is lskat | 22:29 |
| nacc | gsilvapt: well, the b-d in that srcpkg are allready sorted and wrapped | 22:30 |
| gsilvapt | I'm locally testing the package | 22:31 |
| gsilvapt | I'm taking one line out of order | 22:31 |
| sarnold | Unit193: that looks like a depressing story | 22:31 |
| nacc | gsilvapt: works fine here (17.04) | 22:31 |
| sarnold | Unit193: this looked like a story with a happy ending https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 | 22:31 |
| ubottu | Debian bug 827061 in release.debian.org "transition: openssl" [Normal,Open] | 22:31 |
| nacc | gsilvapt: i edited one line out of order, ran the script and it put it back | 22:31 |
| gsilvapt | It's super odd. I have no clue what could be causing this | 22:32 |
| gsilvapt | and I definitely don't want to re-format this machine again | 22:32 |
| nacc | gsilvapt: are you on 17.04? | 22:32 |
| gsilvapt | 16.04 | 22:32 |
| nacc | gsilvapt: like i said, it's a pretty straightforward script, add some debugging and see? | 22:32 |
| nacc | gsilvapt: ok, let me spin up a container | 22:32 |
| Unit193 | sarnold: Depends really, curl was built against 1.0 due to its library, but does support 1.1. Some things do have support, if not just a simple rebuild then new upstream. Ruby 2.4.0 | 22:32 |
| Unit193 | Erm...Ruby is one of them, but Debian is skipping 2.4. | 22:33 |
| gsilvapt | how do I do that, nacc ? | 22:33 |
| nacc | gsilvapt: well i was assuming you knew python :) you can add print()s throughout, though | 22:33 |
| gsilvapt | I assume you're suggesting adding that to the script's source? | 22:34 |
| nacc | gsilvapt: yes | 22:34 |
| gsilvapt | I can give that a try . I need to find where it is located though | 22:34 |
| Unit193 | (And like alpine, just have to wait for my sponsor to come back, and I can push the new version that supports 1.0 and 1.1. Sadly, gvpe isn't there yet, so I'm really hoping Ubuntu stick with 1.0) | 22:34 |
| nacc | gsilvapt: `which wrap-and-sort` | 22:34 |
| sarnold | anonymous cvs, oy :) | 22:36 |
| Unit193 | I did https://bitbucket.org/unit193/gvpe, but I haven't kept up with it. You might remember it from me asking you about openssl incompatibilities a few releases back. There was a protocol issue that wouldn't allow it to communicate, never found out why. | 22:38 |
| slangasek | sarnold: don't worry, it's anonymous cvs with pgp-signed commits | 22:39 |
| mdeslaur | nacc: awesome! (re: apache2) | 22:40 |
| nacc | mdeslaur: i updated the bug as well | 22:40 |
| gsilvapt | nacc, the script stops at the get_files function. It's not working but it gives no error | 22:42 |
| sarnold | is this the kind of error were watching what it does via strace is useful? | 22:43 |
| nacc | gsilvapt: ok, still setting up a repro env | 22:44 |
| gsilvapt | ok, I can wait. Thank you and sorry for the trouble | 22:44 |
| nacc | gsilvapt: nothing to apologize for :) | 22:44 |
| nacc | gsilvapt: works fine in a 16.04 lxd | 22:46 |
| Unit193 | nacc: Ask him for the source package? | 22:46 |
| nacc | gsilvapt: http://paste.ubuntu.com/24852460/ | 22:47 |
| nacc | Unit193: i was testing the srcpkg gsilvapt mentioned (lskat) | 22:47 |
| Unit193 | Oooh,dang. Missed that part. | 22:47 |
| nacc | Unit193: np | 22:47 |
| nacc | gsilvapt: when you say it 'stops' at the get_files function ... what did you mean? | 22:48 |
| gsilvapt | nacc, I basically add print() in all variables and it stops running after the get_files function because it is not searching for files properly | 22:49 |
| gsilvapt | It sets an empty list as files | 22:49 |
| gsilvapt | If files are empty, then there's nothing else to run... | 22:49 |
| nacc | gsilvapt: yes, files is empty to start, the function attempts to find entries from SUPPORTED_FILES that match in the shell | 22:50 |
| nacc | gsilvapt: where are you running the command? | 22:50 |
| gsilvapt | source package parent directory | 22:51 |
| nacc | gsilvapt: oh | 22:51 |
| Unit193 | sarnold: Inconsequential PM? | 22:51 |
| nacc | gsilvapt: you need to run it from the srcpkg directory itself | 22:51 |
| gsilvapt | I'm running inside lskat/ | 22:52 |
| sarnold | Unit193: any time :) | 22:52 |
| gsilvapt | inside lskat, there's the debian/ folder | 22:52 |
| nacc | gsilvapt: oh ok, i misunderstood what you meant by 'parent directory' then | 22:52 |
| gsilvapt | It returns errors when running inside debian/ or outside lskat | 22:52 |
| nacc | gsilvapt: can you run the command (or alterations) as i showed in my paste? or use a paste and show me your alterations and the failure? | 22:53 |
| gsilvapt | Sure, I can copy/paste the script in a bin and show you the output. Potentially I'm doing the print() thing wrong but it seems unlikely | 22:53 |
| gsilvapt | nacc, do you prefer just a diff between my changes and the original file or do you wanna see the full script? | 22:55 |
| nacc | gsilvapt: well in theory we have the same script (wrap-and-sort) -- i meant can you do exactly the alteration i did in my paste (just moves one line) and then show wrap-and-sort failing to fix it? | 22:55 |
| gsilvapt | I didn't add many prints | 22:55 |
| nacc | gsilvapt: a diff is fine too -- my point is, i'm not seeing hte problem (in 16.04 or 17.04) | 22:55 |
| gsilvapt | I have a different debian/control file here but sure. Fixes were proposed but not yet merge. It doesn't matter because it doesn't work anyway. | 22:56 |
| gsilvapt | 1 second then. | 22:56 |
| gsilvapt | nacc, this is the debian/control file: https://paste.ubuntu.com/24852525/ Notice line 17 and 18 should swap. when I run wrap-and-sort -v, this is what I get (using the prints inside the script, otherwise it would return literally nothing): https://paste.ubuntu.com/24852530/ | 22:58 |
| nacc | gsilvapt: http://paste.ubuntu.com/24852550/ | 23:01 |
| nacc | gsilvapt: works fine in my 16.04 lxd | 23:01 |
| gsilvapt | Well, I can't figure out what is causing the issue | 23:01 |
| nacc | gsilvapt: try spinning up a lxd and reproducing it in a clean env | 23:02 |
| gsilvapt | According to the print thing, it can't find any files but they exist | 23:02 |
| nacc | gsilvapt: can you paste your change to the scrpit? | 23:02 |
| nacc | *script | 23:02 |
| gsilvapt | sure | 23:02 |
| gsilvapt | I don't think a diff is very understandable here. Can I just send a paste of the source? | 23:04 |
| nacc | gsilvapt: that's fine too | 23:04 |
| gsilvapt | diff or source? | 23:04 |
| gsilvapt | lol :)( | 23:04 |
| nacc | gsilvapt: a diff is always understandable :) | 23:04 |
| sarnold | diff -u is usually more understandible | 23:05 |
| sarnold | understandable too | 23:05 |
| gsilvapt | Sorry if I always get confused with regular diffs :P | 23:05 |
| gsilvapt | https://paste.ubuntu.com/24852571/ | 23:05 |
| nacc | sarnold: true :) -- i mentally assume everyone is doing -urpN due to kernel work | 23:05 |
| nacc | gsilvapt: yeah, do `diff -urpN old new | pastebinit` instead | 23:05 |
| nacc | *please | 23:06 |
| gsilvapt | Ahhh, this now looks cute | 23:06 |
| gsilvapt | lol | 23:06 |
| gsilvapt | I'm so noob, oh god... | 23:06 |
| gsilvapt | https://paste.ubuntu.com/24852585/ | 23:07 |
| nacc | gsilvapt: it's reversed, but that's ok | 23:07 |
| gsilvapt | I noticed, I should've switched the order but I guessed you'd understand | 23:09 |
| nacc | gsilvapt: http://paste.ubuntu.com/24852599/ can you apply this and re-run the command? | 23:09 |
| gsilvapt | nacc, https://paste.ubuntu.com/24852616/ | 23:11 |
| nacc | gsilvapt: hrm, are your files for some reason executable? | 23:13 |
| gsilvapt | The option is ticked, yes | 23:14 |
| nacc | gsilvapt: hrm? i mean the files in your scrpkg | 23:14 |
| nacc | gsilvapt: e.g., d/control itself | 23:15 |
| gsilvapt | The option to run d/control as executable is ticked, yes | 23:15 |
| gsilvapt | Allow executing file as program | 23:16 |
| infinity | nacc: Hint, "pastebinit -f diff" even gives it pretty colours. | 23:16 |
| nacc | infinity: oh nice! | 23:16 |
| nacc | infinity: thanks :) | 23:16 |
| nacc | gsilvapt: um, it shouldn't be | 23:17 |
| nacc | gsilvapt: you made that change? | 23:17 |
| nacc | gsilvapt: in the current ubuntu source package, the only executable in debian/ is 'rules' | 23:17 |
| gsilvapt | Not really | 23:17 |
| nacc | gsilvapt: `wrap-and-sort` will not wrap or sort any executable file | 23:17 |
| nacc | gsilvapt: i'm still not sure what you mean by ticked? cna you pastebin `ls -ahl debian/` ? | 23:18 |
| gsilvapt | Okay, makes sense. What did I do to have this setting all files as executables? | 23:18 |
| nacc | gsilvapt: i have no idea :) | 23:18 |
| gsilvapt | https://paste.ubuntu.com/24852653/ | 23:19 |
| nacc | gsilvapt: yeah that's ... wrong :) | 23:19 |
| gsilvapt | This has to be a configuration issue then because I experienced the same issue in all srcpckgs | 23:19 |
| gsilvapt | Did I mess up permissions and such? | 23:19 |
| nacc | gsilvapt: run `pull-lp-source lskat` in /tmp, say | 23:19 |
| nacc | gsilvapt: does it have the same permissions? | 23:19 |
| nacc | gsilvapt: do you have an odd umask set? | 23:19 |
| gsilvapt | AFAIK, no | 23:19 |
| nacc | gsilvapt: you can check with `umask` | 23:20 |
| gsilvapt | What value should I get? | 23:20 |
| nacc | default is 0022 | 23:20 |
| gsilvapt | I have 0002 | 23:20 |
| nacc | gsilvapt: did `pull-lp-source` produce hte same permissions? | 23:21 |
| gsilvapt | I don't have the same permissions when using pull-lp-source | 23:21 |
| gsilvapt | The other source was pulled from git | 23:22 |
| nacc | gsilvapt: for comparison: http://paste.ubuntu.com/24852666/ | 23:22 |
| nacc | gsilvapt: hrm, maybe a git config ? pulled from where? | 23:22 |
| gsilvapt | Yep, that's what I have | 23:22 |
| gsilvapt | Here: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/lskat/ | 23:22 |
| nacc | gsilvapt: and more directly to your paste earlier: http://paste.ubuntu.com/24852672/ | 23:23 |
| nacc | gsilvapt: with just a git clone? | 23:23 |
| infinity | Permissions look fine in git. | 23:23 |
| gsilvapt | yes | 23:23 |
| gsilvapt | I have nothing overriding permissions in my gitconfig | 23:23 |
| nacc | gsilvapt: a fresh git-clone also shows them executable? | 23:24 |
| gsilvapt | https://paste.ubuntu.com/24852686/ | 23:24 |
| gsilvapt | Oh, wait. I sent the wrong url | 23:25 |
| gsilvapt | Barr, too many tabs. Nevermind. Testing a new clone in a new folder. Potentially the issue is in the target directory I have been using | 23:25 |
| gsilvapt | Yeap, that has to be it | 23:26 |
| nacc | gsilvapt: ok :) | 23:26 |
| gsilvapt | So I tried cloning in my home directory, permissions worked fine. I have a folder in an external drive in which I have everything related to projects. It's the only way I can have multiple packages and not run out of space (small 128 gbs SSD + 1 TB HDD) | 23:27 |
| gsilvapt | How can I set up this folder in my HDD so that it doesn't mess up permissions? | 23:27 |
| infinity | gsilvapt: Is said external drive formatted with a sketchy filesystem, like vfat? | 23:37 |
| nacc | gsilvapt: what infinity said would be my next suspicion. | 23:38 |
| infinity | I suspect either it's a filesystem that doesn't support permissions at all (like fat/exfat/vfat), or a "foreign" filesystem that supports POSIX permissions via a bit of translation trickery but mount often decides the "defaults" should be something weird (NTFS and HFS+). | 23:40 |
| infinity | In the latter case, you can mount it differently and fix some of your woes, but honestly, you shouldn't do package build type work on a non-UNIX-friendly filesystem. Too many build systems make too many assumptions. | 23:41 |
| infinity | gsilvapt: If 'stat -c%T -f /path/to/build/area' is anything other than 'ext2/ext3', 'xfs', or 'btrfs', your success rate is likely to vary. | 23:46 |
| infinity | (Yes, there are a ton more fully POSIX-compliant filesystems the kernel supports, but those are the only three that get enough use that I'm comfortable recommending them) | 23:46 |
| infinity | Oh, and I guess zfs now. | 23:46 |
| * sarnold puts down the zfs-advocacy megaphone | 23:48 | |
| infinity | sarnold: I refuse to believe anything good has come from SunOS/Solaris since sendfile() | 23:50 |
| slangasek | haha | 23:51 |
| sarnold | infinity: but you should see all the blinking lights during a scrub! | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!