Re: autopkgtest results influencing migration from unstable to testing

[Holger Levsen]

On Wed, May 02, 2018 at 11:09:46PM +0200, Paul Gevers wrote:
> tl;dr: migration from unstable to testing is influenced by the results
> of autopkgtest tests of your own package as well as those of your
> reverse dependencies. 

AWESOME

Thank you to everone who worked and works on this!

 
-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Dealing with ci.d.n for package regressions

[Ian Jackson]

Paul Gevers writes ("Re: Dealing with ci.d.n for package regressions"):
> On 03-05-18 14:12, Ian Jackson wrote:
> > 3. "Required age increased by 10 days because of autopkgtest"
> > seems to appear when either (i) when there are tests that should be
> > run but which haven't completed and (ii) when some tests newly failed ?
> > I wasn't able to see any examples of the latter.
> 
> I gave an example link to python3.6 which worked at the time of writing,
> but of course (that how it goes) changed by an new upload. python2.7
> seems to show one: libgnatcoll (bug filed: 895235)

Thanks.  That is quite a clear report with a helpful link, indeed.

> > 4. Can we have a way to trigger tests from updates of non-direct
> > rdepends ?  At some point in the future maybe we will run tests of
> > whole batches of updates and then have some algorithm to chop out
> > what the failures are caused by, but for now it would be useful to
> > be able to declare a specific indirect dependency for test trigger.
> > Maybe an XS- header field ?
> 
> Just add it as a test dependency in one of your tests?

I hadn't realissed that _test_ dependencies would trigger retests, as
well as actual package dependencies.

Doing as you suggest for a real test feels wrong, since it involves
denormalising (in the relational database sense) the dependency graph.

But I guess I could introduce a test which does nothing, but which has
as direct dependencies the indirect dependencies I want to be retested
for.  It's a bit of a bodge but if we invented a feature name for this
test it would even give us an upgrade path:

  Tests: some-empty-shell-script
  Depends: indirect-dep-1, indirect-dep-2
  Features: hint-indirect-dependencies-retest

And then if we later add a more `proper' way of saying the same thing,
it can understand this old way of writing it.  Or we can ignore it if
we have a better way of doing the same thing later.

What do people think ?

> > 5. AIUI there is no automatic way for the maintainers of the
> > rdependency to be notified of a test failure which is blocking
> > migration of one of their dependencies.  Is that right ?  The result
> > is probably that if the maintainers of the dependency don't follow it
> > up, the regression will migrate and the rdepenency maintainers will be
> > left to fix it up.
> 
> No, it's all manual and currently I am doing most triaging (bunk and
> ginggs have contributed multiple bugs as well). The last couple of weeks
> I was able to file most bugs before the short expiry of 5 days, now with
> 15 days the task gets easier. If error messages and output are clean,
> this isn't so difficult. However, quite often output is hopeless for a
> bystander and difficult to judge the root cause and the severity. I hope
> we can improve this in the future by pointing people to the right tools
> (do they exist (for all languages)?) such that output gets standardized
> a bit more than currently.

For my part I'm sorry that the output from autopkgtest itself is not
always easy to navigate.

But, anyway, thanks for your effort, but it obviously doesn't scale to
have the central infrastructure team triage things.  How easy would it
be to have the CI automatically send an email to the maintainers of
the rdependency and the dependency ?

I think we need to get into the habit of the maintainers talking to
each other about these kind of things, before we start increasing the
blocking time.  Otherwise we risk developing a culture where the
dependency's maintainers usually do some kind of workaround, which the
rdependency's maintainers may find out about much later if at all.

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: Dealing with ci.d.n for package regressions

[Ian Jackson]

Mattia Rizzolo writes ("Re: Dealing with ci.d.n for package regressions"):
> On Thu, May 03, 2018 at 10:38:45PM +0200, Paul Gevers wrote:
> > Just add it as a test dependency in one of your tests?
> 
> Just to share a bit that doesn't seem to be of public knowledge:
> .dsc have a Testsuite-Triggers field that is autopoulated from the
> d/tests/control file (IIRC).  I believe you are looking exactly for
> this field.

Really ?  /me looks.  Cor, so there is.

Is that documented somewhere ?  I can't find it here
  https://manpages.debian.org/stretch/dpkg-dev/dpkg-source.1.en.html
  https://manpages.debian.org/stretch/dpkg-dev/deb-src-control.5.en.html

Presumably I want some way to extend what is put there automatically.

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: Dealing with ci.d.n for package regressions

[Ian Jackson]

Ian Jackson writes ("Re: Dealing with ci.d.n for package regressions"):
> I hadn't realissed that _test_ dependencies would trigger retests, as
> well as actual package dependencies.

Having read Mattia's message, and looking at the Testsuite-Triggers
line which is autogenerated in dgit.dsc, I see that actual package
dependencies are not included.

That seems wrong to me.  foo/debian/tests/control will normally
declare a dependency on foo (perhaps by saying `@'); it then won't
normally mention all of foo's dependencies.

