Re: Bug#928657: ITP: golang-github-naegelejd-go-acl -- Golang POSIX 1e ACL bindings

[Felixoid]

+ submit, debian-devel, debian-go

пт, 10 мая 2019 г. в 09:31, Felixoid :

> Hello. Did I miss something here? What would be the next step to submit
> the repo https://github.com/Felixoid/golang-github-naegelejd-go-acl to
> the created salsa
> https://salsa.debian.org/go-team/packages/golang-github-naegelejd-go-acl
> as well?
>
> I've created a guest user felixoid-guest and couldn't push into repo
> because of lack of permissions:
> > GitLab: You are not allowed to push code to this project.
>
> Best regards,
> Mikhail.
>
> ср, 8 мая 2019 г. в 14:48, Mikhail f. Shiryaev :
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Mikhail f. Shiryaev 
>>
>> * Package name: golang-github-naegelejd-go-acl
>>   Version : 0.0~git20160113.f33f861-1
>>   Upstream Author : Joseph Naegele
>> * URL : https://github.com/naegelejd/go-acl
>> * License : MIT
>>   Programming Lang: Go
>>   Description : Golang POSIX 1e ACL bindings
>>
>>  go-acl Golang POSIX.1e ACL bindings.  Essentially bindings to
>>  /usr/include/sys/acl.h notesmac os x Mac OS X does not seem to support
>>  basic POSIX1.e ACLs. They do provide the POSIX API for NFSv4 ACLs. It
>>  would be nice for this package to also support NFSv4 ACLs.  freebsd By
>>  default, FreeBSD does not enable POSIX1.e ACLs on the root partition. To
>>  enable them, reboot into single-user mode and execute: $ tunefs -a enable
>>  $ reboot
>>  .
>>  Source: https://www.freebsd.org/doc/handbook/fs-acl.html info The
>>  IEEE POSIX.1e specification describes five security extensions to the
>>  base POSIX.1 API: Access Control Lists (ACLs), Auditing, Capabilities,
>>  Mandatory Access Control, and Information Flow Labels.  The specificaiton
>>  was abandoned before finalization, however most UNIX-like operating
>>  systems have some form of ACL implementation.
>>  .
>>  Source: http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=posix1e
>>  copying Copyright (c) 2015 Joseph Naegele. See LICENSE file.
>>
>

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Holger Levsen]

On Fri, May 10, 2019 at 10:59:26AM +0700, Ondřej Surý wrote:
> > I understand that this was an issue when prototyping, but have you used ar
> > to manipulate .deb archives even once this millenium?  By now, the deb
> > format is common, while ar is an obscure implementation detail.
> I did used ar to unpack .deb several times, usually when I had to pull a file
> on a non-Debian system (or when I could not remember the dpkg-deb syntax
> and I was lazy, but that doesn’t count :)
 
same here. and not only this millenium, but also this decade :)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Thomas Goirand]

On 5/9/19 6:25 PM, Andrej Shadura wrote:
> Hi,
> 
> 
> On Thu, 9 May 2019, 15:57 Ian Jackson,  > wrote:
> 
> Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> > `ar` needs to be replaced for the file size limitation mentioned
> in the
> > initial mail: ar represents file size as a 10 digit decimal number[1]
> > which limits the members (control.tar.*, data.tar.*) to ~10G.
> ...
> > Replacing `ar` is an incompatible format change.  So if we already do
> > an incompatible change, it is an appropriate time to bundle any other
> > incompatible changes (if there are any).  That is why I suggested that
> > it might be useful to also replace the `tar` archives with another
> > format.
> 
> As has been pointed out, we have done many incompatible format
> changes.  Every new compression algorithm is one.  It isn't really a
> big problem, when managed properly.
> 
> So I strongly disagree.  The archive size limit is getting more and
> more annoying.  We should not let fixing that be entangled with some
> random other nice-to-haves.
> 
> Personally I still like my multi-ar-member proposal here
>   https://lists.debian.org/debian-dpkg/2016/05/msg00027.html
> Guillem didn't seem entirely unreceptive but nothing came of it.
> 
> 
> 
> How about the format opkg used for some time, which is a .deb file but
> with tar as the outer container format instead of ar?

