Re: Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Daniel Stenberg]

On Tue, 20 Feb 2018, Steve Langasek wrote:

In fact, some of us who remember are still around ;-)  The historical 
context here is that curl upstream made a determination that the SONAME 
should be bumped for an "ABI break" that was not an ABI break in any 
traditional sense, didn't appear to break compatibility in any meaningful 
way


I too am still around! I was the main curl developer upstream then and I am 
still that now and I disagree with that description.


In 2006 we (the curl project) broke compatiblity with older libcurls by 
removing support for several options that we previously supported, involving 
what is called "third party FTP transfers". Hence, the API was made not 
backwards-compatible which according to me warrants an SONAME bump.


I still believe it was the right decision we made in the curl project back 
then. I leave it to you to discuss what the best decision is or was for 
Debian.


(And for the record: we have not bumped the SONAME since...)

--

 / daniel.haxx.se

Bug#834854: Direktoriaus kontaktai - tai Jūsų klientas

[Gautas pranešimas]

Laba diena,


Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos 
įmonių bazės 2018 metų sausio vidurio.
Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys 
veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą.
 
Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, 
transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje.
 
Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis.
 
 
Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis:
 
1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė 
tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai 
bendrausite su direktoriais, komercijos vadovais.
 
2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus 
kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės 
skolingos Sodrai.
 
3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus 
galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių 
siunčiate elektroninius laiškus.
Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas.
 
 
Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia.
( Sąrašas prisegtas laiške excel faile )
 
Parašykite, kurias veiklas išsirinkote 
ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti



Pagarbiai,
Tadas Giedraitis
Tel. nr. +37067881041


Veiklos.xlsx
Description: Binary data

Re: openafs bug 886768

[Benjamin Kaduk]

On Tue, Feb 20, 2018 at 10:49:36PM +0100, Moritz Mühlenhoff wrote:
> On Tue, Feb 20, 2018 at 01:56:12PM -0600, Benjamin Kaduk wrote:
> > 
> > It's probably also worth noting that this is not the first time that
> > a linux security update caused an openafs regression,
> 
> The only sane way to avoid such occasional breakage is to upstream
> the OpenAFS kernel module into the Linux kernel. As long as this doesn't
> happen, it'll inevitably happen again.

The IBM copyright and IBM Public License on a lot of the code would
make that difficult, as I understand it.  But there is an AFS client
in the kernel, David Howells' "kafs", which is seeing active
development (but is not really in a usable state in the stable
kernel, let alone oldstable).

-Ben

Re: Proposed (lib)curl switch to openssl 1.1

[Steve Langasek]

Hi all,

Dimitri drew my attention to this bug and the associated PR, because Ubuntu
is now in the process of transitioning to openssl 1.1 as well, and we have
somewhat shorter timelines in order to complete the transition in time for
Ubuntu 18.04 LTS (releasing in April).

Alessandro wrote:

> last time a transition of libcurl was attempted some 10 years or so ago,
> it was halted for reasons now lost in the mists of time, so we have been
> stuck carrying some hacks to pretend we are still using the old SONAME

In fact, some of us who remember are still around ;-)  The historical
context here is that curl upstream made a determination that the SONAME
should be bumped for an "ABI break" that was not an ABI break in any
traditional sense, didn't appear to break compatibility in any meaningful
way, and imposing this as an SONAME transition in Debian would simply make
upgrades brittle for no real reason.

Maintaining compatibility was the right thing to do.

However, compatibility was maintained in a way that *also* maximized
portability of binaries between Debian and other distributions, by adopting
the libcurl.so.4 SONAME and providing libcurl.so.3 as a symlink (and
retaining the libcurl3 package name) for backwards-compatibility in Debian.

Now, it appears that somewhere along the way, upstream adopted symbol
versioning which is incompatible with that used in Debian, because upstream
symbols are named CURL_${FLAVOR}_4 and ours are named CURL_${FLAVOR}_3.  So
that's somewhat unfortunate, and means we're no longer as binary-compatible
as we were.  However, symbol versioning is great, and it's entirely possible
to fix the libraries to be binary-compatible with all versions of both
upstream and Debian binaries which ship the same ABI.

Which brings me to the first question:  if this is an ABI break with
existing libcurl.so.4, what is curl upstream's position on SONAME changes?
In 2007, they were quite aggressive about renaming in the face of possible
API breaks - are they now ignoring an ABI break that will straight up cause
callers to segfault?

I think it's always best practice to follow upstream's behavior wrt SONAMEs,
and to always change package names when we know that the ABI we're exposing
has changed.  So if upstream is changing the SONAME because of this
transition, then it's easy to follow them and change the package name at the
same time.  But if upstream is not changing the SONAME, we should change the
package name while keeping the same SONAME and adding conflicts against
libcurl3.

Now, the other thing is: 

> Due to the fact that the previous transition (libcurl3 -> libcurl4) was
> partially reverted (in 2007 according to the changelog), I'd also like to
> taeke this opportunity to finally complete that as well, so I made a patch
> to not only rename libcurl3 -> libcurl4, but also (libcurl3-gnutls,
> libcurl3-nss) -> (libcurl4-gnutls, libcurl4-nss), and remove the hacks
> needed to keep compatibility with the previous ABI.