The result of the current behaviour is that regressions introduced by
test framework code are more likely to be detected than regressions
introduced by ordinary dependencies.

Also, and perhaps I should have spotted this earlier:

Doing the calculation of Testsuite-Triggers in dpkg-source means that
fixing this involves changing dpkg-source on developes' systems.  So
if I want this to be fixed for my own uploads, from my laptop which is
running stretch, I will need to wait for the improved dpkg-source to
be in stretch-backports and then update that.  It doesn't seem right
that the contents of Testsuite-Triggers should depend on the tooling
on the uploader's workstation.

I appreciate that the real reason for this design decision is probably
that it is difficult to change the software on ftp.debian.org :-/.

Anyway, I guess I should think about sending patches for dpkg-source ?
If someone could point me at the docs for this Testsuite-Triggers
construction feature then that would give me a leg up.

Thanks,
Ian.

Re: Dealing with ci.d.n for package regressions

[James Clarke]

On Fri, May 04, 2018 at 11:55:56AM +0100, Ian Jackson wrote:
> Mattia Rizzolo writes ("Re: Dealing with ci.d.n for package regressions"):
> > On Thu, May 03, 2018 at 10:38:45PM +0200, Paul Gevers wrote:
> > > Just add it as a test dependency in one of your tests?
> >
> > Just to share a bit that doesn't seem to be of public knowledge:
> > .dsc have a Testsuite-Triggers field that is autopoulated from the
> > d/tests/control file (IIRC).  I believe you are looking exactly for
> > this field.
>
> Really ?  /me looks.  Cor, so there is.
>
> Is that documented somewhere ?  I can't find it here
>   https://manpages.debian.org/stretch/dpkg-dev/dpkg-source.1.en.html
>   https://manpages.debian.org/stretch/dpkg-dev/deb-src-control.5.en.html

It's in the .dsc, so you want dsc(5) :)

> Testsuite-Triggers: package-list
>This field declares the comma-separated union of all test
>dependencies (Depends fields in debian/tests/control file),
>with all restrictions removed, and OR dependencies flattened,
>except for binaries generated by this source package and
>meta-dependencies such as @ or @builddeps@.
>
>Rationale: this field is needed because otherwise to be able to
>get the test dependencies, each source package would need to be
>unpacked.
 -- https://manpages.debian.org/stretch/dpkg-dev/dsc.5.en.html

James

Re: Dealing with ci.d.n for package regressions

[Guillem Jover]

On Fri, 2018-05-04 at 12:08:31 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Dealing with ci.d.n for package regressions"):
> > I hadn't realissed that _test_ dependencies would trigger retests, as
> > well as actual package dependencies.
> 
> Having read Mattia's message, and looking at the Testsuite-Triggers
> line which is autogenerated in dgit.dsc, I see that actual package
> dependencies are not included.

Right.