This is a very bad idea. When installing a large amount of packages, apt
needs to uncompress all control.tar.gz files so it can get the config
and templates of debconf. With tar, meaning without an index, one may
need to uncompress the whole of the .deb file in order to extract just a
tiny portion of it. This could potentially be super long (think: a
dist-upgrade with so many packages...).

Cheers,

Thomas Goirand (zigo)

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Adam Borowski]

On Fri, May 10, 2019 at 11:30:14AM +0200, Andrej Shadura wrote:
> On Fri, 10 May 2019 at 06:47, Adam Borowski  wrote:
> > > So I think Andrej is on the spot, and we should just switch from ar(5)
> > > to tar(5) as the container
> >
> > I would heavily advise against archive-in-archive.  Especially not tar, with
> > its block madness.  The blocks disappear when compressed but you're not
> > going to compress the outer layer.  Also, you can't shed the outer layer of
> > tar without a filter.
> 
> You may be amazed, but that’s actually what ipkg used to do (and opkg
> still supports):
> 
> [1]: 
> https://web.archive.org/web/20100823030002/http://www.handhelds.org/moin/moin.cgi/Ipkg#head-133c8da00cf5d277becb22540e75e6fbe5536902
> 
> [2]: 
> https://git.yoctoproject.org/cgit/cgit.cgi/opkg/tree/libopkg/opkg_archive.c#n523

This code does a filter, via libarchive callbacks.  I've just implemented
the very same thing myself.  Libarchive is quite smart and avoids copying
the data around when possible, but the overhead of block callbacks is still
significant.

It's not possible to peel away the outer layer as tar doesn't guarantee the
data is contiguous in the file.  It supports sparse files, etc.

> (I think it would be quite ironic if Debian switches to a package
> format derived from Debian to be used elsewhere.)

Why?  Stealing the work from derivatives means the community at large is
more effective.  Code/idea/design reuse is good.


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ NADIE anticipa la inquisición de españa!
⠈⠳⣄

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Ian Jackson]

Adam Borowski writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> It's not possible to peel away the outer layer as tar doesn't guarantee the
> data is contiguous in the file.  It supports sparse files, etc.

