Re: Packaging of static libraries

[Sune Vuorela]

On 2016-04-11, Alastair McKinstry  wrote:
> What uses require PIC static libraries that cannot be satisfied by building
> -static --whole-archive ?

Linking a static library into a dynamic library.

/Sune

RFA: storaged -- Disk Manager

[Andreas Henriksson]

Package: wnpp
Severity: normal

Hello!

This is a borderline RFA/RFH. I've already packaged storaged, which is
a fork of udisks2 but more targeted at supporting advanced "enterpricy"
storage solutions. It's currently sitting in experimental, since I don't
have time to properly maintain it myself and thus shouldn't upload it
targeted at testing/stretch.
Many backends are currently disabled since their dependencies are
currently not available in Debian.
I've also not properly tested that it's functional, but TTBOMK it is.

Further information can be found at:
https://tracker.debian.org/pkg/storaged

Like the packaging vcs at:
https://anonscm.debian.org/cgit/collab-maint/pkg-storaged.git

There's also interest from upstream to see Debian support and their
bug tracker has an issue for this, see:
https://github.com/storaged-project/storaged/issues/41#issuecomment-205769607

Upstream has packaged the dependencies which are not available in Debian
in separate Ubuntu PPAs and updated the storaged package in an Ubuntu PPA
to enable the new backends, which should serve as a very good base for
someone willing to maintain these in Debian!

If you'd like to see storaged (which is an optional but quite central
dependency of cockpit-project.org) in a future stable Debian release,
then this is your chance to help out!

Get in touch if you'd like to be the primary maintainer of storaged
in Debian. I'm willing to assist as a co-maintainer and can also sponsor
you if you're not already a Debian Developer.

Regards,
Andreas Henriksson

Re: Packaging of static libraries

[Mike Hommey]

On Mon, Apr 11, 2016 at 06:44:45AM +0100, Alastair McKinstry wrote:
> 
> 
> On 10/04/2016 23:08, Mike Hommey wrote:
> > On Sun, Apr 10, 2016 at 02:28:02PM +0100, Alastair McKinstry wrote:
> >>
> >> On 10/04/2016 08:05, Andreas Tille wrote:
> >>> Hi,
> >>>
> >>>   > The only use case I could imagine is to create an executable that can
> >>>   > run outside of Debian.
> >> Static builds are still common in (parts of) scientific computing.
> >> Two main reasons:
> >>
> >> (1) When performance matters. Here we need the static library to be
> >> built without
> >> position independent code.
> > That's the funny part. Some use cases require non-PIC static libraries,
> > and others require PIC static libraries. Should we then ship both?  I
> > think we can all agree that would be terrible. So why prioritize one
> > over the other?
> What uses require PIC static libraries that cannot be satisfied by building
> -static --whole-archive ?

https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2Fg.2B-.2B-_-fPIE_-pie.29

Mike

Re: Packaging of static libraries

[Alastair McKinstry]

On 10/04/2016 23:08, Mike Hommey wrote:
> On Sun, Apr 10, 2016 at 02:28:02PM +0100, Alastair McKinstry wrote:
>>
>> On 10/04/2016 08:05, Andreas Tille wrote:
>>> Hi,
>>>
>>>   > The only use case I could imagine is to create an executable that can
>>>   > run outside of Debian.
>> Static builds are still common in (parts of) scientific computing.
>> Two main reasons:
>>
>> (1) When performance matters. Here we need the static library to be
>> built without
>> position independent code.
> That's the funny part. Some use cases require non-PIC static libraries,
> and others require PIC static libraries. Should we then ship both?  I
> think we can all agree that would be terrible. So why prioritize one
> over the other?
What uses require PIC static libraries that cannot be satisfied by building
-static --whole-archive ?
> Mike
Alastair

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Re: Opt out style recommends

[Paul Wise]

On Mon, Apr 11, 2016 at 9:22 AM, Ben Hutchings wrote:

> Binding *is* lazy by default, but loading of NEEDED libraries is eager
> since ELF dynamic symbol references don't say which library they're
> expected to be resolved in (perhaps the best *and* worst feature of ELF
> dynamic linking).  If we made the absence of a NEEDED library non-
> fatal, that would put off failure until the application used a symbol
> from the missing library, but at that point I don't think there's any
> good way for the application to handle failure gracefully.

Apparently Solaris has support for optional shared libraries. It seems
like something that would be useful to have on Linux/glibc.

https://lists.debian.org/debian-devel/2015/02/msg00261.html
https://sourceware.org/ml/libc-help/2013-02/msg00017.html
http://comments.gmane.org/gmane.comp.handhelds.tizen.devel/4892

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Priorities overrides? Extra?

[Paul Wise]

On Mon, Apr 11, 2016 at 5:49 AM, Philipp Kern wrote:

> Maybe it's time to acknowledge that it's mostly busy work at this
> point and packages could be authoritative for this kind of information (and
> handle NEW with a simple list of packages).

I expect the ftpteam will want to put things in NEW when they move
between main/contrib/non-free so a simple list of packages wouldn't be
enough?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Opt out style recommends

[Ben Hutchings]

On Sun, 2016-04-10 at 13:35 -0700, Russ Allbery wrote:
[...]
> The major place where this breaks down is with shared
> libraries, since, due to how dynamic linking works, even shared libraries
> only used in specific dconfigurations have to be listed in Depends.  But,
> because the shared library may be unused other than by mapping it during
> process startup, all of its dependencies (of any strength) that don't
> interfere with startup mapping should be deprioritized.
> 
> In other words, the root of the problem is that we're forced to take
> artificially strong dependencies that aren't warranted by the
> functionality of the library due to the implementation of dynamic linking
> and the fact we want startup binding instead of lazy binding on first call
> (for some justifiably good reasons).

Binding *is* lazy by default, but loading of NEEDED libraries is eager
since ELF dynamic symbol references don't say which library they're
expected to be resolved in (perhaps the best *and* worst feature of ELF
dynamic linking).  If we made the absence of a NEEDED library non-
fatal, that would put off failure until the application used a symbol
from the missing library, but at that point I don't think there's any
good way for the application to handle failure gracefully.

Would it be useful to have a linker option to omit a NEEDED entry for a
particular library?  The application could then call
dlopen("libfoo.so.42", RTLD_NOW|RTLD_GLOBAL) before it starts using the
library, typically right before calling foo_init(), but it wouldn't
need to use dlsym().  However this would absolutely depend on lazy
binding, i.e. the application would break if LD_BIND_NOW was set.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

signature.asc
Description: This is a digitally signed message part

Re: Packaging of static libraries

[Milan Kupcevic]

On 04/10/2016 06:05 PM, Jakub Wilk wrote:
> * Milan Kupcevic , 2016-04-10, 16:51:
 We should change policy and packaging tools such that static linking
 are not enabled by default and only enabled when there is a good
 reason to do so; when requested by users or when there is some other
>>> No, we should not.
>>
>> +1
>>
>> A lintian check should suffice.
> 
> Lintian check for what?
> 


In the context of discussion and Paul's proposal[0][1] lintian check for
statically linked binaries in Debian packages should suffice. If the one
we've got[2] is deficient then we should look into it and figure out how
to fix it.

Another way to discourage or eradicate static linking would be a mandate
of placement of static library files in a separate development package.
This way linking to a static library would require explicit declaration
of lib*-static-dev instead of lib*-dev in Build-Depends, for example.
Unintentional linking to a static library would not be possible in this
case.