I think this is a very bad idea.

The ABI is breaking due to changes to an OpenSSL object type being returned
by the library.  This means that the ABI is changing *only* for the OpenSSL
variant of the library.

And, in Debian unstable:

$ apt-cache rdepends libcurl3 | wc -l
115
$ apt-cache rdepends libcurl3-gnutls | wc -l
378
$ apt-cache rdepends libcurl3-nss | wc -l
8
$

Changing the package names for the libraries whose ABI has *not* changed
(and does not need to be changed by Debian, wrt SONAME or symbol versions)
will make the transition 4x bigger than it would be from changing libcurl3
alone.  If anything, if you do believe that it's important to clean up the
library package names in a way that forces a transition (which I have argued
against above), then you should at least do this /separately/ from the
transition of libcurl3 for openssl, in order to not entangle the two
otherwise-unrelated transitions.

And as Adrian writes:

>> Maybe it would be wise to suggest to upstream to bump major 4 to a 5 to
>> signal that this libcurl exposes the libssl1.1 ABI now.

> "now" was 2016.

> Back then this would have been a valid point, but after other
> distributions already ship with OpenSSL 1.1 and the old libcurl soname it
> is too late for that.

> The package name is the only thing we can change without diverging from
> other distributions.

So, despite Julien's valid objection that core library conflicts cause
dist-upgrades to be more brittle, I think the right answer here is:

- keep all sonames as-is.
- rename libcurl3 to libcurl4.
- leave the package names of the other variants as-is.
- *if* libcurl-gnutls.so.4 and libcurl-nss.so.4 sonames are known to exist
  elsewhere outside the Debian ecosystem, fix the symbol versions for
  libcurl3-gnutls and libcurl3-nss to use symbol aliases, so that CURL_FOO_4
  is used as the preferred name and CURL_FOO_3 is for compatibility only.
  (This is only worth doing if this increases binary compatibility;
  otherwise it's better to 

Re: openafs bug 886768

[Moritz Mühlenhoff]

On Tue, Feb 20, 2018 at 01:56:12PM -0600, Benjamin Kaduk wrote:
> On Tue, Feb 20, 2018 at 08:51:16PM +0100, Salvatore Bonaccorso wrote:
> > Hi Thorsten,
> > 
> > On Tue, Feb 20, 2018 at 02:45:48PM +0100, Thorsten Alteholz wrote:
> > > Hi everybody,
> > > 
> > > the latest security update of the kernel to version 3.2.0-5 in Jessie
> > > resulted in #886768 [1] for openafs.
> > > 
> > > Wouldn't it be better to do the openafs upload via security as well?
> > > At the moment openafs in Jessie is just broken until the next point 
> > > release.
> > 
> > Whilest one arguably can say that the issue was introduced/uncovered
> > by a security update, the package has already been accepted by the SRM
> > (thanks for that to Julien and Adam!).
> > 
> > So affected persons could already install the fixed packages via
> > proposed-updates, but maybe Julien and Adam can be conviced that an
> > update is important enought to schedule an update earlier via a SUA?
> 
> It's probably also worth noting that this is not the first time that
> a linux security update caused an openafs regression,

The only sane way to avoid such occasional breakage is to upstream
the OpenAFS kernel module into the Linux kernel. As long as this doesn't
happen, it'll inevitably happen again.

Cheers,
Moritz

Re: openafs bug 886768

[Benjamin Kaduk]

On Tue, Feb 20, 2018 at 08:51:16PM +0100, Salvatore Bonaccorso wrote:
> Hi Thorsten,
> 
> On Tue, Feb 20, 2018 at 02:45:48PM +0100, Thorsten Alteholz wrote:
> > Hi everybody,
> > 
> > the latest security update of the kernel to version 3.2.0-5 in Jessie
> > resulted in #886768 [1] for openafs.
> > 
> > Wouldn't it be better to do the openafs upload via security as well?
> > At the moment openafs in Jessie is just broken until the next point release.
> 
> Whilest one arguably can say that the issue was introduced/uncovered
> by a security update, the package has already been accepted by the SRM
> (thanks for that to Julien and Adam!).
> 
> So affected persons could already install the fixed packages via
> proposed-updates, but maybe Julien and Adam can be conviced that an
> update is important enought to schedule an update earlier via a SUA?

It's probably also worth noting that this is not the first time that
a linux security update caused an openafs regression, and thus not
the first time that this question has been raised.  I don't have a
great recollection of the specific arguments presented from previous
instances, but do remember that the conclusion was to not treat the
openafs change as a security update.  So presumably some compelling
new argument would be desired in order to actually reopen the
discussion.

-Ben

Re: openafs bug 886768

[Salvatore Bonaccorso]

Hi Thorsten,

On Tue, Feb 20, 2018 at 02:45:48PM +0100, Thorsten Alteholz wrote:
> Hi everybody,
> 
> the latest security update of the kernel to version 3.2.0-5 in Jessie
> resulted in #886768 [1] for openafs.
> 
> Wouldn't it be better to do the openafs upload via security as well?
> At the moment openafs in Jessie is just broken until the next point release.

Whilest one arguably can say that the issue was introduced/uncovered
by a security update, the package has already been accepted by the SRM
(thanks for that to Julien and Adam!).

So affected persons could already install the fixed packages via
proposed-updates, but maybe Julien and Adam can be conviced that an
update is important enought to schedule an update earlier via a SUA?

Regards,
Salvatore

Bug#890935: transition: console-bridge

[Jose Luis Rivero]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team:

console-bridge 0.4.0 is now in experimental, we can start the transition
for the existing packages to the archive currently using console-bridge.
The following source packages need to be rebuild:

ros-actionlib_1.11.12-1
ros-class-loader_0.3.8-1
ros-geometry2_0.5.16-1
ros-rosconsole-bridge_0.5.1-1
ros-roscpp-core_0.6.7-1
urdfdom_1.0.0-2
ros-bond-core_1.8.1-2
ros-ros-comm_1.13.5+ds1-1
ros-dynamic-reconfigure_1.5.49-1
ros-geometry_1.11.9-1

I think that in terms of 'ben' lingo, the transition has the following
parameters:

title = "console-bridge";
is_affected = .depends ~ "libconsole-bridge0.2v5" | .depends ~ 
"libconsole-bridge0.4";
is_good = .depends ~ "libconsole-bridge0.4";
is_bad = .depends ~ "libconsole-bridge0.2v5";

Please schedule binNMUs for the above mentioned packages on all
architectures.

Thanks you.
 Jose

openafs bug 886768

[Thorsten Alteholz]

Hi everybody,

the latest security update of the kernel to version 3.2.0-5 in Jessie 
resulted in #886768 [1] for openafs.


Wouldn't it be better to do the openafs upload via security as well?
At the moment openafs in Jessie is just broken until the next point 
release.


  Thorsten

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886768

Bug#890897: transition: unibilium

[James McCoy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

There is an upstream SONAME bump due to support for terminfo's new wide
format.  The dependency chain revolves around neovim and everything
rebuilds and tests fine with the new unibilium.

Ben file:

title = "unibilium";
is_affected = .depends ~ "libunibilium0" | .depends ~ "libunibilium4";
is_good = .depends ~ "libunibilium4";
is_bad = .depends ~ "libunibilium0";


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

AIDE

[coumba coulibaly]

Bonjour , 

J'ai installé DEBIAN 9.3  sur virtualbox . Je n'arrive pas à installer PHP et 
mysql . On me ramène toujours les problèmes de dépendances.Merci de m'aider

Bug#890889: stretch-pu: package yorick-av/0.0.4-1

[Thibaut Paumard]

Package: release.debian.org
Severity: normal
Tags: patch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

yorick-av has an important bug (important impact on usability, does not make
the package totally useless) that I only notice now while working on porting
this package to the upcoming FFmpeg in experimental:

https://bugs.debian.org/890880

The fix is one-line in the C code (at two places).

While I am working on more details for unstable, I would like to be given the
opportunity to upload this one-liner fix to stable.

I attach a source diff.

Kind regards, Thibaut.

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
diff --git a/debian/changelog b/debian/changelog
index 5a2c216..188f477 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+yorick-av (0.0.4-2) stable; urgency=low
+
+  * Bug fix: "AVPacket timestamps need to be rescaled for most codecs"
+(Closes: #890880).
+
+ -- Thibaut Paumard   Tue, 20 Feb 2018 11:37:10 +0100
+
 yorick-av (0.0.4-1) unstable; urgency=low
 
   * New upstream release
diff --git a/debian/patches/rescale-ts b/debian/patches/rescale-ts
new file mode 100644
index 000..bf934fc
--- /dev/null
+++ b/debian/patches/rescale-ts
@@ -0,0 +1,29 @@
+Description: Rescale frame timestamps
+ Without this, the timestamps are wrong with most codecs, making the
+ output garbage.
+Author: Thibaut Paumard 
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890880
+Forwarded: not-needed
+Applied-Upstream: ed6b754e03f280708991f579db42dca136431c35
+Last-Update: 2018-02-20
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/yav.c
 b/yav.c
+@@ -391,6 +391,7 @@
+ AVPacket pkt;
+ av_init_packet();
+ pkt.flags |= AV_PKT_FLAG_KEY;
++av_packet_rescale_ts(, c->time_base, obj->video_st->time_base);
+ pkt.stream_index = obj->video_st->index;
+ pkt.data= obj->video_outbuf;
+ // pkt.size= out_size;
+@@ -408,6 +409,7 @@
+ }
+ /* If size is zero, it means the image was buffered. */
+ if (!ret && got_packet && pkt.size) {
++  av_packet_rescale_ts(, c->time_base, obj->video_st->time_base);
+   pkt.stream_index = obj->video_st->index;
+   /* Write the compressed frame to the media file. */
+   ret = av_interleaved_write_frame(obj->oc, );
diff --git a/debian/patches/series b/debian/patches/series
index e69de29..6c46fab 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -0,0 +1 @@
+rescale-ts