If we were to use tar as a format we would support only a restricted
subset of tar, obviously.  For comparison, we don't support anywhere
near all `ar' formats, to the point that it is awkward to *create* a
legal .deb with a normal ar utility.  I think that is OK.

The advantages of my multi-ar-members-for-large-data-file proposal,
over switching to tar:
  * recognised as a .deb by all existing sniffing tools etc.
  * only .debs with large data files are incompatible with
old dpkg-deb
  * given a .deb with large data files, if you don't need the
data archive old tools will still work (dpkg -I, say).
  * reduced code churn

The disadvantages are:
  * Somewhat increased complexity in .deb decoding software

I think the increased complexity is worth these other benefits.

I was surprised to see people saying that they were still unpacking
.debs occasionally with ar.  I guess my decision back in 199mumble is
vindicated...  That definitely means we should keep the property that
a .deb can be unpacked with non-Debian-specific shell tools.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Michael Stone]

On Fri, May 10, 2019 at 05:18:18AM +0200, Guillem Jover wrote:

be updated anyway to support any new format. It also destroys some of the
nice properties of the 2.x format, namely:

 - Not requiring special tools to build/extract.


This is really not a property worth preserving. I think it would be 
fairly easy to get significant performance improvements if we dropped 
the archive nesting, and all it would cost is losing a bullet point that 
nobody really cares about all that much. I remember when this was one of 
the "reasons" to advocate .deb over .rpm but in the real world people
just apt install rpm and the anecdotes about this one time somebody 
wanted to unpack a deb on an ancient sunos box aren't worth slowing down 
every install until the end of time.

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Sam Hartman]

> "Michael" == Michael Stone  writes:

Michael> On Fri, May 10, 2019 at 05:18:18AM +0200, Guillem Jover wrote:
>> be updated anyway to support any new format. It also destroys
>> some of the nice properties of the 2.x format, namely:
>> 
>> - Not requiring special tools to build/extract.

Michael> This is really not a property worth preserving. I think it
Michael> would be fairly easy to get significant performance
Michael> improvements if we dropped the archive nesting, and all it
Michael> would cost is losing a bullet point that nobody really
Michael> cares about all that much. I remember when this was one of
Michael> the "reasons" to advocate .deb over .rpm but in the real
Michael> world people just apt install rpm and the anecdotes about
Michael> this one time somebody wanted to unpack a deb on an ancient
Michael> sunos box aren't worth slowing down every install until the
Michael> end of time.

I've certainly heard people describe our use of both ar and tar as an
architectural minus especially on embedded platforms just because the
dependency set of dpkg needed to be larger.

I don't know how big of a concern that still is, but it does seem
strange to use multiple different archiving technologies in the same
format today.

Re: Bug#928657: ITP: golang-github-naegelejd-go-acl -- Golang POSIX 1e ACL bindings

[Shengjing Zhu]

Hi

On Fri, May 10, 2019 at 4:06 PM Felixoid  wrote:
>
> + submit, debian-devel, debian-go

sub...@bugs.debian.org is meant for creating a new bug..

>
> пт, 10 мая 2019 г. в 09:31, Felixoid :
>>
>> Hello. Did I miss something here? What would be the next step to submit the 
>> repo https://github.com/Felixoid/golang-github-naegelejd-go-acl to the 
>> created salsa 
>> https://salsa.debian.org/go-team/packages/golang-github-naegelejd-go-acl as 
>> well?
>>
>> I've created a guest user felixoid-guest and couldn't push into repo because 
>> of lack of permissions:
>> > GitLab: You are not allowed to push code to this project.

You could do it with dh-make-golang, you can get more info at
https://go-team.pages.debian.net/packaging.html#_using_dh_make_golang

-- 
Shengjing Zhu

Re: .deb format: let's use 0.939, zstd, drop bzip2

[W. Martin Borgert]

Quoting Sam Hartman :

I've certainly heard people describe our use of both ar and tar as an
architectural minus especially on embedded platforms just because the
dependency set of dpkg needed to be larger.


On my embedded systems, I don't have ar installed, only tar.
I assume, that dpkg speaks ar natively?


I don't know how big of a concern that still is, but it does seem
strange to use multiple different archiving technologies in the same
format today.


Anything wrong with one .zip, just like .jar or .odf?

Ghy

[Lovell]

Sent from my iPhone 

Re: Re: SAGE packages for Debian

[Lovell]

Global media blogs games apps google maps hello world media world largest 
social media hate crime 

Sent from my iPhone 

I

[Lovell]

Sent from my iPhone app developers globally promoting media globally promoting 
global abuse harassment defamation hate crime 

Global media abuse harassment defamation blogs

[Lovell]

Sent from my iPhone 

T

[Lovell]

Sent from my iPhone 

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Adam Borowski]

On Fri, May 10, 2019 at 02:49:01PM +0200, W. Martin Borgert wrote:
> Quoting Sam Hartman :
> > I've certainly heard people describe our use of both ar and tar as an
> > architectural minus especially on embedded platforms just because the
> > dependency set of dpkg needed to be larger.
> 
> On my embedded systems, I don't have ar installed, only tar.
> I assume, that dpkg speaks ar natively?

Both yes and no, of course. :p

> > I don't know how big of a concern that still is, but it does seem
> > strange to use multiple different archiving technologies in the same
> > format today.
> 
> Anything wrong with one .zip, just like .jar or .odf?

/usr on the box I'm sitting at:
* zip the program: dies horribly due to /usr/lib/llvm-7/build/ symlink
  loops.
* zip:
1891345142 bytes
* zip-the-concept (individually compressed files), xz
1516943024 bytes
* tar.xz
1092591508 bytes

Linux source:
* zip:
213820843 bytes
* individually compressed files, xz
180997203 bytes
* tar.xz:
104318396 bytes

So no, I don't want zip, nor even a randomly accessible format.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Marc Haber]

On Fri, 10 May 2019 07:42:52 -0400, Michael Stone 
wrote:
>This is really not a property worth preserving.

I disagree. I frequently unpack .debs on .rpm Systems, especially when
I want to see how the rather nice behavior that I find in Debian is
implemented to see whether I can implant that hotness into the .rpm
world.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Michael Stone]

On Fri, May 10, 2019 at 05:42:45PM +0200, Marc Haber wrote:

On Fri, 10 May 2019 07:42:52 -0400, Michael Stone 
wrote:

This is really not a property worth preserving.


I disagree. I frequently unpack .debs on .rpm Systems, especially when
I want to see how the rather nice behavior that I find in Debian is
implemented to see whether I can implant that hotness into the .rpm
world.


And there are easily installed tools which I have every confidence will 
be updated to work with any new format so your ability to do so won't be 
diminished in the least. Just like I can unpack rpms on a deb system.

Re: .deb format: let's use 0.939, zstd, drop bzip2

[James Cloos]

>> I did used ar to unpack .deb several times, usually when I had to pull a file
>> on a non-Debian system (or when I could not remember the dpkg-deb syntax
>> and I was lazy, but that doesn’t count :)
 
> same here. and not only this millenium, but also this decade :)

ar(1) is the only thing I've ever used to look inside a deb(5) file.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Ian Jackson]

W. Martin Borgert writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> Quoting Sam Hartman :
> > I've certainly heard people describe our use of both ar and tar as an
> > architectural minus especially on embedded platforms just because the
> > dependency set of dpkg needed to be larger.
> 
> On my embedded systems, I don't have ar installed, only tar.
> I assume, that dpkg speaks ar natively?

dpkg-deb has a built-in decoder for the subset of ar that is used for
deb(5).  One reason I chose ar rather than tar is that handwriting a
decoder for ar was much simpler than for tar.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: .deb format: let's use 0.939, zstd, drop bzip2

[John Goerzen]

On Fri, May 10 2019, Ian Jackson wrote:

>> On my embedded systems, I don't have ar installed, only tar.
>> I assume, that dpkg speaks ar natively?
>
> dpkg-deb has a built-in decoder for the subset of ar that is used for
> deb(5).  One reason I chose ar rather than tar is that handwriting a
> decoder for ar was much simpler than for tar.

Plus, of course, when discussing tar, there is always the "which tar
format do you mean?" question.

https://manpages.debian.org/stretch/libarchive-dev/tar.5.en.html

I should note that dpkg does have a maximum file size limit that's
rather lower than the ar limit, due to its interpretation of tar
headers.  I believe I filed a bug on this but I'm not able to find it
right now, unfortunately.

John

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Marc Haber]

On Fri, 10 May 2019 11:50:17 -0400, Michael Stone 
wrote:
>On Fri, May 10, 2019 at 05:42:45PM +0200, Marc Haber wrote:
>>On Fri, 10 May 2019 07:42:52 -0400, Michael Stone 
>>wrote:
>>>This is really not a property worth preserving.
>>
>>I disagree. I frequently unpack .debs on .rpm Systems, especially when
>>I want to see how the rather nice behavior that I find in Debian is
>>implemented to see whether I can implant that hotness into the .rpm
>>world.
>
>And there are easily installed tools which I have every confidence will 
>be updated to work with any new format so your ability to do so won't be 
>diminished in the least.

If I can install rpms without hassle, yes. I often cannot.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834