Removing static option from building tools or completely removing static
libraries from development packages would be a step backward. Static
linking is unavoidable in building bootloaders, forensic and diagnostic
tools that have to run on bare systems or in bare kernel only environments.

Moreover, static libraries and static linking option is expected to be
available in an universal operating system. They are coming handy for
compiling custom binaries intended to run outside of full Debian
installation. An example would be a scientific analysis binary running
on a cluster where cluster nodes have nothing else but kernel and just a
few essential dynamic libraries available.


[0] https://lists.debian.org/debian-devel/2016/04/msg00210.html
[1] https://wiki.debian.org/StaticLinking
[2] https://lintian.debian.org/tags/statically-linked-binary.html




signature.asc
Description: OpenPGP digital signature

Re: Packaging of static libraries

[Russ Allbery]

Mike Hommey  writes:

> That's the funny part. Some use cases require non-PIC static libraries,
> and others require PIC static libraries. Should we then ship both?  I
> think we can all agree that would be terrible.

Actually, if the library is needed in both forms, it's not that bad of an
idea.

lothlorien:~$ ls /usr/lib/x86_64-linux-gnu/*_pic.a
/usr/lib/x86_64-linux-gnu/libcdb_pic.a  /usr/lib/x86_64-linux-gnu/libfl_pic.a

> So why prioritize one over the other?

I think that's another good argument for not shipping them at all by
default, and letting the package maintainer choose which to ship based on
the reasons why people actually *want* static versions of that library.
And if no one ever wants them, no one has to go to the work of making
them and we don't have to ship them around to lots of mirrors.

-- 
Russ Allbery (r...@debian.org)   

Re: Packaging of static libraries

[Mike Hommey]

On Sun, Apr 10, 2016 at 02:28:02PM +0100, Alastair McKinstry wrote:
> 
> 
> On 10/04/2016 08:05, Andreas Tille wrote:
> > Hi,
> >
> >   > The only use case I could imagine is to create an executable that can
> >   > run outside of Debian.
> Static builds are still common in (parts of) scientific computing.
> Two main reasons:
> 
> (1) When performance matters. Here we need the static library to be
> built without
> position independent code.

That's the funny part. Some use cases require non-PIC static libraries,
and others require PIC static libraries. Should we then ship both?  I
think we can all agree that would be terrible. So why prioritize one
over the other?

Mike

Re: Packaging of static libraries

[Jakub Wilk]

* Milan Kupcevic , 2016-04-10, 16:51:
We should change policy and packaging tools such that static linking 
are not enabled by default and only enabled when there is a good 
reason to do so; when requested by users or when there is some other

No, we should not.


+1

A lintian check should suffice.


Lintian check for what?

--
Jakub Wilk

Re: Priorities overrides? Extra?

[Philipp Kern]

On 2016-04-10 07:08, Ole Streicher wrote:

Jakub Wilk  writes:

* Ole Streicher , 2016-04-10, 14:22:

When I look into the "overrides" file for debian stretch:
http://ftp.debian.org/debian/indices/override.stretch.main.gz
I find there more than 48.000 overrides; which means that almost
*all* packages are overridden.

Exactly _all_ binary packages are in the override file.

Yes, but why?


Because it's an implementation detail of the archive software that NEW 
processing create an override entry for every binary package. The 
presence of the override entry determines if the package is (subject to) 
NEW or not.


It used to be the case that uploads are costly and back then overrides 
were decoupled from the in-package content as it could change more often 
than the package. It might still make sense that there's a possibility 
to bump a package's priority independently from the package. As in, for 
instance: The distribution wants the priority of $library to be higher 
than it usually would be if considered independently ("optional", as for 
almost every other package), mostly because of transitive dependencies. 
But outside of any core set this functionality is rarely used. And I 
think no-one actively tends to override mismatches on the ftp-master 
side. In the end what happens is that people file bugs when the 
mismatches appear on the tracker one way or the other. Maybe it's time 
to acknowledge that it's mostly busy work at this point and packages 
could be authoritative for this kind of information (and handle NEW with 
a simple list of packages).


Kind regards
Philipp Kern

Re: Packaging of static libraries

[Milan Kupcevic]

On 04/10/2016 12:15 PM, Clint Adams wrote:
> On Mon, Apr 11, 2016 at 12:13:20AM +0800, Paul Wise wrote:
>> We should change policy and packaging tools such that static linking
>> are not enabled by default and only enabled when there is a good
>> reason to do so; when requested by users or when there is some other
> 
> No, we should not.
> 

+1

A lintian check should suffice.



signature.asc
Description: OpenPGP digital signature

Re: Packaging of static libraries

[Pau Garcia i Quiles]

On Sun, Apr 10, 2016 at 10:24 PM, Henrique de Moraes Holschuh <
h...@debian.org> wrote:


> 1) make it clearn that static linking is to be used only when strongly
> justified (e.g. system rescue tools like sash).
>
>
As I see it, static libraries are mostly meant for the end-user, not for
distribution packages.

E. g. my package witty (http://www.webtoolkit.eu) is a C++ web library
(something like Rails, Django or Laravel). It is mostly used either in
embedded (e. g. medical devices, routers, etc) or in high-load applications
(e. g. a Facebook app). For the first use case I provide static libraries,
for the second use case I provide shared libraries.

One problem my users find is many libraries in Debian do not provide a
static library, rendering my static libraries useless.

-- 
Pau Garcia i Quiles
http://www.elpauer.org

Re: Opt out style recommends

[Russ Allbery]

Tollef Fog Heen  writes:
> ]] Russ Allbery 

>> I think a more correct fix would (unfortunately) involve a new binary
>> package field that we don't currently have: Depends-Shallow (for lack
>> of a better term) that acts like Depends *except* disables Recommends
>> processing for anything below the shallow dependencies in the tree.  So
>> if everything you're installing only Depends-Shallow on
>> libimobiledevice4, you don't get the recommendation; if anything
>> straight depends on it, you do.

> I think I want something like Recommends that get less and less weight
> the further they get from something you explicitly requested. Direct
> recommends: 1 point, One step indirect, 0.8 point, two steps 0.8^2
> points, etc.  One point or more -> install.  You can then also do things
> like adding together scores, so if A, B and C all suggests D, you might
> get that, even if none of them would pull it in by themselves.

> (Weights are obviously pulled out of thin air, experimentation would be
> needed to find sensible values.)

Distance is being used as a proxy for "likely to interfere with the
usability of the program."  It's not a bad proxy, but it would be ideal if
we could directly annotate this, since often the maintainers involved know
exactly what weight should be placed.  There are some long dependency
chains that actually need a strong dependency the whole way.

And largely maintainers can do that annotation, using Depends, Recommends,
and Suggests.  The major place where this breaks down is with shared
libraries, since, due to how dynamic linking works, even shared libraries
only used in specific configurations have to be listed in Depends.  But,
because the shared library may be unused other than by mapping it during
process startup, all of its dependencies (of any strength) that don't
interfere with startup mapping should be deprioritized.

In other words, the root of the problem is that we're forced to take
artificially strong dependencies that aren't warranted by the
functionality of the library due to the implementation of dynamic linking
and the fact we want startup binding instead of lazy binding on first call
(for some justifiably good reasons).

-- 
Russ Allbery (r...@debian.org)   

Re: Priorities overrides? Extra?

[Ole Streicher]

Andrey Rahmatullin  writes:
> On Sun, Apr 10, 2016 at 08:34:18PM +0200, Ole Streicher wrote:
>> Question is wich information they cover. For me, "optional" means:
>> conflict free by policy.
> You are still mixing two completely separate things.

Which?

>> > One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
>> > #373603 in 2006 and fixed back by #706164 in 2013.
>> 
>> Yes; this is the reason why I had it in some of my first packages, from
>> where it was copied and pasted to other new packages.
>> 
>> The problem is that I cannot set it back on my own. I have to ask
>> ftp-master and put them more load on their shoulders.
> Changing overrides is a normal procedure.

For 12.000 packages? Sure, these are less if I leave out oldlibs and
debug packages, but probably still a few thousands.

>> For a field that is -- as you said -- pure informational (and where the
>> wrong setting could be mentioned just by filing a bug).
> By saying "informational" I meant that the override value is what matters,
> not the field in the package.

So what is the field in the package for?

>> Sure. The problem arises f.e. with my package: it is really special, and
>> you would not like to install it unless you know what it is for.
> You should use "optional" for such packages.

Sure. As there are hundreds of other packages which are in the blends.

>> > See also #759260 for discussions about dropping extra completely.
>> 
>> I would not drop it completely, since it provides the useful information
>> "may have conflicts with other packages".
> I'm not sure who would find this information useful.
> Note that according to the bug discussion this distinction was caused only
> by a requirement to be able to co-install all optional packages which is
> not useful at all.

"Optional" packages are conflict free by policy. So, if we provide a few
default installations of Blends via tasksel, we can be sure that there
will be no conflict, as long as all tasks are Priority "optional".

The problem is not to install *all* packages, but to be able to install
*every* package without the risk of having a conflict (not sure if my
englisch is good enoough here): how else can I make sure that if someone
chooses at installation time that he wants to have f.e. "Debian Astro"
installed, that none of the included packages have conflicts? If they
were all priority "optional" (and we would file/fix the policy
violations), we could.

Usage by the Debian installer/tasksel is IMO one of the ue cases for the
distinction between "extra" and "optional": If a package is "extra", it
has either the risk of introducing a package conflict, or it is so
special that there is no reason to be installed by a common task.

>> -- either since they are really too special, or since they may have
>> conflicts. So, to get the Debian Blends into the installer, what should
>> I do? 
> See? That's why your package should be priority: optional.

 as thousands other packages. I'd have no problems to file a bug
report for each of these against ftp-masters, but I would like to hear
opinions about that first.

> You can also behave like many packagers do: don't pretend that optional
> and extra priorities are different and that the policy (still) has
> different requirements about them. I don't see any downsides with that.

As I wrote: The distinction is good for things that are done by first
install. Imagine some newcomer who selects the "Debian Games" pure blend
during the Debian installation and is then left alone with the
resolution of package conflicts. I'd call that a desaster.

Best regards

Ole

Re: Packaging of static libraries

[Henrique de Moraes Holschuh]

On Sun, 10 Apr 2016, Clint Adams wrote:
> On Mon, Apr 11, 2016 at 12:13:20AM +0800, Paul Wise wrote:
> > We should change policy and packaging tools such that static linking
> > are not enabled by default and only enabled when there is a good
> > reason to do so; when requested by users or when there is some other
> 
> No, we should not.

Agreed.  The correct fix is to:

1) make it clearn that static linking is to be used only when strongly
justified (e.g. system rescue tools like sash).

2) add dependency metadata to track this, so that a tool can schedule
binNMUs as required when a statically-linked dependency gets updated, and so
that it won't cause extra heartburn for the security team.

3) add a way to automatically generate the metadata for (2) during package
build, otherwise it is pointless to even try.

I have a hunch we even have some (maybe even all) of this already...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Opt out style recommends

[Tollef Fog Heen]

]] Russ Allbery 

> I think a more correct fix would (unfortunately) involve a new binary
> package field that we don't currently have: Depends-Shallow (for lack of a
> better term) that acts like Depends *except* disables Recommends
> processing for anything below the shallow dependencies in the tree.  So if
> everything you're installing only Depends-Shallow on libimobiledevice4,
> you don't get the recommendation; if anything straight depends on it, you
> do.

I think I want something like Recommends that get less and less weight
the further they get from something you explicitly requested. Direct
recommends: 1 point, One step indirect, 0.8 point, two steps 0.8^2
points, etc.  One point or more -> install.  You can then also do things
like adding together scores, so if A, B and C all suggests D, you might
get that, even if none of them would pull it in by themselves.

(Weights are obviously pulled out of thin air, experimentation would be
needed to find sensible values.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Priorities overrides? Extra?

[Holger Levsen]

On Mon, Apr 11, 2016 at 12:24:55AM +0500, Andrey Rahmatullin wrote:
> You can also behave like many packagers do: don't pretend that optional
> and extra priorities are different and that the policy (still) has
> different requirements about them. I don't see any downsides with that.

or simply ask the ftp-masters to adopt the overrides as needed. It's a
<1min change and they are happy to maintain that file.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Priorities overrides? Extra?

[Andrey Rahmatullin]

On Sun, Apr 10, 2016 at 08:34:18PM +0200, Ole Streicher wrote:
> > Note that you mix two completely different questions in your email.
> >
> > On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
> >> http://ftp.debian.org/debian/indices/override.stretch.main.gz
> >> 
> >> I find there more than 48.000 overrides; which means that almost *all*
> >> packages are overridden.
> >> 
> >> What is the reason for that? I would expect that overriding is something
> >> exceptional, but not the common way to set the priority?
> > I guess that's an implementation detail of the archive software. Priority
> > fields in the packages are only informational, that's all.
> 
> Question is wich information they cover. For me, "optional" means:
> conflict free by policy.
You are still mixing two completely separate things.

> > One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
> > #373603 in 2006 and fixed back by #706164 in 2013.
> 
> Yes; this is the reason why I had it in some of my first packages, from
> where it was copied and pasted to other new packages.
> 
> The problem is that I cannot set it back on my own. I have to ask
> ftp-master and put them more load on their shoulders.
Changing overrides is a normal procedure.

> For a field that is -- as you said -- pure informational (and where the
> wrong setting could be mentioned just by filing a bug).
By saying "informational" I meant that the override value is what matters,
not the field in the package.

> > Yet another one is the bad policy wording about "likely to be useful
> > if you already know what they are" (see #660249 about dropping that).
> Sure. The problem arises f.e. with my package: it is really special, and
> you would not like to install it unless you know what it is for.
You should use "optional" for such packages.

> > See also #759260 for discussions about dropping extra completely.
> 
> I would not drop it completely, since it provides the useful information
> "may have conflicts with other packages".
I'm not sure who would find this information useful.
Note that according to the bug discussion this distinction was caused only
by a requirement to be able to co-install all optional packages which is
not useful at all.

> My problem here is that, according to the policy, no "extra" programs
> should be installed by the Debian installer
I don't think the policy says or means anything about the Debian
installer.

> -- either since they are really too special, or since they may have
> conflicts. So, to get the Debian Blends into the installer, what should
> I do? 
See? That's why your package should be priority: optional.

> I could create bugs for all affected packages (of the blends, and their
> dependencies), which would end up in maybe 1000 bug reports (or commits,
> if they are team maintained). However, at some point I would have to ask
> the ftp-masters to change all these priorities, and I am not sure
> whether they are too happy with it.
You can also behave like many packagers do: don't pretend that optional
and extra priorities are different and that the policy (still) has
different requirements about them. I don't see any downsides with that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Priorities overrides? Extra?

[Ole Streicher]

Andrey Rahmatullin  writes:
> Note that you mix two completely different questions in your email.
>
> On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
>> http://ftp.debian.org/debian/indices/override.stretch.main.gz
>> 
>> I find there more than 48.000 overrides; which means that almost *all*
>> packages are overridden.
>> 
>> What is the reason for that? I would expect that overriding is something
>> exceptional, but not the common way to set the priority?
> I guess that's an implementation detail of the archive software. Priority
> fields in the packages are only informational, that's all.

Question is wich information they cover. For me, "optional" means:
conflict free by policy.

> One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
> #373603 in 2006 and fixed back by #706164 in 2013.

Yes; this is the reason why I had it in some of my first packages, from
where it was copied and pasted to other new packages.

The problem is that I cannot set it back on my own. I have to ask
ftp-master and put them more load on their shoulders. For a field that
is -- as you said -- pure informational (and where the wrong setting
could be mentioned just by filing a bug).

> Yet another one is the bad policy wording about "likely to be useful
> if you already know what they are" (see #660249 about dropping that).

Sure. The problem arises f.e. with my package: it is really special, and
you would not like to install it unless you know what it is for.

However, it is an dependency of other programs, and they are *not*
special anymore. But by policy they would be required to be "extra" as
well.

> See also #759260 for discussions about dropping extra completely.

I would not drop it completely, since it provides the useful information
"may have conflicts with other packages". I would just like to see how
we can get back to get it useful and how we can people take it seriously.

My problem here is that, according to the policy, no "extra" programs
should be installed by the Debian installer -- either since they are
really too special, or since they may have conflicts. So, to get the
Debian Blends into the installer, what should I do? I could create bugs
for all affected packages (of the blends, and their dependencies), which
would end up in maybe 1000 bug reports (or commits, if they are team
maintained). However, at some point I would have to ask the ftp-masters
to change all these priorities, and I am not sure whether they are too
happy with it.

Best regards

Ole

Re: Priorities overrides? Extra?

[Ole Streicher]

Andrey Rahmatullin  writes:
> Note that you mix two completely different questions in your email.
>
> On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
>> http://ftp.debian.org/debian/indices/override.stretch.main.gz
>> 
>> I find there more than 48.000 overrides; which means that almost *all*
>> packages are overridden.
>> 
>> What is the reason for that? I would expect that overriding is something
>> exceptional, but not the common way to set the priority?
> I guess that's an implementation detail of the archive software. Priority
> fields in the packages are only informational, that's all.

Question is wich information they cover. For me, "optional" means:
conflict free by policy.

> One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
> #373603 in 2006 and fixed back by #706164 in 2013.

Yes; this is the reason why I had it in some of my first packages, from
where it was copied and pasted to other new packages.

The problem is that I cannot set it back on my own. I have to ask
ftp-master and put them more load on their shoulders. For a field that
is -- as you said -- pure informational (and where the wrong setting
could be mentioned just by filing a bug).

> Yet another one is the bad policy wording about "likely to be useful
> if you already know what they are" (see #660249 about dropping that).

Sure. The problem arises f.e. with my package: it is really special, and
you would not like to install it unless you know what it is for.

However, it is an dependency of other programs, and they are *not*
special anymore. But by policy they would be required to be "extra" as
well.

> See also #759260 for discussions about dropping extra completely.

I would not drop it completely, since it provides the useful information
"may have conflicts with other packages". I would just like to see how
we can get back to get it useful and how we can people take it seriously.

My problem here is that, according to the policy, no "extra" programs
should be installed by the Debian installer -- either since they are
really too special, or since they may have conflicts. So, to get the
Debian Blends into the installer, what should I do? I could create bugs
for all affected packages (of the blends, and their dependencies), which
would end up in maybe 1000 bug reports (or commits, if they are team
maintained). However, at some point I would have to ask the ftp-masters
to change all these priorities, and I am not sure whether they are too
happy with it.

Best regards

Ole

Re: Packaging of static libraries

[Niels Thykier]

Alastair McKinstry:
> 
> 
> On 10/04/2016 08:05, Andreas Tille wrote:
>> Hi,
>>
>>   > The only use case I could imagine is to create an executable that can
>>   > run outside of Debian.
> Static builds are still common in (parts of) scientific computing.
> Two main reasons:
> 
> (1) When performance matters. Here we need the static library to be
> built without
> position independent code. This can still give several percent gains
> depending
> on arch / programming language.
> [...]

Hi,

I would like to use this opportunity to remind people that GCC-5 has
significantly improved the performance of Position Independent Code
(PIC) on i386 compared to earlier releases.  Please see [1] or [2] for
details.

I do not intend to make any claims about whether that is sufficient for
the use-case you are referring to, but I thought I would mention it as
it seemed relevant.

Thanks,
~Niels

[1]
https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode

[2] https://gcc.gnu.org/gcc-5/changes.html

Look for "Register allocation improvements:"




signature.asc
Description: OpenPGP digital signature

Re: Packaging of static libraries

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Apr 10, 2016 at 09:06:50PM +0500, Andrey Rahmatullin wrote:
> On Sun, Apr 10, 2016 at 05:57:16PM +0200, Andreas Tille wrote:
> > > > whether it is advisable to try hard to provide static libraries even if
> > > > upstream build system does not easily provide both.
> > > Note that it's only a wishlist severity bug if you don't provide it.
> > I do not mind about the severity of the bug (since IMHO also wishlist
> > bugs should be closed).  My point was that to my understanding people
> > are misunderstanding policy when giving the advise to ignore static
> > library.
> If you want to provide them it's fine, I don't think anybody will stop you
> (and if there are reasons, we should update the policy). You are just not
> obliged to do that work if you don't have enough resources or it's too
> complicated.

I think we all agree here.  Static libraries should be provided if possible,
but it's acceptable if you don't do it.  However, as Andreas points out, if
people are advising in general to not package static libraries (or worse, to
remove them from a package), that is wrong.

In specific cases it can be fine ("it seems to be hard to do it here, I
wouldn't bother"), but not in general ("packages shouldn't contain static
libraries").

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXCnwoAAoJEJzRfVgHwHE6WiIP/21an2YKFamUTAMY9EfAWo+U
L46eEk6zWaMUtUYVwN+lnwiMWxoRLZqBucksh6u2eF62VpZ3XwkyXQLJnVbdEGUS
nCSsJFGm5W/VxD3DsMhdSmEhkI/XajkglC5+RZnOcLt8b+UW/xa5gDmLi9XybS76
N8ep2bx5MLoO8XyaCR3dABKDBqXcgReys9Vr7wps4u+ocXCw34icphQ8mgJxn1kN
XSixGvsV8tDAhnAuzqZLHz+hRMZo0IQ6+UewKr0gYaMgVp5gWRbi70+RP6jj/qkN
UqDE0nLYcaMtvU7xt308Guuln+SEyhy44RXLJUHmf8lwQWG+fg7nXXrGPfMYjRjr
YmeaC329gOzKkggVbu/TdN5tgDLNP10uGMV/4mve0O3HCOzmd9P8qOfdeXIjpjxQ
WXNgQ1qEC9c7qufSDFGAoYSzN8P1DlomxDn6gEhNCl/XQwLuetxdVifkgNcScfxF
PWv1oYUwoEBSb4ULHqToLBOXSr1HTm5ZOeReGwj27zpL9KEtk03wUWSNFRveB1D3
eno90VtbCtWCLi00VxvQDBJKcA4ZlMjXPZA0b9sPgTfgKQ+6jKuYbDIcpUWdjeF4
EgOewNZW3EaAfrbLae4LrX0wwtrBNPte4h1lrpEaJq5Fl3mzmEM3C2qgxOevIrgr
GZTMwySVZlWXHcUVtHfP
=pEit
-END PGP SIGNATURE-

Re: Packaging of static libraries

[Clint Adams]

On Mon, Apr 11, 2016 at 12:13:20AM +0800, Paul Wise wrote:
> We should change policy and packaging tools such that static linking
> are not enabled by default and only enabled when there is a good
> reason to do so; when requested by users or when there is some other

No, we should not.

Re: Packaging of static libraries

[Paul Wise]

On Sun, Apr 10, 2016 at 11:57 PM, Andreas Tille wrote:

> I do not mind about the severity of the bug (since IMHO also wishlist
> bugs should be closed).  My point was that to my understanding people
> are misunderstanding policy when giving the advise to ignore static
> library.

We should change policy and packaging tools such that static linking
are not enabled by default and only enabled when there is a good
reason to do so; when requested by users or when there is some other
issue with dynamic libs. If anyone wants to help out there:

https://wiki.debian.org/StaticLinking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Packaging of static libraries

[Andrey Rahmatullin]

On Sun, Apr 10, 2016 at 05:57:16PM +0200, Andreas Tille wrote:
> > > whether it is advisable to try hard to provide static libraries even if
> > > upstream build system does not easily provide both.
> > Note that it's only a wishlist severity bug if you don't provide it.
> I do not mind about the severity of the bug (since IMHO also wishlist
> bugs should be closed).  My point was that to my understanding people
> are misunderstanding policy when giving the advise to ignore static
> library.
If you want to provide them it's fine, I don't think anybody will stop you
(and if there are reasons, we should update the policy). You are just not
obliged to do that work if you don't have enough resources or it's too
complicated.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Packaging of static libraries

[Andreas Tille]

On Sun, Apr 10, 2016 at 07:12:05PM +0500, Andrey Rahmatullin wrote:
> On Sun, Apr 10, 2016 at 09:05:36AM +0200, Andreas Tille wrote:
> > whether it is advisable to try hard to provide static libraries even if
> > upstream build system does not easily provide both.
> Note that it's only a wishlist severity bug if you don't provide it.

I do not mind about the severity of the bug (since IMHO also wishlist
bugs should be closed).  My point was that to my understanding people
are misunderstanding policy when giving the advise to ignore static
library.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Priorities overrides? Extra?

[Andrey Rahmatullin]

Note that you mix two completely different questions in your email.

On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
> http://ftp.debian.org/debian/indices/override.stretch.main.gz
> 
> I find there more than 48.000 overrides; which means that almost *all*
> packages are overridden.
> 
> What is the reason for that? I would expect that overriding is something
> exceptional, but not the common way to set the priority?
I guess that's an implementation detail of the archive software. Priority
fields in the packages are only informational, that's all.

> Looking into the priorities, I found:
> 
>  66 required
>  64 important
>  86 standard
>   34854 optional
>   13191 extra
> 
> which means that almost one third of the packages is priority
> "extra". From the policy, I would expect that the main reasons to give
> the priority "extra" are either a conflict with another package, or the
> dependency on a package with priority "extra".
One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
#373603 in 2006 and fixed back by #706164 in 2013. Yet another one is the
bad policy wording about "likely to be useful if you already know what
they are" (see #660249 about dropping that).

See also #759260 for discussions about dropping extra completely.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#820615: ITP: go-cve-dictionary -- builds a local copy of the NVD/JVN (vulnerability databases)

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 
Control: block by 820614 -1

* Package name: go-cve-dictionary
  Version : 0.0+git20160410.6d3c17f
  Upstream Author : Kota Kanbe 
* URL : https://github.com/kotakanbe/go-cve-dictionary
* License : Apache-2.0
  Programming Lang: Go
  Description : builds a local copy of the NVD/JVN (vulnerabilitiy 
databases)

This is tool to build a local copy of the NVD (National Vulnerabilities 
Database) [1]
and the Japanese JVN, which contain security vulnerabilities according to their
CVE identifiers [2] including exhaustive information and a risk score. The local
copy is generated in sqlite format, and the tool has a server mode for easy 
querying.
This is needed by vuls.

I'm going to maintain this in the Pkg-go group, the name of the binary is going
to be "go-cve-dictionary".

Thanks,
DS

[1] https://en.wikipedia.org/wiki/National_Vulnerability_Database

[2] https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures

Re: Priorities overrides? Extra?

[Ole Streicher]

Santiago Vila  writes:
> On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
>> What is the idea behind the current structure?
>
> It all depends on what you call "specialized requirements".
>
> Unless we rely on popcon to decide what's special and what's not,
> this will remain very subjective.
>
> IMHO, we could well get rid of the "special requirements" thing and
> make "optional" maximally useful by raising as many packages as we can
> from extra to optional.
>
> The only rule which is currently useful is the "no conflicts between
> optional packages". This has also the good property of being objective.

Ack. This would mark 12.000 more packages as "optional". Why don't we do
that?

Best regards

Ole

Bug#820614: ITP: vuls -- package inventory scanner for CVE vulnerabilities

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: vuls
  Version : 0.1.1
  Upstream Author : Kota Kanbe 
* URL : https://github.com/future-architect/vuls
* License : GPL-3
  Programming Lang: Google Go
  Description : package inventory scanner for CVE vulnerabilities

This is scanner which checks the package inventory against a local copy of
the National Vunerabilities Database (NVD) of vulnerabilities according to
their CVE (Common Vulnerabilities and Exposures) indentifiers. The backends
supports a couple of OSs (Debian, RHEL, CentOS, Amazon Linux). Scanning servers
over the network is possible.

A typical scan goes like (a Ubuntu 12.04 server via SSH):

$ ./vuls scan
[Apr 10 16:21:02]  INFO [localhost] Validating Config...
[Apr 10 16:21:02]  INFO [localhost] Detecting OS... 
[Apr 10 16:21:06]  INFO [localhost] Scanning vulnerabilities... 
[Apr 10 16:21:06]  INFO [localhost] Check required packages for scanning...
[Apr 10 16:21:06]  INFO [localhost] Scanning vulnerable OS packages...
{...}
[Apr 10 16:21:44]  INFO [myserver:22] (1/22) Scanned 
libisccfg82-1:9.8.1.dfsg.P1-4ubuntu0.15 : [CVE-2016-1285 CVE-2016-1286]
[Apr 10 16:21:44]  INFO [myserver:22] (2/22) Scanned 
libisc83-1:9.8.1.dfsg.P1-4ubuntu0.15 : [CVE-2016-1285 CVE-2016-1286]
[Apr 10 16:21:44]  INFO [myserver:22] (3/22) Scanned 
libisccc80-1:9.8.1.dfsg.P1-4ubuntu0.15 : [CVE-2016-1285 CVE-2016-1286]
[Apr 10 16:21:44]  INFO [myserver:22] (4/22) Scanned 
dnsutils-1:9.8.1.dfsg.P1-4ubuntu0.15 : [CVE-2016-1285 CVE-2016-1286]
[Apr 10 16:21:44]  INFO [myserver:22] (5/22) Scanned 
libgnutls26-2.12.14-5ubuntu3.11 : []
[Apr 10 16:21:44]  INFO [myserver:22] (6/22) Scanned 
liblwres80-1:9.8.1.dfsg.P1-4ubuntu0.15 : [CVE-2016-1285 CVE-2016-1286]
[Apr 10 16:21:44]  INFO [myserver:22] (7/22) Scanned 
ca-certificates-20141019ubuntu0.12.04.1 : []
[Apr 10 16:21:44]  INFO [myserver:22] (8/22) Scanned 
bind9-host-1:9.8.1.dfsg.P1-4ubuntu0.15 : [CVE-2016-1285 CVE-2016-1286]
[Apr 10 16:21:44]  INFO [myserver:22] (9/22) Scanned 
libbind9-80-1:9.8.1.dfsg.P1-4ubuntu0.15 : [CVE-2016-1285 CVE-2016-1286]
[Apr 10 16:21:44]  INFO [myserver:22] (10/22) Scanned 
libdns81-1:9.8.1.dfsg.P1-4ubuntu0.15 : [CVE-2016-1285 CVE-2016-1286]
[Apr 10 16:21:44]  INFO [myserver:22] (11/22) Scanned libpcre3-8.12-4ubuntu0.1 
: [CVE-2015-2327 CVE-2015-8382 CVE-2015-8385 {...}
[Apr 10 16:21:44]  INFO [myserver:22] (12/22) Scanned 
perl-base-5.14.2-6ubuntu2.4 : [CVE-2013-7422 CVE-2014-4330 CVE-2016-2381]
[Apr 10 16:21:44]  INFO [myserver:22] (13/22) Scanned libpam0g-1.1.3-7ubuntu2 : 
[CVE-2015-3238 CVE-2013-7041 CVE-2014-2583]
[Apr 10 16:21:44]  INFO [myserver:22] (14/22) Scanned openssl-1.0.1-4ubuntu5.33 
: [CVE-2016-0702 CVE-2016-0705 CVE-2016-0797 {...}
[Apr 10 16:21:44]  INFO [myserver:22] (15/22) Scanned 
libpam-modules-bin-1.1.3-7ubuntu2 : [CVE-2015-3238 CVE-2013-7041 CVE-2014-2583]
[Apr 10 16:21:44]  INFO [myserver:22] (16/22) Scanned 
linux-generic-lts-trusty-3.13.0.79.71 : []
[Apr 10 16:21:44]  INFO [myserver:22] (17/22) Scanned 
libpam-modules-1.1.3-7ubuntu2 : [CVE-2015-3238 CVE-2013-7041 CVE-2014-2583]
[Apr 10 16:21:44]  INFO [myserver:22] (18/22) Scanned perl-5.14.2-6ubuntu2.4 : 
[CVE-2013-7422 CVE-2014-4330 CVE-2016-2381]
[Apr 10 16:21:45]  INFO [myserver:22] (19/22) Scanned 
libssl1.0.0-1.0.1-4ubuntu5.33 : [CVE-2016-0702 CVE-2016-0705 CVE-2016-0797 {...}
[Apr 10 16:21:45]  INFO [myserver:22] (20/22) Scanned 
libpam-runtime-1.1.3-7ubuntu2 : [CVE-2015-3238 CVE-2013-7041 CVE-2014-2583]
[Apr 10 16:21:46]  INFO [myserver:22] (21/22) Scanned 
tzdata-2015g-0ubuntu0.12.04 : []
[Apr 10 16:21:46]  INFO [myserver:22] (22/22) Scanned 
perl-modules-5.14.2-6ubuntu2.4 : [CVE-2013-7422 CVE-2014-4330 CVE-2016-2381]
[Apr 10 16:21:46]  INFO [myserver:22] Fetching CVE details...
[Apr 10 16:21:46]  INFO [myserver:22] Done
[Apr 10 16:21:46]  INFO [localhost] Scanning vulnerable software specified in 
the CPE...
[Apr 10 16:21:46]  INFO [localhost] Reporting...
myserver (ubuntu 12.04)
===
CVE-2016-0799   10.0The fmtstr function in crypto/bio/b_print.c in OpenSSL 
1.0.1 before 1.0.1s and 1.0.2
before 1.0.2g improperly calculates string lengths, 
which allows remote attackers to
cause a denial of service (overflow and out-of-bounds 
read) or possibly have
unspecified other impact via a long string, as 
demonstrated by a large amount of
ASN.1 data, a different vulnerability than 
CVE-2016-2842.   
CVE-2016-0705   10.0Double free vulnerability in the dsa_priv_decode 
function in crypto/dsa/dsa_ameth.c 
in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g 
allows remote attackers to   
cause a denial of service (memory corruption) or 
possibly have unspecified other
impact via a malformed DSA private key. 
 

Re: Bug#820561: ITP: dh-elpa-test -- Debian helper tool for running ELPA package testsuites

[Sean Whitton]

Hello,

On Sun, Apr 10, 2016 at 05:09:29AM +, Mattia Rizzolo wrote:
> If you put that in Debian::Debhelper::Sequence::elpa you could just
> check for something (an exported variable?) and/or do some magic to
> detect on your own, without having package maintainers having to do this
> choice for all those packages, couldn't you?

Hmm, an exported environment variable in debian/rules to make the choice
is a good idea.  I'll look into that, thanks.

> > But then for ease of maintenance it should be its own source
> > package.
> 
> this sounds kind of ominous to me: we're talking about an alleged
> helper, maintained in the same team where dh-elpa is maintained. What
> kind of difficult of maintenance would have it?  To me, it looks like
> it would actually *easy* the maintenance, as I couldn't figure this
> as something separated from dh-elpa, but only tightly united.

I didn't want responsibility for fixing bugs in dh-elpa-test to fall on
the shoulders of David Bremner :)  Even though it's a team-maintained
package, it makes sense for the person who wrote the code to try fixing
it first.

On Sun, Apr 10, 2016 at 06:36:11AM +, Niels Thykier wrote:
> I am not aware of any reason why a package can only provide at most one
> debhelper sequence?  If this is the primary reason for having two
> packages, please assert that this assumption holds.

No, a package can provide more than one.  I just didn't want to throw in
a lot of extra lines to dh-elpa's build scripts.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Priorities overrides? Extra?

[Santiago Vila]

On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:

> What is the idea behind the current structure?

It all depends on what you call "specialized requirements".

Unless we rely on popcon to decide what's special and what's not,
this will remain very subjective.

IMHO, we could well get rid of the "special requirements" thing and
make "optional" maximally useful by raising as many packages as we can
from extra to optional.

The only rule which is currently useful is the "no conflicts between
optional packages". This has also the good property of being objective.

Thanks.

Re: Packaging of static libraries

[Andrey Rahmatullin]

On Sun, Apr 10, 2016 at 09:05:36AM +0200, Andreas Tille wrote:
> whether it is advisable to try hard to provide static libraries even if
> upstream build system does not easily provide both.
Note that it's only a wishlist severity bug if you don't provide it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Priorities overrides? Extra?

[Ole Streicher]

Jakub Wilk  writes:
> * Ole Streicher , 2016-04-10, 14:22:
>>When I look into the "overrides" file for debian stretch:
>>
>>http://ftp.debian.org/debian/indices/override.stretch.main.gz
>>
>> I find there more than 48.000 overrides; which means that almost
>> *all* packages are overridden.
>
> Exactly _all_ binary packages are in the override file.

Yes, but why?

> That doesn't mean that that every single package had their priority or
> section actually changed.

But I repeatedly experienced that when I change the priority in the
package, it is not changed in the archive. liberfa1 is an example here.

Probably the most common case is like this one: the priority in the
package changed, but the overrides file keeps it at the old value, so
they actually differ. What is the use of this? Why can't I change the
Priority of my packages on my own? This seems to make a change
extra->optional unnecessarily complicated, and involves the
always-overloaded ftp-master in a process where I don't see a policy
risk.

Best regards

Ole

Re: [clamav-users] Remove clamav-unofficial-sigs

[Paul Wise]

On Sun, Apr 10, 2016 at 8:10 PM, Joel Esler (jesler) wrote:

> Luca is no longer with the ClamAV project.

Removed from CC.

> our community signature program:

Unfortunately this isn't suitable for the distribution of the
3rd-party rules that we are talking about, there is a list of the
current ones here:

https://github.com/extremeshok/clamav-unofficial-sigs

To replace that code with freshclam, there would probably need to be:

A directory where configuration files can be dropped in.

A way to specify where to get files from.

A way to specify the OpenPGP key or similar for each provider.

A way to specify per-downloader secrets for the paid providers.

> the same QA and FP regression test that we do our signatures.

Are these regression tests published?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Priorities overrides? Extra?

[Jakub Wilk]

* Ole Streicher , 2016-04-10, 14:22:

When I look into the "overrides" file for debian stretch:

http://ftp.debian.org/debian/indices/override.stretch.main.gz

I find there more than 48.000 overrides; which means that almost *all* 
packages are overridden.


Exactly _all_ binary packages are in the override file.

That doesn't mean that that every single package had their priority or 
section actually changed.


--
Jakub Wilk

Re: Packaging of static libraries

[Alastair McKinstry]

On 10/04/2016 08:05, Andreas Tille wrote:
> Hi,
>
>   > The only use case I could imagine is to create an executable that can
>   > run outside of Debian.
Static builds are still common in (parts of) scientific computing.
Two main reasons:

(1) When performance matters. Here we need the static library to be
built without
position independent code. This can still give several percent gains
depending
on arch / programming language.
Hence the library needs to be built differently than for shared libs. I
typically use
separate debian/build-{shared,static} directories or the cmake equivalent.

(2) Long-lived executables. e.g. for time series in Earth obs, climate
work, where you want
to guarantee reproducibility / biases of an executable built two years ago.
Often in such science its more important to know and track bugs/biases
than to repair.

>   That's a valid use case for consumer of the lib*-dev package.
>
> remained unanswered but it seems there might be some need what "usually
> provided in addition" might mean and whether it is advisable to try hard
> to provide static libraries even if upstream build system does not
> easily provide both.
>
> Kind regards
>
>   Andreas.
>
> [0] https://lists.debian.org/debian-mentors/2016/04/msg00183.html
> [1] 
> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static
>
Kind regards
Alastair

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Re: [clamav-users] Remove clamav-unofficial-sigs

[Joel Esler (jesler)]

> On Apr 10, 2016, at 12:10 AM, Paul Wise  wrote:
> 
>> On Wed, Apr 6, 2016 at 3:47 PM, Mathieu Parent wrote:
>> 2016-04-06 6:55 GMT+02:00 Paul Wise:
>>> Personally I am still waiting for clamav freshclam to properly support
>>> third-party signatures, so clamav-unofficial-sigs can be a config file.
>> 
>> Is there a tracking bug for this? How can we help?
> 
> This was an upstream initiative that now appears to be completely
> removed from their website. Some references still exist on archive.org
> though:
> 
> https://wayback.archive.org/web/http://www.clamav.net/lang/en/2011/07/25/clamav-0-97-2-is-now-available/
> https://wayback.archive.org/web/http://www.clamav.net/lang/en/download/cvd/3rdparty/
> 
> CCing Luca from the clamav project, perhaps he has some news about this.


Luca is no longer with the ClamAV project.   The way that we support these 
right now is through our community signature program:
http://blog.clamav.net/2014/02/introducing-clamav-community-signatures.html

This way we can send all sigs distributed through the same QA and FP regression 
test that we do our signatures. We even have a monthly contest that we award 
people for submissions:
http://blog.clamav.net/2016/03/clamav-monthly-community-signature.html

Priorities overrides? Extra?

[Ole Streicher]

Hi all,

Paul Wise gave me the hint that for one of my packages (src:erfa) the
"Priority" field is overwritten (it is "extra", while I specified
"optional" in the package).

When I look into the "overrides" file for debian stretch:

http://ftp.debian.org/debian/indices/override.stretch.main.gz

I find there more than 48.000 overrides; which means that almost *all*
packages are overridden.

What is the reason for that? I would expect that overriding is something
exceptional, but not the common way to set the priority?

Looking into the priorities, I found:

 66 required
 64 important
 86 standard
  34854 optional
  13191 extra

which means that almost one third of the packages is priority
"extra". From the policy, I would expect that the main reasons to give
the priority "extra" are either a conflict with another package, or the
dependency on a package with priority "extra".

However, when I look for "extra" packages which have "conflicts", I
found only ~450 packages that have this field set (and that do not
conflict with themself, f.e. an earlier version). And from the "extra"
packages, about 12.000 are not affected by these (so they could, by
policy, have priority "optional").

Since "optional" gives the safety of having no conflicts, I wonder why

 * so many packages have priority "extra"

 * this cannot be changed by simply changing it in the package (since it
   stays overridden in the ftp-master's override file).

The rationale behind this question is the preparation of default
installations within the Debian Pure Blends concept. For a default
installation (selected by install-cd's tasksel), it is expected to have
no conflicts in the installation. The easiest way to achieve this would
be to use only "optional" packages. This, however does not work in the
moment, since there are so many packages in the blends with priority
"extra" (of whoose the majority could easily set to "optional").

What is the idea behind the current structure?

Best regards

Ole

Bug#820593: ITP: imip-agent -- agent programs to handle calendar information in e-mail

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: imip-agent
  Version : 0.1
  Upstream Author : Paul Boddie 
* URL : http://groupware.boddie.org.uk/imip-agent
* License : GPL-3+
  Programming Lang: Python
  Description : agent programs to handle calendar information in e-mail

 imip-agent is an extension for existing MTAs (mail transport agents)
 providing extra support for calendaring and scheduling.
 .
  * It uses the iCalendar, iTIP and iMIP Internet standards.
  * It can inspect messages containing calendar objects and extract
availability information for sharing and publication. You and your
users decide exactly which kind of messages it will inspect, whose
messages it will inspect, and for whom no inspection or sharing will
occur at all.
  * It can provide a Web-based interface to calendar information for
users who cannot or choose not to use mail software with calendaring
support. This is optional and your users can choose to adjust,
ignore or disable this functionality.
  * It supports autonomous entities such as meeting rooms and resources,
automatically accepting or declining invitations according to their
schedules. You can adjust this behaviour to implement your own
policies.
 .
 Unlike some monolithic groupware solutions...
  * It does not require you to change your MDA (mail delivery agent) or
your mail storage software,
  * It does not require your users to change their MUAs (mail user
agents).
  * It does not insist that everybody must store their schedules on a
single server in order to collaboratively schedule events.
  * Instead, imip-agent takes advantage of the decentralized nature of
the iCalendar and iMIP Internet standards.
  * It allows people in your organisation to collaborate with people
outside your organisation without insisting that they join your
infrastructure or that everybody join some cloud service that keeps
everyone's information within a single, typically proprietary,
remote service (that may also be potentially vulnerable to intrusion
and surveillance).
 .
 The role of imip-agent is to bridge the gap between plain e-mail and
 "full-stack" groupware solutions, thus allowing organisations and
 individuals to augment their existing infrastructure instead of being
 compelled to perform costly and unnecessary migrations and
 infrastructure transformations.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXCj2gAAoJECx8MUbBoAEhlHgP/08OhEaXmxqbZITu/7ZQX/a9
IsLyGGkwq9Vhytf1mjP+WYVYXpK3sCSq8jDy2buRxsHYN6XsLCD8ARgj02RqX/H5
vAIfZPGMNdxm1hAXnGLdfhe+fTmg+17hF4PgAJUitQtqTxXubmsAENK+dijaNBRb
xCwhNNSErBIS0KG+5ZFC61zWvrCflug9F74NeVVYJyZqgEX89MaGcbeNZHwIWIPc
BeBR8IJcdkQehBCOQZEbiCX6+kQSOaO3IYaQUC/2tGyH/jHBTQaFgTbc/6gRcqz8
KrbncpwyeN66fXoZK8ZITWR7vTZUqm4OmTM6LM0Jqyx0Y5O9uO1wV+lNZeWaUzn4
oXfx0jMfzqh21kJwiAok7GxNoj+Qd+utg/yReYEI71h7KamnDaKkD9AAqPzY1pDS
CMv+9PWumiBZ2ni/sDnZNLnz/QFeYH6rFOYbZ0GEFVDszg4iudBc9b2rJAr4AUXY
xpkJqUNR56uBJ7ND6t1Gg76bewmhsXpmblXH3iU9u8KmAh04ql8U+mnBvkLB9ba7
KeY7O0ic6HUh9ti+VZNrDzlxxpwcE4zjWZjq3sLTxm7Bim5lVgd7wENl/ZMbMYNX
IKXkl8RSXmfA/dUxTxvYS8nL3VAzgZmPEShxcnVuOSx1OBiNCbynZda2YPBv+LDg
/JIdg7/la3qAs7nV3LAd
=DsIM
-END PGP SIGNATURE-

Re: /usr/bin/openssl failed on sso.debian.org

[Jonas Smedegaard]

Quoting Enrico Zini (2016-04-10 11:20:51)
> On Sun, Apr 10, 2016 at 11:20:07AM +0200, Jonas Smedegaard wrote:
>>> If WebID has a workable plan for what to do after  
>>> disappears, I haven't seen it. If you have, please send me precise 
>>> details[1]: I haven't seen any in 
>>> https://www.w3.org/mid/20150730174424.GA7779@c
>>
>> I am unaware of them being magicians.  Some of them have put together 
>> Javascript for execution in the browser.  I guess you already know 
>> about (and dislike) that workaround.
>
> I don't know of that workaround, and you didn't send me a link to any 
> detail about it.

Sorry, I was mistaken: I (wrongly!) understood from past discussions 
that some had made a javascript shim for keygen (and others being 
strongly sceptic about the security implications of that), but looking 
closer I now realize that javascript approaches to client-side certs 
only at most do pure-JS computation of the key but then spit out the 
result as a file for the user to manually install - i.e. _not_ handling 
the keygen part after all (if I have understood this correctly).

Here's summaries for the main WebID implementations: 
https://www.w3.org/wiki/Foaf%2Bssl/IDP - among those, I believe only the 
myprofile.eu is not entangled in a large database infrastructure - but 
unfortunate myprofile.eu seems currently down... :-/

As I recall, the central piece for generating X.509 as client-side 
Javascript with myprofile.eu is https://github.com/juliangruber/keypair


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: /usr/bin/openssl failed on sso.debian.org

[Enrico Zini]

On Sun, Apr 10, 2016 at 11:20:07AM +0200, Jonas Smedegaard wrote:

> > If WebID has a workable plan for what to do after  disappears, 
> > I haven't seen it. If you have, please send me precise details[1]: I 
> > haven't seen any in https://www.w3.org/mid/20150730174424.GA7779@c
> 
> I am unaware of them being magicians.  Some of them have put together 
> Javascript for execution in the browser.  I guess you already know about 
> (and dislike) that workaround.

I don't know of that workaround, and you didn't send me a link to any
detail about it.


Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: /usr/bin/openssl failed on sso.debian.org

[Jonas Smedegaard]

Quoting Enrico Zini (2016-04-10 10:44:02)
> On Sat, Apr 09, 2016 at 11:25:34PM +0200, Jonas Smedegaard wrote:
>>> I have seen no sign that Chrome or Firefox developers have much 
>>> interest in supporting WebID either, and given how I've seen one of 
>>> the WebID people argue their case[1] with the Chrome and Firefox 
>>> developers, the little interest they might have had to start with is 
>>> probably gone by now :/
>>
>> You can consider both WebID itself and the social skills of its 
>> defenders bad, yet still benefit from following their work.
>
> What is have seen of their work is that it relies on the same features 
> that we use on sso.debian.org, and when those will go away, both 
> sso.debian.org and webid will stop working.

Ah, so you are aware of their work already.  Good.


> If WebID has a workable plan for what to do after  disappears, 
> I haven't seen it. If you have, please send me precise details[1]: I 
> haven't seen any in https://www.w3.org/mid/20150730174424.GA7779@c

I am unaware of them being magicians.  Some of them have put together 
Javascript for execution in the browser.  I guess you already know about 
(and dislike) that workaround.


> [1] patches would be even better, because sso.debian.org is a service 
> that I DO NOT WANT TO MAINTAIN, and I'm just stuck with it because I 
> seem to be the person in Debian that needs an authentication system 
> the most (for nm.debian.org and contributors.debian.org).

I am aware.  Pointing you at fellow developers is as far as my skills 
reach in this area, unfortunately.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: /usr/bin/openssl failed on sso.debian.org

[Enrico Zini]

On Sat, Apr 09, 2016 at 11:25:34PM +0200, Jonas Smedegaard wrote:

> > I have seen no sign that Chrome or Firefox developers have much 
> > interest in supporting WebID either, and given how I've seen one of 
> > the WebID people argue their case[1] with the Chrome and Firefox 
> > developers, the little interest they might have had to start with is 
> > probably gone by now :/
> 
> You can consider both WebID itself and the social skills of its 
> defenders bad, yet still benefit from following their work.

What is have seen of their work is that it relies on the same features
that we use on sso.debian.org, and when those will go away, both
sso.debian.org and webid will stop working.

If WebID has a workable plan for what to do after  disappears, I
haven't seen it. If you have, please send me precise details[1]: I
haven't seen any in https://www.w3.org/mid/20150730174424.GA7779@c


[1] patches would be even better, because sso.debian.org is a service
that I DO NOT WANT TO MAINTAIN, and I'm just stuck with it because I
seem to be the person in Debian that needs an authentication system the
most (for nm.debian.org and contributors.debian.org).


Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Packaging of static libraries

[Andreas Tille]

Hi,

when I was asking for help to create shared *and* static library on
Debian Mentors list[0] I received two answers that static libraries
are not needed.  My reply

  Policy says[1]:

   The static library (libraryname.a) is usually provided in addition to
   the shared version. 

  I have no good reason to derive from this.

  > The only use case I could imagine is to create an executable that can
  > run outside of Debian.

  That's a valid use case for consumer of the lib*-dev package.

remained unanswered but it seems there might be some need what "usually
provided in addition" might mean and whether it is advisable to try hard
to provide static libraries even if upstream build system does not
easily provide both.

Kind regards

  Andreas.

[0] https://lists.debian.org/debian-mentors/2016/04/msg00183.html
[1] 
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static

-- 
http://fam-tille.de