Chris Lamb dixit:
>Another solution might be to let strip-nondeterminism handle
>these Zip files. There is prior art for this in that we handle other
>Zip files with non-.zip extensions:
Interesting, but I’d rather fix the root cause, considering that
this kind of container building will
Hi Chris,
>> … nowhere in there does it say any Unix permissions.
>>
>> Are those really stored in the PKZIP archive, or […]
>
>Yes, try zipinfo(1):
oh, thanks, didn’t know that.
>> OK, this really is unfun.
>
>Hopefully we can keep this list friendly and welcoming to all
>regardless of your
Chris Lamb wrote:
> > Yes, of course. I was a bit frustrated in my inability to
> > figure out where the permission bits come from.
>
> Oh I can relate, don't worry...
Another solution might be to let strip-nondeterminism handle
these Zip files. There is prior art for this in that we handle
Hi Thorsten,
> > Hopefully we can keep this list friendly and welcoming to all
> > regardless of your understandable frustration.
>
> Yes, of course. I was a bit frustrated in my inability to
> figure out where the permission bits come from.
Oh I can relate, don't worry...
Thanks for bringing
Thorsten,
> … nowhere in there does it say any Unix permissions.
>
> Are those really stored in the PKZIP archive, or […]
Yes, try zipinfo(1):
$ zipinfo -v path/to/Advanced.workspace | fgrep 'Unix file'
Unix file attributes (100644 octal):-rw-r--r--
Unix file attributes
>from the origtgz (and thus should have the correct permissions,
>unless tar does not extract them right).
I guess it doesn’t:
(pbuild1029-sid/amd64)root@tglase:/tmp/buildd/musescore-3.2.3+dfsg1 # ll
share/workspaces/
total 168
-rw-rw-r-- 1 pbuilder pbuilder 136628 Jul 6 2019 Advanced.xml
On 2020-02-06, Thorsten Glaser wrote:
>>Indeed, an extremely quick glance at your package suggests that whilst
>>dh(1) itself resets to he umask, musescore is calling dh_auto_build
>>manually:
>
> that, yes, but dh_auto_build is called from dh, so it should
> inherit its umask. The top-level
Hi Chris,
>Indeed, an extremely quick glance at your package suggests that whilst
>dh(1) itself resets to he umask, musescore is calling dh_auto_build
>manually:
that, yes, but dh_auto_build is called from dh, so it should
inherit its umask. The top-level targets that dpkg-buildpackage
calls are
