[02:25] <mdeslaur> nacc: I haven't had time to look at it yet
[02:26] <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
[03:03] <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
[07:14] <lathiat> e
[12:24] <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> ?
[13:19] <seb128> hum
[13:20] <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:21] <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:22] <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:31] <seb128> cjwatson, wgrant, hey, do you know if that's a launchpad bug/known issue?
[13:33] <cjwatson> seb128: https://bugs.launchpad.net/launchpad/+bug/1697680 - reported by Didier earlier today and I pushed an MP to fix it
[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:34] <seb128> hehe, yeah
[13:34] <cjwatson> (it was a consequence of the fix for bug 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:35] <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:37] <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:41] <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: ^
[14:35] <rbasak> cyphermox: please see bug 1624519 - I pinned it down. I think it's related to your merge of tasksel 3.34ubuntu1.
[15:29] <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:34] <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:35] <mdeslaur> actually, I'm not even sure if yakkety is ok
[15:35] <nacc> mdeslaur: oh! :) it's marked fix released by bdmurray
[15:36] <mdeslaur> yeah, it's complicated...some of the yakkety universe packages have "Supported: 9m"
[15:37] <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:53] <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:54] <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:59] <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/
[16:00] <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:01] <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:02] <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:03] <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:04] <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:29] <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:31] <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:32] <rbasak> Linked, thanks.
[16:32] <ogra> wow, you re-vived blueprints ?
[16:34] <slangasek> they've never been dead
[16:34] <ogra> well, others said differently :)
[16:34] <ogra> good to see someone still uses them
[17:01] <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:03] <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:04] <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:05] <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:07] <cjwatson> kyrofa: I believe
[17:07] <cjwatson> so
[17:09] <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:11] <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:12] <tdaitx> bdmurray, sure, I know, but does that mean that the other reports also duplicate the tag?
[17:13] <bdmurray> tdaitx: I don't know. Maybe apport should review the tags for duplicates or something. Its really not a big deal though.
[17:14] <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:16] <kyrofa> cjwatson, oh you were fast, thank you!
[17:28] <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:29] <tdaitx> as I was doing stuff in parallel apport might have run through the report twice or something
[17:30] <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:31] <bdmurray> tdaitx: That seems like a special corner case.
[18:03] <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:06] <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:07] <fossfreedom> yup - but I'm struggling why buildd is failing but the same source builds in an artful PPA and also artful pbuilder
[18:08] <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:09] <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:10] <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:11] <jbicha> there was also a glib2.0 update this morning
[18:12] <jbicha> the glib update is still in -proposed
[18:16] <fossfreedom> ok - thanks.  Yeah - enabling proposed killed the build.
[18:16] <nacc> fossfreedom: gl! :)
[19:11] <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:20] <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:21] <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:22] <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:23] <jbicha> oh I forgot that meson was stuck in -proposed too
[19:55] <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:56] <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:57] <kyrofa> slangasek, indeed, xenial: https://bileto.ubuntu.com/#/ticket/2812
[19:59] <infinity> Oh joy, a bileto SRU.  My favourite.
[19:59] <kyrofa> infinity, join the club man :P
[20:04] <kyrofa> Alright I hit publish
[20:12] <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:13] <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:14] <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:15] <slangasek> publish clicked to publish click
[20:15] <kyrofa> Haha, thanks slangasek
[20:16] <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:17] <kyrofa> Okay good deal
[20:19] <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:20] <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:21] <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:58] <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:59] <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
[21:01] <kyrofa> bdmurray, the newly patched click is now in the unapproved queue for xenial
[22:23] <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:24] <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:25] <Unit193> (Though of course I'd prefer it not, because that'd hold Ubuntu back from switching this cycle.)
[22:26] <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:27] <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:28] <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:29] <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:30] <nacc> gsilvapt: well, the b-d in that srcpkg are allready sorted and wrapped
[22:31] <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] <nacc> gsilvapt: i edited one line out of order, ran the script and it put it back
[22:32] <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:33] <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:34] <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:36] <sarnold> anonymous cvs, oy :)
[22:38] <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:39] <slangasek> sarnold: don't worry, it's anonymous cvs with pgp-signed commits
[22:40] <mdeslaur> nacc: awesome! (re: apache2)
[22:40] <nacc> mdeslaur: i updated the bug as well
[22:42] <gsilvapt> nacc, the script stops at the get_files function. It's not working but it gives no error
[22:43] <sarnold> is this the kind of error were watching what it does via strace is useful?
[22:44] <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:46] <nacc> gsilvapt: works fine in a 16.04 lxd
[22:46] <Unit193> nacc: Ask him for the source package?
[22:47] <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:48] <nacc> gsilvapt: when you say it 'stops' at the get_files function ... what did you mean?
[22:49] <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:50] <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:51] <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:52] <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:53] <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:55] <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:56] <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:58] <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/
[23:01] <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:02] <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:04] <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:05] <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:06] <nacc> *please
[23:06] <gsilvapt> Ahhh, this now looks cute
[23:06] <gsilvapt> lol
[23:06] <gsilvapt> I'm so noob, oh god...
[23:07] <gsilvapt> https://paste.ubuntu.com/24852585/
[23:07] <nacc> gsilvapt: it's reversed, but that's ok
[23:09] <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:11] <gsilvapt> nacc, https://paste.ubuntu.com/24852616/
[23:13] <nacc> gsilvapt: hrm, are your files for some reason executable?
[23:14] <gsilvapt> The option is ticked, yes
[23:14] <nacc> gsilvapt: hrm? i mean the files in your scrpkg
[23:15] <nacc> gsilvapt: e.g., d/control itself
[23:15] <gsilvapt> The option to run d/control as executable is ticked, yes
[23:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <nacc> gsilvapt: a fresh git-clone also shows them executable?
[23:24] <gsilvapt> https://paste.ubuntu.com/24852686/
[23:25] <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:26] <gsilvapt> Yeap, that has to be it
[23:26] <nacc> gsilvapt: ok :)
[23:27] <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:37] <infinity> gsilvapt: Is said external drive formatted with a sketchy filesystem, like vfat?
[23:38] <nacc> gsilvapt: what infinity said would be my next suspicion.
[23:40] <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:41] <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:46] <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:48]  * sarnold puts down the zfs-advocacy megaphone
[23:50] <infinity> sarnold: I refuse to believe anything good has come from SunOS/Solaris since sendfile()
[23:51] <slangasek> haha
[23:51] <sarnold> infinity: but you should see all the blinking lights during a scrub!