> That seems wrong to me.  foo/debian/tests/control will normally
> declare a dependency on foo (perhaps by saying `@'); it then won't
> normally mention all of foo's dependencies.
> 
> The result of the current behaviour is that regressions introduced by
> test framework code are more likely to be detected than regressions
> introduced by ordinary dependencies.

I'm not sure why this is a problem, though? The CI system in use can
easily choose to inject all of foo's dependencies as triggers. And AFAIK
that's already the case?

> Also, and perhaps I should have spotted this earlier:
> 
> Doing the calculation of Testsuite-Triggers in dpkg-source means that
> fixing this involves changing dpkg-source on developes' systems.  So
> if I want this to be fixed for my own uploads, from my laptop which is
> running stretch, I will need to wait for the improved dpkg-source to
> be in stretch-backports and then update that.  It doesn't seem right
> that the contents of Testsuite-Triggers should depend on the tooling
> on the uploader's workstation.

That's no different to so many other fields, which get generated from
other stuff by several tools from the toolchain?

If the desire here is to make it easier to control what gets output,
we could handle this field as we handle the Testsuite one, and append
to it if it already exists in debian/control for example (I'd need to
go back to the original discussion in case we already considered that
but rejected it for some reason), but as you've noticed elsewhere you
can already control it by adding (dummy) entries in debian/tests/control.

> I appreciate that the real reason for this design decision is probably
> that it is difficult to change the software on ftp.debian.org :-/.

The main design decision here, was to avoid needing to unpack the source
packages on the archive side, regardless of what that software might be.

Thanks,
Guillem

Re: RFC: Support for zstd in .deb packages?

[Guillem Jover]

Hi!

On Mon, 2018-04-30 at 20:23:15 +, Nick Terrell wrote:
> On Fri, 27 Apr 2018, Guillem Jover wrote:
> [...]
> > * Format stability: Although it's supposedly frozen now, it has
> > changed quite often in recent times. AFAIR it was also mentioned at
> > least in the past that the target was mainly real-time data streaming,
> > so long-term data storage might not be a priority? Would need
> > clarification from upstream I guess.
> 
> I'm one of the upstream maintainers of zstd. If you have any questions,
> please feel free to either open an issue on the issue board [1] or email
> me or Yann Collet (CCed).

Perfect, thanks for reaching out!

> The format has been stable since version 0.8.1, which was released on
> August 18th 2016. We have an RFC draft describing the compression
> format in progress [2], so we are completely committed to keeping the
> format stable.
> 
> Long-term data storage is as much a priority for us as real-time data
> streaming. IMO one of the strengths of Zstandard is the ability to maintain
> the same fast decompression speed at every compression level. That
> allows both real-time streaming and long-term storage to use the same
> format.

Thanks for the clarification!

Regards,
Guillem

Re: RFC: Support for zstd in .deb packages?

[Guillem Jover]

Hi!

On Fri, 2018-04-27 at 07:02:12 +0200, Guillem Jover wrote:
> The following is a quick run-down of the items from [F], not all
> being important from Debian's perspective, but being for dpkg's:

> * License: Permissive (dual BSD + GPL-2), which makes universal
>   availability possible.

Unfortunately, I've just noticed that the project requires a CLA,
which means universal contributions are *not* possible. :(

  
  

Nick & Yann, I'm assuming this is some corporate requirement from
Facebook, and it's probably not going to go away?

Thanks,
Guillem

Re: Dealing with ci.d.n for package regressions

[Ian Jackson]

James Clarke writes ("Re: Dealing with ci.d.n for package regressions"):
> On Fri, May 04, 2018 at 11:55:56AM +0100, Ian Jackson wrote:
> > Is that documented somewhere ?  I can't find it here
> >   https://manpages.debian.org/stretch/dpkg-dev/dpkg-source.1.en.html
> >   https://manpages.debian.org/stretch/dpkg-dev/deb-src-control.5.en.html
> 
> It's in the .dsc, so you want dsc(5) :)

Ah, thanks.  Looks like there is no way to control it from the source
package.  There is a difficulty with implementing that.  The
Test-Triggers ought to mention autocomputed dependencies.  Eg, if we
have

   foo/debian/tests/control
  Depends: @

   foo/debian/control:
  Build-Depends: libbar-dev
  Depends: ${shlibs:Depends}, ${misc:Depends}

   foo.deb:
  Depends: libbar1 (>= 1.2-0)

then we should have

   Testsuite-Triggers: libbar1

This can't be computed from the source package because it depends on
the version of libbar-dev.  It can't even be computed as source upload
time.

I think therefore that tests should be triggered based, additionally,
on binary package dependencies as found in the archive.  For every
binary package B which is produced by a source package S and depends
on another binary package D: tests of S should be retriggered for
updates to D.  "Depends on" would probably mean "is mentioned as first
alternative in any Depends on Recommends requirement".  This can be
determined from the published metadata without unpacking any source
packages or looking at Testsuite-Triggers.

(In theory this should only be done for binary packages B which are
not only generated by S but also mentioned, perhaps by virtue of `@',
in the Depends on a test of S.  This could be determined from
Testsuite-Triggers except that Testsuite-Triggers is specified to
exclude @ish dependencies.)

