provide something that
is better than what is already available elsewhere.
The worst case would be if we have to tell more frequently to users
"Please don't use the packages in our stable release." because they
are worse than alternatives.
> Cheers,
> OdyX
>...
c
On Fri, Mar 09, 2018 at 02:07:19AM +0100, gregor herrmann wrote:
> On Thu, 08 Mar 2018 23:03:17 +0200, Adrian Bunk wrote:
>
> > The first question should always be if/how we can provide something that
> > is better than what is already available elsewhere.
>
> An answe
is much more restricticted than the permitted
syntax for (build) dependencies.
Dependency fields have negative syntax like !m68k, for the Architecture:
field this is only possible with a complete list of all architectures
except the one you want to exclude.
cu
Adrian
--
"Is t
TBFS on big endian
- FTBFS on 32bit
- FTBFS on architectures where char is unsigned
I would not see the benefits of tagging 8 ports when the pattern of
red/green makes it clear that the problem is due to char being unsigned.
There are special cases like conf
me.
When I see a bug "FTBFS on big endian" with "help" tag and a maintainer
statement in the bug "I don't care about big endian but I am willing
to apply patches", then that's all I need to know.
> Ian.
cu
Adrian
--
"Is there not prom
paque OpenSSL struct).
OpenSSL is special due to two versions being supported in stretch,
otherwise a Conflicts between libssl1.0.2 and libssl1.1 might have
been a good solution.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of th
es, but for past incorrect epoch usage all that can
be done is to limit the damage.
Things that cannot be undone for moon-buggy:
- the epoch
- two files moon-buggy_1.0.51-1.dsc exist in Debian,
with different contents [2]
What can be done for moon-buggy is to use a Debian revision that doesn't
r
On Mon, Apr 02, 2018 at 08:30:54PM +0200, Christian T. Steigies wrote:
> Moin,
Hi,
> On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> >
> > There are two problems here.
> >
> > The first is the use of an epoch in a situation where it shouldn't
ke c_rehash currently does) but as
> explained above it should not be required to use it.
>...
If c_rehash gets removed before buster, please add appropriate Breaks
for the non-fixed stretch packages to openssl, to avoid problems similar
to #894282 during stretch->buster upgades.
>
no record anywhere that this version
was already taken by some random person from the internet who once
upon a time uploaded it to mentors.d.n.
> cheers,
> Holger
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. Th
On Mon, Apr 09, 2018 at 02:24:23PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW
> process"):
> > A version is published to our users when it gets accepted into
> > the archive.
> >
> > Readable inf
On Wed, Apr 11, 2018 at 02:05:03PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > Imagine tomorrow a random person from the internet noone has ever heard
> > of uploads a package dgit 5.0 to mentors.d.n.
>
> > It is clear that this would not be sponsored.
On Mon, Apr 09, 2018 at 04:12:47PM +0100, Simon McVittie wrote:
> (I don't speak for the GNOME team, or for Josselin, who is officially
> this package's maintainer; please don't assume I do.)
>
> On Sun, 08 Apr 2018 at 22:19:43 +0300, Adrian Bunk wrote:
> > I
rchive.
What happens outside of our archive (e.g. in Ubuntu or .debian.net)
is nothing we officially provide to our users.
> Ian.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain fo
Do you have any proof that the victim was actually notified in any
way at the time of the hijack?
> cheers,
> Holger
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
On Sat, Apr 14, 2018 at 01:00:08PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW
> process"):
>...
> > What happens outside of our archive (e.g. in Ubuntu or .debian.net)
> > is nothing we officially provide to our
ferently than LANG=C?
Estonian (et_EE) sorts z between s and t.
> Mike Stone
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
or extra work
(in several cases Python 2 modules were dropped in a new Debian
revision of a package without any real reason).
There are of course cases (e.g. OpenStack) where providing Python 2
modules in buster is not possible with reasonable effort.
Thanks
Adrian
--
"Is ther
On Mon, Apr 23, 2018 at 05:49:32PM +0200, Helmut Grohne wrote:
> On Sat, Apr 21, 2018 at 08:57:55PM +0300, Adrian Bunk wrote:
> > The tip of the iceberg are some recent cases where Python 2 modules
> > were dropped that still had reverse dependencies in unstable, but
> > a
eate security fixes
for the Python 2 interpreter for many years to come).
> Cheers,
>
> Thomas Goirand (zigo)
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only
ually a good sign that there
will be many more users whom you would cause problems without these
Python 2 modules.
In practice "problems" might often imply "you cannot upgrade to buster"
or "you cannot use Debian".
> Cheers,
>
> Thomas Goirand (zigo)
cu
Adria
On Thu, Apr 26, 2018 at 12:03:56AM +0200, Thomas Goirand wrote:
> On 04/25/2018 06:14 PM, Adrian Bunk wrote:
> > On Tue, Apr 24, 2018 at 12:10:12AM +0200, Thomas Goirand wrote:
> >> ...
> >> This cannot go on, and on, and on, and on... We have to send a clear
> >
On Thu, Apr 26, 2018 at 10:35:10AM -0700, Don Armstrong wrote:
> On Thu, 26 Apr 2018, Adrian Bunk wrote:
> > We (Debian) have decided to support Python 2.7 in buster, like it or
> > not.
> >
> > At that point it is not up to individual maintainers to sabotage
> >
On Thu, Apr 26, 2018 at 06:19:24PM +0100, Ian Jackson wrote:
>...
> Adrian: are you volunteering to write patches to solve Helmut's cross
> building problem ?
I am willing to stop for several weeks/months to monitor RC bugs and
report FTBFS if you can make the case that it is more
On Fri, Apr 27, 2018 at 01:06:03PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Please do not drop Python 2 modules"):
> > On Thu, Apr 26, 2018 at 06:19:24PM +0100, Ian Jackson wrote:
> > > Adrian: are you volunteering to write patches to solve Helmut&#x
where something like faster setup
of cloud servers would matter are not the ports with slow buildds or
where 64 MB memory usage would matter much on any supported hardware.
> Thanks,
> Guillem
cu
Adrian
[1] we are talking about perhaps 5-10% smaller packages and faster
decompress
On Fri, Apr 27, 2018 at 03:08:24PM +0200, Thomas Goirand wrote:
> On 04/26/2018 07:14 PM, Adrian Bunk wrote:
> > On Thu, Apr 26, 2018 at 12:03:56AM +0200, Thomas Goirand wrote:
> >> On 04/25/2018 06:14 PM, Adrian Bunk wrote:
> >>> On Tue, Apr 24, 2018 at 12:10:12
On Mon, Apr 30, 2018 at 06:47:41PM -0400, Jeremy Bicha wrote:
> On Sun, Apr 8, 2018 at 3:19 PM, Adrian Bunk wrote:
>
> Sorry for not replying more promptly.
>
> > I hereby declare my intent to adopt gconf.
>
> Why? Basically there are only two things left in Buste
fy them a bit?
>...
"purge" might happen decades (sic) after "remove" with no dependencies
installed and packages that are essential today no longer being essential.
> Cheers,
> Dan
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked
is still reachable:
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-xml-sgml-pkgs
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Most important will be Breaks for all affected packages in *stretch*,
since there might otherwise be nasty problems in stretch->buster
upgrades depending on the undefined order of package upgrades.
> Cheers,
>
> Thomas Goirand (zigo)
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
rm64 and mips64el have been a burden
in recent years.
And the next burden will be if riscv64 gets added in bullseye.
I do not have the impression that this burden is unmanageable, but if
you disagree the actual discussion you have to start is about delaying
the inclusion of ports for new hardware
s - the risk is too high that the private key either
gets accidentally compromised (see Emdebian) or intentionally planted
(see NSA/FBI/GCHQ/FSB/...).
> bye,
> pabs
cu
Adrian
[1] https://tracker.debian.org/pkg/emdebian-archive-keyring
--
"Is there not promise of rain?
onsidered
"giving root access to the people operating this repository".
This also opens the general question whether 3rd party repositories
should become strongly discouraged in general, and flatpak/snap/...
recommended instead.
cu
Adrian
--
"Is there not promise of rain?&qu
far Debian has completely failed on properly vetting and
DSA-maintaining 3rd party keys in Debian releases.
> Sean Whitton
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Aug 21, 2018 at 04:20:14PM +0200, Adam Borowski wrote:
> On Tue, Aug 21, 2018 at 05:07:21PM +0300, Adrian Bunk wrote:
> > This also opens the general question whether 3rd party repositories
> > should become strongly discouraged in general, and flatpak/snap/...
> >
y on GitHub giving his fringe programs names like "bat" or "fd",
the sane solutions are to either rename or not package.
Making it easy for fringe programs to take over already used names
would cause more trouble that it would be worth.
> Cheers,
> Sylvestre
>...
cu
Adri
On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
> Dear Adrian,
Dear Chris,
> > This is fake news.
>
> Please try and avoid casual use of this term on Debian lists.
>
> Whilst I understand your meaning and intentions, the term has now been
> so overused and
ecoming a good solution.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
therefore usually not a problem.[1]
Recommends are basically dependencies you are allowed to break when
you know what you are doing, and that's the level of expertise someone
is expected to have when optimizing disk space usage.
> Ian.
cu
Adrian
[1] "libfoo pulls in 100 MB of data
better off with just automake (>= 1.11) anyway, so I haven't filtered
> those out.
What you describe is somewhere between "minor" and not worth reporting.
But several packages have
automake1.11 | automake (>= 1:1.11)
Ouch.
> Regards,
> S
>...
cu
Adrian
--
Package: wnpp
Severity: wishlist
Owner: Adrian Alves
* Package name: passh
Version : 1.7.1
Upstream Author : Ivan Ariel Barrera Oro
* URL : https://github.com/HacKanCuBa/passh
* License : GPL-3
Programming Lang: bash
Description : passh: a pass fork
> people away.
>...
Non-informative frontpages like the LXDE one are what scares me away.
The contents of the Gentoo homepage is similar to what Debian has but
presented with a different CSS - something like that would be a good
improvement.
cu
Adrian
--
"Is there not promis
owing packages:" or "installing this package will
remove debian-security-support".
cu
Adrian
[1]
http://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security
[2]
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.h
be for ldc?
Every ABI-changing version of the default compiler will then be a small
library transition that should be executed via the normal transition
process.
IMHO this would be a better solution than any kind of "ship source code
instead of libraries" hacks.
> Cheers,
>
e point mainstream.
No disagreement from me that anything other than amd64 in unusual and
should be non-default, just pointing out that new i386-only hardware was
still being sold and popular nearly a decade after 2004.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked s
package (e.g. pulseaudio) when it would otherwise be pulled in
through recommends.
> Regards,
> Christian
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
mats that prevents GCC from releasing tarballs with
> lzip.
>...
GCC is actually pretty much the worst example for two reasons:
First, Debian already repackages the upstream tarballs (to .tar.xz)
for reasons unrelated to the compression format (GFDL).
Second, the GCC tarball (the repackaged
supported compression formats.
>...
A digital signature is an ECC layer.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
y none of the above has an answer right now, and that is OK.
My point is that these are topics that have to be started soon
if it shouldn't be too late for buster.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
would make a relatively hard to exploit issue appear more
worrisome to a user than installing a browser engine with zero
security support and more than 100 unfixed CVEs.
> Regards,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darknes
es Uploaders: as the intersection
of current team members and people who did the latest 10 uploads
of a package.
cu
Adrian
[1] a few people are IMHO just bad maintainers, but in the common
case there is simply too much work for too few people in a
volunteer project and new team members
dividual, it is no more a team, yet
> the package is still maintained and need not be orphaned.
Your objection does not make sense.
The change Sean is proposing is intended to make providing the
information about team members in Uploaders: optional.
If are not objecting to removing the
On Thu, Aug 03, 2017 at 12:30:11PM +0300, Adrian Bunk wrote:
> On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> > On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > > Bill Allombert writes:
> > > > On Wed, Aug 02, 2017 at 05:48:
On Thu, Aug 03, 2017 at 12:36:04PM -0400, Sean Whitton wrote:
> On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> > Please be more thoughtful about the consequences of such changes to policy.
> >
> > This would not be "a purely informative change".
>
eam maintaining 1 package)
this is also a way for seeing when 0 team members are left who
are still active in Debian.
> Cheers,
> gregor
cu
Adrian
[1] or retired, all this is about what happens after it has been
determined that a person is no longer active in Debian
--
&quo
ices without the current notifications
from the MIA team that a team member is no longer active in Debian.
You are assuming that the team has a non-zero number of active members
left after a member becomes MIA.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Aug 03, 2017 at 08:16:30PM -0400, gregor herrmann wrote:
> On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:
>
> > On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > > What I don't understand in the point of view of the "keep Uploade
On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
>
> I agree, but that's not directly relevant here, since we'
a different place outside the packages would
fix the problem of losing information about team membership.
Or the low-change option of documenting that the already used way of
autogenerating the Uploaders list based on information stored in one
core package of the team is a valid option - thi
On Fri, Aug 04, 2017 at 06:20:31PM -0700, Sean Whitton wrote:
> Hello,
>
> On Fri, Aug 04 2017, Adrian Bunk wrote:
>
> > Autogenerating Uploaders like GNOME does [1] would be an alternative
> > approach.
> >
> > [1]
> > https://sources.debian.net/src/g
ge ?
> > Using [] for non-team members is very common.
>
> for getting the _uploaders_ it's not even required to parse those fields, as
> each upload has one uploader which is semantically strict defined already.
Policy says that Uploaders contains the _co-maintainers_.
And that a
On Sat, Aug 05, 2017 at 03:28:57PM +, Holger Levsen wrote:
> On Sat, Aug 05, 2017 at 10:39:02AM +0300, Adrian Bunk wrote:
> > > I don't understand this suggestion. If it can be automatically
> > > generated, just generate it when you need it -- why store it i
teams.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
u and to package
maintainers by lintian, with automated checking by lintian
actually more reliable than information in the BTS.
And maintainers who ignore lintian results in their packages tend to be
the same people who ignore non-RC bugs in their packages.
> Matthias
cu
Adrian
--
a maintainer do based on a python3-app bug or lintian warning?
"Please convert to Python3, the 2021 release of Debian will drop Python2"
sounds hilarious if sent to upstream today.
> Matthias
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly o
pendency on avx-512-ifma-support [any-i386 any-amd64]
be OK for such a library?
> Meow!
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
- 73 teams maintaining a single package
A package with 500 LOC might have an own team:
https://qa.debian.org/developer.php?email=hostname-de...@lists.alioth.debian.org
cu
Adrian
[1] grep -Ei '^Maintainer.*(team|maintainer|lists.alioth.debian.org).*'
--
"Is there not promis
es (Go, gcl, haskell) that are either buggy
due to one bug or can be whitelisted together.
The majority of packages in the amd64 list seem to be binaries built by Go.
I checked one case in a package, and that was code with proper runtime
detection copied from golang-1.8 (Go doesn't have shared
tinue to ship the software in stable.
But comparing backports with a flatpak solution for users who want the
latest upstream code, I see all the benefits at the flatpak solution.
When it is both less work for Debian and a better result for users,
I do not see the point why Debian should compete with th
doesn't hit.
One nice part about including it in lintian is that this gives the
maintainer a standard way to indicate that the package had been
confirmed to only select such instructions after autodetection of
the cpu features by adding a lintian override.
cu
Adrian
--
"Is ther
7, 2017 at 04:48:54PM +0300, Adrian Bunk wrote:
>
> Approximate data based on grep'ing Packages[1]:
> - 466 teams maintaining packages in unstable
> - 8 is the median number of packages maintained by a team
> - 73 teams maintaining a single package
>
> A package with 500
Do you really want to ship *patches*, and not just copies of all
changed files?
Patching binaries to a new upstream version doesn't sound to me like
something that would make sense.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the d
any effort been made to create a coherent
policy for buster for all packages that contain a TLS implementation?
> Kurt
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
amable changes, while not changing the amount of
TLS 1.0/1.1 using software in Debian substantially.
Nothing that Debian does alone will have any measurable impact
on TLS 1.0 usage.
> Kurt
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of
encouraged to
consider TLS v1.2.
> ciao,
> Marco
cu
Adrian
[1]
https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had b
int) faces the reality that
a significant share of the customers is using ancient Android
releases with a firmware that are several years old.
It doesn't matter whether something works with newer Android phones,
or what you consider a security issue.
The only thing you would achieve would
On Fri, Aug 18, 2017 at 10:07:49PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>...
> The PCI consortium extended the deadline until June
> 2018. Assuming that deadline holds, people with older machines will not
> be able to access services such as online banking or pay onli
On Sun, Aug 20, 2017 at 01:51:16PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>...
> > Think of the "TLS 1.2 not working with WPA" discussed earlier here that
> > might still affect half a billion active Android devices at the buster
> > release date.[
ducible, this would
be a huge fail itself.
AFAIK the only place where we currently still need binary packages that
have been built on a maintainer machine is for NEW, and after someone
has implemented a solution for that there is no blocker left for
allowing only source-only uploads f
tested in the r-b infrastructure are quite different.
I would strongly object to raising the severity to "important" for
packages where it is not proven that they are not reproducible according
to current [1] policy.
> Regards,
cu
Adrian
[1] current at the time of the severity rais
On Fri, Sep 01, 2017 at 09:43:54AM +, Holger Levsen wrote:
> On Fri, Sep 01, 2017 at 09:34:53AM +0300, Adrian Bunk wrote:
> > On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote:
> > >...
> > > However, based on an informal survey at DebConf (and to reflec
On Thu, Oct 05, 2017 at 03:52:56AM +0200, Adam Borowski wrote:
>...
> But, Adrian Bunk warned that this makes violating the baseline too easy.
> And indeed, I just noticed an attempt to use an extension in a way I don't
> consider to be valid: #864012. I understand the maint
do support non-SSE2 in a previous
Debian stable but cannot be made to compile without SSE2-support now?
> Regards,
> Aron
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"
might not even notice if the
port is broken on the baseline.
If anyone is running stretch, buster or sid on ARMv4t hardware,
then please let us know what device and kernel you are using
and whether you intend to use buster.
cu
Adrian
[1] https://lists.debian.org/debian-arm/2017/08/msg00046
On Tue, Nov 07, 2017 at 01:43:50PM +0100, Héctor Orón Martínez wrote:
>...
> 2017-11-05 22:32 GMT+01:00 Adrian Bunk :
>
> > for the armel port in buster the question of raising the baseline came up.
>
> That has been a recurring question over the time, the reason to
> mai
t for buster will also end in mid-2022,
so if buildds (and likely porterbox) are still required
for armhf then armel hw needs are already covered.
> Cheers,
> Julien
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There ha
t for stretch.
Every time the topic of armel-specific major problems comes up people
are either not nameing any specific problems, or they mention problems
that were fixed long ago.
> Wookey
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
o
g some hard to resolve bugs), so assuming
there are < 1k packages that have to be fixed with the trivial one-line
opt-out change "Rules-Requires-Root: binary-targets" a flag day would
be doable.
> Thanks,
> ~Niels
cu
Adrian
--
"Is there not promise of rain?"
On Sat, Nov 11, 2017 at 09:03:04PM +0100, Andreas Henriksson wrote:
> Hello,
>
> On Tue, Nov 07, 2017 at 11:10:27PM +0200, Adrian Bunk wrote:
> [...]
> > This whole "so many packages are broken on armel" narrative
> > is actually mostly FUD, and you ar
kage, the package should probably stay at compat 10
> until buster is released.
Is anything preventing a backport of cmake to stretch-backports?
This would allow debhelper to add Breaks on older cmake versions,
which would also automatically handle all backports situations
in a correct way.
&g
Package: libqt5opengl5-dev
Version: 5.9.2+dfsg-4
Severity: normal
Tags: patch
Different from other architectures, on armel and armhf
Qt in Debian is configured to use OpenGL ES instead
of full OpenGL.
Some OpenGL-related functionality in Qt is not available
with OpenGL ES, and Qt also offers dire
if done manually.[2]
If you want to automate that it is fine, but the majority of maintainer
work on a new upstream version is what happens after the automated part
or if the automated part fails. And this maintainer work should happen
before the package hits users in sid.
> Many thanks f
On Mon, Nov 20, 2017 at 09:37:10AM +, Lars Brinkhoff wrote:
> Adrian Bunk wrote:
> > If anyone is running stretch, buster or sid on ARMv4t hardware, then
> > please let us know what device and kernel you are using and whether
> > you intend to use buster.
>
> M
aging of Node.js modules.
There are more than half a million Node.js modules available.
These could be automatically packaged into half a million
Debian packages.
> I prefer this so much that in some cases I have considered packaging
> the thing myself and becoming one of these "dis
On Thu, Nov 30, 2017 at 06:36:59PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Auto-update for sid? Auto-backport?"):
> > Sometimes I see bug reports in the BTS where it is evident that a user
> > has spent hours or days on debugging an issue and writing a mar
On Sun, Oct 25, 2015 at 05:33:19PM +0100, Jonas Smedegaard wrote:
[Context: http://bugs.debian.org/685878]
> > We're now more than three years behind upstream (3.0 released
> > 2012-07-09).
> > My github repo is still waiting to be integrated with Debian.
> And my point is still that there's an R
Package: wnpp
Severity: wishlist
Owner: Adrian Alves
* Package name: gmilk
Version : 0.1.2
Upstream Author : eustaquioran...@gmail.com
* URL : https://github.com/taq/gmilk
* License : GPL
Programming Lang: Python
Description : GTK tray icon for
Package: wnpp
Severity: wishlist
Owner: Adrian Alves
* Package name: python-daemonocle
Version : 0.8
Upstream Author : Jonathan Robson
* URL : https://github.com/jnrbsn/daemonocle
* License : MIT
Programming Lang: Python
Description : Library for
Package: wnpp
Severity: wishlist
Owner: Adrian Alves
* Package name: python-flask-marshmallow
Version : 0.6.2
Upstream Author : Steven Loria
* URL : https://github.com/marshmallow-code/flask-marshmallow
* License : MIT
Programming Lang: Python
Description
701 - 800 of 1531 matches
Mail list logo
