[02:25] nacc: I haven't had time to look at it yet [02:26] 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] oh heh i made some uploads just after a kde update [03:03] so i'll get my autopkgtest results next week then [07:14] e === CRogers_________ is now known as CRogers === CRogers_________ is now known as CRogers [12:24] 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] ? [13:19] hum [13:20] 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] ginggs: you can pull it from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2779/+packages [13:21] jamespage: ta [13:21] the urls to download the debs from https://launchpad.net/ubuntu/artful/+queue?queue_state=0&queue_text= don't work [13:22] they lead to "Lost something?" launchpad pages [13:22] e.g libebook-1.2-19_3.24.2-0ubuntu2_amd64.deb (69.7 KiB) NEW [13:22] -> https://launchpad.net/ubuntu/artful/+upload/15539512/+files/libebook-1.2-19_3.24.2-0ubuntu2_amd64.deb [13:31] cjwatson, wgrant, hey, do you know if that's a launchpad bug/known issue? [13:33] seb128: https://bugs.launchpad.net/launchpad/+bug/1697680 - reported by Didier earlier today and I pushed an MP to fix it [13:33] Launchpad bug 1697680 in Launchpad itself "Can't access binaries in NEW queue (source packages assets are fine though)" [Critical,In progress] [13:33] thanks [13:33] sorry for not checking launchpad reported bugs first, I should know better [13:33] 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] (I had IRC closed during lunch so didn't notice that didrocks hit that earlier) [13:34] hehe, yeah [13:34] (it was a consequence of the fix for bug 1663334) [13:34] bug 1663334 in Launchpad itself "make queue files dget'able" [Low,Fix released] https://launchpad.net/bugs/1663334 [13:34] archive admin reviews are not going strongly nowadays :-/ [13:34] seb128: (you can use queue fetch as a workaround) [13:34] ah, nice to see those becoming dget compatible! [13:34] I did get the binaries from the build page [13:35] or that, yes [13:35] they are just not marked as New so a bit of forth and back but it was ok :-) [13:35] thanks! [13:35] np [13:37] jamespage: i'm gonna try building with --no-parallel in case that makes the build log easier to follow [13:37] ginggs: ok it will take some time... [13:37] ginggs: thanks for the help [13:41] 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] jamespage: ^ === Tm_K is now known as Tm_T [14:35] cyphermox: please see bug 1624519 - I pinned it down. I think it's related to your merge of tasksel 3.34ubuntu1. [14:35] bug 1624519 in tasksel (Ubuntu) "Debian-defined tasks override Ubuntu-defined ones" [Undecided,Triaged] https://launchpad.net/bugs/1624519 [15:29] 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] 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] right now yakkety is ok, just because it's not an LTS release [15:35] actually, I'm not even sure if yakkety is ok [15:35] mdeslaur: oh! :) it's marked fix released by bdmurray [15:36] yeah, it's complicated...some of the yakkety universe packages have "Supported: 9m" [15:37] when in fact...they probably shouldn't [15:37] mdeslaur: ok, it seems like you have a solid handle on it :) [15:37] kind of :P [15:53] 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] (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] kyrofa: d/p only exists if there are patches to apply? [15:59] kyrofa: that is, if it's an upstream source change [15:59] kyrofa: is it? (or what is the patch specifically) [15:59] kyrofa: click is a native package. don't use debian/patches/ [16:00] kyrofa: just apply the thing directly [16:00] well, its versioning isn't technically native, but still [16:00] cjwatson: ah, makes sense [16:01] 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] 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] kyrofa: e.g. an MP that's based on the correct starting point [16:02] kyrofa: "Revert to r606" in your MP - why? Why not just branch from r606 in the first place? [16:02] 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] well, your branch, not your MP [16:03] cjwatson, because I don't know bzr :P . If I was to make a MP it would of course be cleaned up [16:03] kyrofa: It would be preferable to figure out how to land this using bileto if possible [16:03] cjwatson, okay [16:04] 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] cjwatson, excellent, I'll do that, thank you [16:29] 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] bug 1697730 in systemd (Ubuntu) "Long boot time due to systemd-networkd-wait-online.service failure" [Undecided,New] https://launchpad.net/bugs/1697730 [16:31] rbasak: bugs are being linked from the blueprint https://blueprints.launchpad.net/ubuntu/+spec/foundations-aa-migrating-to-netplan [16:31] rbasak: also, cyphermox [16:32] Linked, thanks. [16:32] wow, you re-vived blueprints ? [16:34] they've never been dead [16:34] well, others said differently :) [16:34] good to see someone still uses them === zyga is now known as zyga-fedora [17:01] 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] 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] cjwatson, so do I target xenial in bileto, then? [17:04] sudo CRASH_DB_URL=https://daisy.staging.ubuntu.com whoopsie -f' [17:04] tdaitx: ^^ that's what I really meant [17:05] 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] kyrofa: I believe [17:07] so [17:09] 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] kyrofa: which MP? I thought I just approved one [17:11] tdaitx: well if 'tag' not in report['Tags'] would avoid it [17:12] bdmurray, sure, I know, but does that mean that the other reports also duplicate the tag? [17:13] tdaitx: I don't know. Maybe apport should review the tags for duplicates or something. Its really not a big deal though. [17:14] 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] cjwatson, oh you were fast, thank you! === JanC_ is now known as JanC [17:28] 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] I ended up running apport-cli and then also installed apport-noui [17:29] as I was doing stuff in parallel apport might have run through the report twice or something [17:30] starting update-notifier-crash manually send the report to staging and there was no tag duplication, as expected [17:30] now I need to check why that service believes there is no X session =/ [17:31] tdaitx: That seems like a special corner case. [18:03] 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] fossfreedom: in https://launchpadlibrarian.net/323780787/buildlog_ubuntu-artful-amd64.budgie-desktop_10.3.1-2_BUILDING.txt.gz search for FAILED [18:06] Unknown option -lm [18:06] Run 'valac --help' to see a full list of available command line options. [18:06] fossfreedom: is that why? [18:07] yup - but I'm struggling why buildd is failing but the same source builds in an artful PPA and also artful pbuilder [18:08] fossfreedom: does your PPA have proposed enabled? or your pbuilder? [18:08] when did you build it in your artful ppa? [18:08] no [18:08] fossfreedom: the builder does [18:09] fossfreedom: and there is a new valac in artful-proposed :) [18:09] about 10 minutes ago jbicha [18:09] fossfreedom: 0.34.7-1 (a) and 0.36.3-1~gi1 (a-p) [18:09] ahhh [18:09] fossfreedom: so presumably the new valac has changed flags somehow? [18:09] fossfreedom: but enablign proposed should make it reproducible [18:10] valac is stricter so I expect several packages to FTBFS :( [18:10] okey dokey - will try that. [18:10] jbicha: ah, interesting [18:10] valac 0.36 is the same vala released with GNOME 3.24 a few months ago [18:11] there was also a glib2.0 update this morning [18:12] the glib update is still in -proposed [18:16] ok - thanks. Yeah - enabling proposed killed the build. [18:16] fossfreedom: gl! :) [19:11] fossfreedom: Looks like a meson/ninja (well, somewhere in the build system) bug to me. [19:11] fossfreedom: That -lm should be passed to the cc call, but not the valac call. [19:20] 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] infinity, agreed. very odd. Upstream confirms that they are using the same valac compiler version as in proposed. [19:21] 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] for instance, upstream is likely not using the latest glib development release [19:22] Based on the error, it can really only be meson or valac. [19:22] Either valac stopped ignoring the incorrect option or meson started injecting it into the valac call. [19:22] Both are new in -proposed. [19:23] oh I forgot that meson was stuck in -proposed too [19:55] 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] (cc cjwatson, although I expect you're asleep) [19:56] that is the next step. hopefully the ticket was set up correctly to target xenial, and not xenial overlay? [19:57] slangasek, indeed, xenial: https://bileto.ubuntu.com/#/ticket/2812 [19:59] Oh joy, a bileto SRU. My favourite. [19:59] infinity, join the club man :P [20:04] Alright I hit publish [20:12] 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] kyrofa: you must have upload rights on the package to ack the packaging changes [20:12] Yep, not me then [20:13] Is that not redundant given an approved MP? [20:13] no, it is not [20:13] I guess given the fact that multiple MPs could be included makes it possible to get weird results [20:14] there is no guarantee that the people approving the MPs on the upstream project have upload rights to Ubuntu either [20:14] Ah of course [20:14] in this case if it was approved by cjwatson, then yes - but bileto doesn't try to discover that [20:15] publish clicked to publish click [20:15] Haha, thanks slangasek [20:16] What's next regarding the actual SRU process? I've never SRUd with bileto before [20:16] 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] Okay good deal [20:19] 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] 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] 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] 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] nacc: yes, that would be preferred [20:21] slangasek: ok, i'll work on tweaking those around, thanks! [20:58] 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] slangasek: but that (per the upstream and manpage) adds '.' to the PYTHONPATH [20:58] slangasek: so it ends up, depending on the package layout, testing the source contents, not hte as-installed python lib [20:58] score [20:59] slangasek: if instead, one does pytest or (pytest-3) tests/, the tests use the system python as-installed libs [20:59] slangasek: but then you can't make it a pretty loop (since the invocation name is different) [20:59] 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] bdmurray, the newly patched click is now in the unapproved queue for xenial [22:23] mdeslaur: rbasak: fyi, upstream apache has unmarked http/2 as experimental in 2.4.26 [22:23] 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] sweet [22:24] 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] sarnold: --^ just fyi [22:24] That's also the first version with openssl 1.1 support. [22:24] Unit193: good to know [22:24] slangasek: --^ i guess you'd also be interested then :) [22:25] (Though of course I'd prefer it not, because that'd hold Ubuntu back from switching this cycle.) [22:26] hasn't debian done the work to transition all but three or four packages to openssl 1.1? [22:26] 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] And I'm running in the right directory [22:26] sarnold: They have libssl1.0-dev. [22:27] gsilvapt: it's python :) should be easy to debug? [22:27] nacc, the problem is that I get literally nothing [22:27] I run wrap-and-sort and nothing. even using the verbose option [22:27] nacc: If that's the case, I have another python breakage that I'd love to know what'sgoing on. :> [22:28] Unit193: :) [22:28] gsilvapt: which srcpkg (is it in the archive)? [22:28] what do you mean? What package I'm trying to sort debian/control? [22:28] gsilvapt: yeah [22:29] sarnold: For kicks, http://paste.openstack.org/show/612474 [22:29] I've tried in several but the one I'm currently trying to work on is lskat [22:30] gsilvapt: well, the b-d in that srcpkg are allready sorted and wrapped [22:31] I'm locally testing the package [22:31] I'm taking one line out of order [22:31] Unit193: that looks like a depressing story [22:31] gsilvapt: works fine here (17.04) [22:31] Unit193: this looked like a story with a happy ending https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 [22:31] Debian bug 827061 in release.debian.org "transition: openssl" [Normal,Open] [22:31] gsilvapt: i edited one line out of order, ran the script and it put it back [22:32] It's super odd. I have no clue what could be causing this [22:32] and I definitely don't want to re-format this machine again [22:32] gsilvapt: are you on 17.04? [22:32] 16.04 [22:32] gsilvapt: like i said, it's a pretty straightforward script, add some debugging and see? [22:32] gsilvapt: ok, let me spin up a container [22:32] 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] Erm...Ruby is one of them, but Debian is skipping 2.4. [22:33] how do I do that, nacc ? [22:33] gsilvapt: well i was assuming you knew python :) you can add print()s throughout, though [22:34] I assume you're suggesting adding that to the script's source? [22:34] gsilvapt: yes [22:34] I can give that a try . I need to find where it is located though [22:34] (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] gsilvapt: `which wrap-and-sort` [22:36] anonymous cvs, oy :) [22:38] 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] sarnold: don't worry, it's anonymous cvs with pgp-signed commits [22:40] nacc: awesome! (re: apache2) [22:40] mdeslaur: i updated the bug as well [22:42] nacc, the script stops at the get_files function. It's not working but it gives no error [22:43] is this the kind of error were watching what it does via strace is useful? [22:44] gsilvapt: ok, still setting up a repro env [22:44] ok, I can wait. Thank you and sorry for the trouble [22:44] gsilvapt: nothing to apologize for :) [22:46] gsilvapt: works fine in a 16.04 lxd [22:46] nacc: Ask him for the source package? [22:47] gsilvapt: http://paste.ubuntu.com/24852460/ [22:47] Unit193: i was testing the srcpkg gsilvapt mentioned (lskat) [22:47] Oooh,dang. Missed that part. [22:47] Unit193: np [22:48] gsilvapt: when you say it 'stops' at the get_files function ... what did you mean? [22:49] 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] It sets an empty list as files [22:49] If files are empty, then there's nothing else to run... [22:50] gsilvapt: yes, files is empty to start, the function attempts to find entries from SUPPORTED_FILES that match in the shell [22:50] gsilvapt: where are you running the command? [22:51] source package parent directory [22:51] gsilvapt: oh [22:51] sarnold: Inconsequential PM? [22:51] gsilvapt: you need to run it from the srcpkg directory itself [22:52] I'm running inside lskat/ [22:52] Unit193: any time :) [22:52] inside lskat, there's the debian/ folder [22:52] gsilvapt: oh ok, i misunderstood what you meant by 'parent directory' then [22:52] It returns errors when running inside debian/ or outside lskat [22:53] 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] 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] nacc, do you prefer just a diff between my changes and the original file or do you wanna see the full script? [22:55] 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] I didn't add many prints [22:55] gsilvapt: a diff is fine too -- my point is, i'm not seeing hte problem (in 16.04 or 17.04) [22:56] 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] 1 second then. [22:58] 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] gsilvapt: http://paste.ubuntu.com/24852550/ [23:01] gsilvapt: works fine in my 16.04 lxd [23:01] Well, I can't figure out what is causing the issue [23:02] gsilvapt: try spinning up a lxd and reproducing it in a clean env [23:02] According to the print thing, it can't find any files but they exist [23:02] gsilvapt: can you paste your change to the scrpit? [23:02] *script [23:02] sure [23:04] I don't think a diff is very understandable here. Can I just send a paste of the source? [23:04] gsilvapt: that's fine too [23:04] diff or source? [23:04] lol :)( [23:04] gsilvapt: a diff is always understandable :) [23:05] diff -u is usually more understandible [23:05] understandable too [23:05] Sorry if I always get confused with regular diffs :P [23:05] https://paste.ubuntu.com/24852571/ [23:05] sarnold: true :) -- i mentally assume everyone is doing -urpN due to kernel work [23:05] gsilvapt: yeah, do `diff -urpN old new | pastebinit` instead [23:06] *please [23:06] Ahhh, this now looks cute [23:06] lol [23:06] I'm so noob, oh god... [23:07] https://paste.ubuntu.com/24852585/ [23:07] gsilvapt: it's reversed, but that's ok [23:09] I noticed, I should've switched the order but I guessed you'd understand [23:09] gsilvapt: http://paste.ubuntu.com/24852599/ can you apply this and re-run the command? [23:11] nacc, https://paste.ubuntu.com/24852616/ [23:13] gsilvapt: hrm, are your files for some reason executable? [23:14] The option is ticked, yes [23:14] gsilvapt: hrm? i mean the files in your scrpkg [23:15] gsilvapt: e.g., d/control itself [23:15] The option to run d/control as executable is ticked, yes [23:16] Allow executing file as program [23:16] nacc: Hint, "pastebinit -f diff" even gives it pretty colours. [23:16] infinity: oh nice! [23:16] infinity: thanks :) [23:17] gsilvapt: um, it shouldn't be [23:17] gsilvapt: you made that change? [23:17] gsilvapt: in the current ubuntu source package, the only executable in debian/ is 'rules' [23:17] Not really [23:17] gsilvapt: `wrap-and-sort` will not wrap or sort any executable file [23:18] gsilvapt: i'm still not sure what you mean by ticked? cna you pastebin `ls -ahl debian/` ? [23:18] Okay, makes sense. What did I do to have this setting all files as executables? [23:18] gsilvapt: i have no idea :) [23:19] https://paste.ubuntu.com/24852653/ [23:19] gsilvapt: yeah that's ... wrong :) [23:19] This has to be a configuration issue then because I experienced the same issue in all srcpckgs [23:19] Did I mess up permissions and such? [23:19] gsilvapt: run `pull-lp-source lskat` in /tmp, say [23:19] gsilvapt: does it have the same permissions? [23:19] gsilvapt: do you have an odd umask set? [23:19] AFAIK, no [23:20] gsilvapt: you can check with `umask` [23:20] What value should I get? [23:20] default is 0022 [23:20] I have 0002 [23:21] gsilvapt: did `pull-lp-source` produce hte same permissions? [23:21] I don't have the same permissions when using pull-lp-source [23:22] The other source was pulled from git [23:22] gsilvapt: for comparison: http://paste.ubuntu.com/24852666/ [23:22] gsilvapt: hrm, maybe a git config ? pulled from where? [23:22] Yep, that's what I have [23:22] Here: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/lskat/ [23:23] gsilvapt: and more directly to your paste earlier: http://paste.ubuntu.com/24852672/ [23:23] gsilvapt: with just a git clone? [23:23] Permissions look fine in git. [23:23] yes [23:23] I have nothing overriding permissions in my gitconfig [23:24] gsilvapt: a fresh git-clone also shows them executable? [23:24] https://paste.ubuntu.com/24852686/ [23:25] Oh, wait. I sent the wrong url [23:25] 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] Yeap, that has to be it [23:26] gsilvapt: ok :) [23:27] 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] How can I set up this folder in my HDD so that it doesn't mess up permissions? [23:37] gsilvapt: Is said external drive formatted with a sketchy filesystem, like vfat? [23:38] gsilvapt: what infinity said would be my next suspicion. [23:40] 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] 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] 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] (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] Oh, and I guess zfs now. [23:48] * sarnold puts down the zfs-advocacy megaphone [23:50] sarnold: I refuse to believe anything good has come from SunOS/Solaris since sendfile() [23:51] haha [23:51] infinity: but you should see all the blinking lights during a scrub!