Arguably the test triggers from Depends in debian/tests/control are
less important and could even be dropped.  But in any case dpkg-source
should have explicit way to control or supplement.
Testsuite-Triggers.

I'm happy to write a patch to do the latter.  I'm not sure where I
would start with the former but I would be willing to give it a go if
someone would point me in the right direction.

Thanks,
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: Dealing with ci.d.n for package regressions

[Ian Jackson]

Paul Gevers writes ("Dealing with ci.d.n for package regressions"):
> As I just announced on d-d-a¹, we have enabled autopkgtest usage for
> unstable-to-testing migration.

I observe that the tests done for this are done without building the
source, where this is a feature advertised by the test suite.

At some point it might be worth disabling this autopkgtest feature,
and triggering retests on build-depends.  That would make the whole
system an automatic rebuild test.

Ian.

Bug#897900: ITP: node-turbolinks -- Turbolinks makes navigating your web application faster

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-turbolinks
  Version : 5.1.1
  Upstream Author : packagethief, sstephenson
* URL : https://github.com/turbolinks/turbolinks#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Turbolinks makes navigating your web application faster
 Get the performance benefits of a single-page application without the added
 complexity of a client-side JavaScript framework. Use HTML to render your
 views on the server side and link to pages as usual. When you follow a
link,
 Turbolinks automatically fetches the page, swaps in its , and merges
 its , all without incurring the cost of a full page load.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Re: Firefox 60esr on Stretch ?

[Moritz Mühlenhoff]

Julien Cristau  schrieb:
> I expect nothing much different from previous ESR cycles: stretch will 
> move to 60 after 52 goes EOL in September.

Exactly.

Cheers,
Moritz

Bug#897903: ITP: soapsnp -- resequencing utility that can assemble consensus sequence of genomes

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: soapsnp
* URL : http://soap.genomics.org.cn/soapsnp.html
* License : GPL
  Description : resequencing utility that can assemble consensus sequence 
of genomes

Packaging team-maintained on https://salsa.debian.org:med-team/soapsnp

Re: Firefox 60esr on Stretch ?

[W. Martin Borgert]

Quoting Moritz Mühlenhoff :

Julien Cristau  schrieb:

I expect nothing much different from previous ESR cycles: stretch will
move to 60 after 52 goes EOL in September.


Exactly.


How will we deal with breaking extensions?

E.g. I'm using xul-ext-scrapbook a lot. AFAIK, upstream does
not provide a post-XUL version. Probably other extensions will
face the same compatibility issue.

Should we just remove them from stable?

Bug#897907: ITP: hashcheck -- verifies the files on a live mounted ISO image

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 

* Package name: hashcheck
  Version : 1.0.0
  Upstream Author : Kyle Robbertze 
* URL : https://gitlab.com/paddatrapper/hashcheck
* License : GPL-3+
  Programming Lang: C++
  Description : verifies the files on a live mounted ISO image

Provides a graphical interface to verify a live mounted ISO image.
The image is expected to be mounted under /lib/live/mount/medium
It is useful as part of a live environment

This is a part of AIMS desktop and will be packaged for use in that,
though it is useful in Debian too.

Bug#897908: ITP: soapaligner -- aligner of short reads of next generation sequencers

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: soapaligner
* URL : http://soap.genomics.org.cn/soapaligner.html
* License : GPL
  Programming Lang: C
  Description : aligner of short reads of next generation sequencers

Package team-maintained on https://salsa.debian.org/med-team/soapaligner

Re: Firefox 60esr on Stretch ?

[Emilio Pozuelo Monfort]

On 04/05/18 17:42, W. Martin Borgert wrote:
> Quoting Moritz Mühlenhoff :
>> Julien Cristau  schrieb:
>>> I expect nothing much different from previous ESR cycles: stretch will
>>> move to 60 after 52 goes EOL in September.
>>
>> Exactly.
> 
> How will we deal with breaking extensions?
> 
> E.g. I'm using xul-ext-scrapbook a lot. AFAIK, upstream does
> not provide a post-XUL version. Probably other extensions will
> face the same compatibility issue.
> 
> Should we just remove them from stable?

I guess so, yes. There's not much we can do if there is no support for newer
versions.

Emilio

Re: Dealing with ci.d.n for package regressions

[Chris Lamb]

Chris Lamb wrote:

> I can hack together quick things like:

I just noticed that UDD has lintian results, so you can just write
this as:

(Spoilers: I'm not a SQL programmer)

   SELECT source, CASE (SELECT COUNT(*) FROM lintian
   WHERE package = source AND package_type = 'source' AND
   tag = 'testsuite-autopkgtest-missing') WHEN 0 THEN 'yes' ELSE
   'no' END AS has_autopkgtests FROM popcon_src ORDER BY insts DESC
   LIMIT 100;
   
 source | has_autopkgtests
+--
 dpkg   | no
 sed| no
 attr   | no
 debianutils| no
 bzip2  | no
 pam| no
 tar| no
 coreutils  | no
 acl| no
 zlib   | no
 util-linux | yes
 ncurses| no
 shadow | no
 base-passwd| no
 grep   | yes
 base-files | no
 gzip   | no
 findutils  | no
 hostname   | no
 debconf| no
 e2fsprogs  | no
 apt| yes
 perl   | no
 adduser| yes
 readline   | no
 readline6  | yes
 lsb| no
 netbase| no
 gnupg2 | yes
 gnupg  | yes
 gcc-4.4| yes
 gcc-6  | no
 gcc-4.9| yes
 gcc-8  | no
 gcc-4.7| yes
 gcc-7  | no
 sysvinit   | no
 libgpg-error   | yes
 bash   | no
 libselinux | no
 libsepol   | no
 eglibc | yes
 glibc  | yes
 slang2 | no
 procps | no
 popt   | no
 tzdata | no
 debian-archive-keyring | no
 cpio   | no
 ucf| no
 bsdmainutils   | no
 liblocale-gettext-perl | yes
 logrotate  | no
 libedit| no
 libtext-iconv-perl | no
 wget   | no
 popularity-contest | no
 pcre3  | no
 mawk   | no
 expat  | no
 newt   | no
 cron   | no
 tcp-wrappers   | no
 iputils| no
 libidn | no
 sqlite3| no
 libtext-charwidth-perl | no
 systemd| yes
 udev   | yes
 libtext-wrapi18n-perl  | no
 openssh| yes
 iptables   | yes
 ifupdown   | yes
 keyutils   | yes
 gettext| no
 lvm2   | no
 freetype   | no
 klibc  | no
 cyrus-sasl2| no
 pciutils   | no
 libcap2| yes
 vim| yes
 libxml2| yes
 libusb | no
 libxdmcp   | no
 libxau | no
 initramfs-tools| no
 openssl| no
 dmidecode  | no
 libx11 | no
 file   | no
 mime-support   | no
 openldap   | no
 libxcb | yes
 python-defaults| no
 groff  | no
 gdbm   | no
 libxext| no
 busybox| no
 dash   | yes
(100 rows)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Firefox 60esr on Stretch ?

[The Wanderer]

On 2018-05-04 at 12:22, Emilio Pozuelo Monfort wrote:

> On 04/05/18 17:42, W. Martin Borgert wrote:

>> How will we deal with breaking extensions?
>> 
>> E.g. I'm using xul-ext-scrapbook a lot. AFAIK, upstream does not
>> provide a post-XUL version. Probably other extensions will face the
>> same compatibility issue.
>> 
>> Should we just remove them from stable?
> 
> I guess so, yes. There's not much we can do if there is no support
> for newer versions.

Though please do take note of other applications which may still work
with them.

Even leaving other Mozilla-based browsers aside, ISTR there being (or
having been?) some extensions which would work just fine in both Firefox
and Thunderbird, and since Thunderbird is retaining XUL support - at
least for now - there may be some value in retaining such "overlap"
extensions for people who use them there.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Firefox 60esr on Stretch ?

[Carsten Schoenert]

Hi,

Am 04.05.18 um 18:38 schrieb The Wanderer:
...
>> I guess so, yes. There's not much we can do if there is no support
>> for newer versions.
> 
> Though please do take note of other applications which may still work
> with them.
> 
> Even leaving other Mozilla-based browsers aside, ISTR there being (or
> having been?) some extensions which would work just fine in both Firefox
> and Thunderbird, and since Thunderbird is retaining XUL support - at
> least for now - there may be some value in retaining such "overlap"
> extensions for people who use them there.

well, there is some support for legacy extensions in Thunderbird > 57.0
<= 60.x. But, the authors of such plugins need to make some adjustments
within their AddOns to get them work with the upcoming TB ESR 60.x

https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_57

My experience right now is this is simply not happen for a significant
amount of Thunderbird AddOns, all my extensions I normally want to use
do not work with TB 60. So it will be a long road to walk.

For Thunderbird there are probably more problems to fix. The old way of
packaging XUL based extensions into /u/s/xul-ext/$extension isn't
working out of the box anymore and I've no idea why nor had I time to
take a deeper look at this issue. I can't speak for Firefox but I expect
a similar situation here. The last FF version in Debian right now is
59.0.2. Maybe Mike can say something on this.

We will also need to fix some build issues before any version uploaded
to unstable can enter testing.

https://bugzilla.mozilla.org/show_bug.cgi?id=1434589

-- 
Regards
Carsten

Re: Firefox 60esr on Stretch ?

[Moritz Mühlenhoff]

W. Martin Borgert  schrieb:
> Quoting Moritz Mühlenhoff :
>> Julien Cristau  schrieb:
>>> I expect nothing much different from previous ESR cycles: stretch will
>>> move to 60 after 52 goes EOL in September.
>>
>> Exactly.
>
> How will we deal with breaking extensions?

Same as all previous extension breakages incurred by ESR transitions;
not at all. Apart from enigmail those are all not updated along
in stable, this doesn't scale at all. If you want your extensions
to be kept compatible, get them from the Mozilla addons page
like every other Firefox/Thunderbird user.

We should make it easy for administrators of bigger desktop
deployments to easily create debs for local deployments, but
keeping all those extensions in a stable release is just
broken and we should block them from testing migration.

Cheers,
Moritz

Re: Firefox 60esr on Stretch ?

[W. Martin Borgert]

On 2018-05-04 21:12, Moritz Mühlenhoff wrote:
> Same as all previous extension breakages incurred by ESR transitions;
> not at all. Apart from enigmail those are all not updated along
> in stable, this doesn't scale at all. If you want your extensions
> to be kept compatible, get them from the Mozilla addons page
> like every other Firefox/Thunderbird user.

This is not something I would consider.
If a software is not in Debian, I just don't use it.
(Or only with the objective to bring it into Debian.)
 
> We should make it easy for administrators of bigger desktop
> deployments to easily create debs for local deployments, but
> keeping all those extensions in a stable release is just
> broken and we should block them from testing migration.

Why? We have now a huge breakage for all XUL extensions, but
were there problems of a similar scale before? Do we have to
expect similar breakages in the future with the new API?

Re: Firefox 60esr on Stretch ?

[Holger Levsen]

On Fri, May 04, 2018 at 10:52:26PM +0200, W. Martin Borgert wrote:
> On 2018-05-04 21:12, Moritz Mühlenhoff wrote:
> > Same as all previous extension breakages incurred by ESR transitions;
> Why?

because this is what the modern web has become in 2018. go gopher go!


-- 
cheers,
Holger, SCNR


signature.asc
Description: PGP signature

Re: Firefox 60esr on Stretch ?

[Moritz Mühlenhoff]

W. Martin Borgert  schrieb:
> On 2018-05-04 21:12, Moritz Mühlenhoff wrote:
>> Same as all previous extension breakages incurred by ESR transitions;
>> not at all. Apart from enigmail those are all not updated along
>> in stable, this doesn't scale at all. If you want your extensions
>> to be kept compatible, get them from the Mozilla addons page
>> like every other Firefox/Thunderbird user.
>
> This is not something I would consider.
> If a software is not in Debian, I just don't use it.

Your call. Don't use the extensions, then.

> Why? We have now a huge breakage for all XUL extensions, but
> were there problems of a similar scale before? Do we have to
> expect similar breakages in the future with the new API?

Sure, plenty of addons needed updates to remain compatible
with later Firefox (ESR) releases in the past. This model
is broken for many years already, totally independant of
the switch to web extensions.

Cheers,
Moritz

Re: RFC: Support for zstd in .deb packages?

[Nick Terrell]

> On May 4, 2018, at 6:22 AM, Guillem Jover  wrote:
> 
> Hi!
> 
> On Fri, 2018-04-27 at 07:02:12 +0200, Guillem Jover wrote:
>> The following is a quick run-down of the items from [F], not all
>> being important from Debian's perspective, but being for dpkg's:
> 
>> * License: Permissive (dual BSD + GPL-2), which makes universal
>>  availability possible.
> 
> Unfortunately, I've just noticed that the project requires a CLA,
> which means universal contributions are *not* possible. :(
> 
>  
>  
> 
> Nick & Yann, I'm assuming this is some corporate requirement from
> Facebook, and it's probably not going to go away?

Yup, it is here to stay.

-Nick

Re: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

[Svante Signell]

On Fri, 2018-05-04 at 23:16 +0200, Mattia Rizzolo wrote:
> Yavor,
> 
> On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> > Andreas Tille wrote:
> > > What's the correct way to fix the symbols file to work with both
> > > versions of gcc?

> Guess what, C++ is more complex than C.

Sorry for being uniformed/not knowing: But why log symbols at all? It
seems to be very much not needed. If so tell me why it is!

Forbidding Firefox addons from testing & stable (was: Firefox 60esr on Stretch ?)

[Sean Whitton]

Hello,

On Fri, May 04 2018, Moritz Mühlenhoff wrote:

> Same as all previous extension breakages incurred by ESR transitions;
> not at all. Apart from enigmail those are all not updated along in
> stable, this doesn't scale at all. If you want your extensions to be
> kept compatible, get them from the Mozilla addons page like every
> other Firefox/Thunderbird user.
>
> We should make it easy for administrators of bigger desktop
> deployments to easily create debs for local deployments, but keeping
> all those extensions in a stable release is just broken and we should
> block them from testing migration.

Is there a precedent for declaring a whole class of packages RC-buggy,
yet continuing to offer them in the unstable and experimental suites
(that it what we would need in order to make it easy for administrators
to create those debs: we'd need to be actively using the tooling
ourselves)?

In this case, I take it the point is that the special exception for
updating src:firefox-esr in stable justifies excluding packages that
effectively depend on specific versions of firefox-esr.

The only case I know of a package that will never migrate to testing,
but isn't RMed, is a single package, src:firefox.

It would also be good to know what the Release Team think of Moritz's
proposal, since they have authority over what goes into testing.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Firefox 60esr on Stretch ?

[Stephan Seitz]

On Fr, Mai 04, 2018 at 09:12:39 +0200, Moritz Mühlenhoff wrote:

Same as all previous extension breakages incurred by ESR transitions;
not at all. Apart from enigmail those are all not updated along
in stable, this doesn't scale at all. If you want your extensions
to be kept compatible, get them from the Mozilla addons page
like every other Firefox/Thunderbird user.


Then drop firefox/thunderbird from debian as well. If you don’t want to 
do it right (meaning with all the extensions), then don’t do it.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Firefox 60esr on Stretch ?

[Vincent Bernat]

 ❦  4 mai 2018 23:22 +0200, Moritz Mühlenhoff  :

>> Why? We have now a huge breakage for all XUL extensions, but
>> were there problems of a similar scale before? Do we have to
>> expect similar breakages in the future with the new API?
>
> Sure, plenty of addons needed updates to remain compatible
> with later Firefox (ESR) releases in the past. This model
> is broken for many years already, totally independant of
> the switch to web extensions.

WebExtensions are backed by a standard draft:
https://browserext.github.io/browserext/. So, situation is expected to
improve in the future.
-- 
Say what you mean, simply and directly.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature