x27;t rely on a third-party service for this.
(In particular the service in question here doesn't do that as far as
I can tell.)
Ansgar
it so far, but at least "whalebuilder" exists.
The gitlab-ci used on salsa.d.o also uses Docker containers; people also
build packages using this (mostly for testing though, see for example [1]).
Ansgar
[1] https://salsa.debian.org/salsa-ci-team/pipeline
on't really care about
collision attacks after all.
We have most infrastructure already using SHA-2 and there are
preparations to support newer hashes as well; it is a regression to
introduce a new system bound to SHA1 for the foreseeable future (and
given Git's use of SHA1 their need to require a strong hash is far
less).
Ansgar
h the same way as tag2upload does, AFAICT.
That is true and I don't like it. I should probably add a sha2 hash
somewhere. (Note that we *can* just change it...)
> On Mon 15 Jul 2019 at 10:43PM +02, Ansgar Burchardt wrote:
> > It also has one downside: `git tag` alone won't be
Russ Allbery writes:
> Ansgar Burchardt writes:
>> The client tool could possibly also just create the .dsc and .changes,
>> except for hashes of the compressed files, and the web service just
>> recreate the tarball and compress them.
>
> I think experience with
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Russ Allbery writes:
>>> If so, I think that security model is roughly equivalent to the
>>> automatic signing of binary packages by buildds, so probably doesn't
>>> introduce a new vulnerability,
>
er would normally do.
We have other permissions checks as well; they shouldn't be
reimplemented in different places. Instead the archive (dak) should
know who signed the package.
Ansgar
uld probably not start raising a warning about it and one
should keep in mind that Policy might not reflect consensus when
referring to it.
Ansgar
Sean Whitton writes:
> On Fri 12 Jul 2019 at 02:06PM +02, Ansgar wrote:
>> Depends on a lot of things. As far as I understand this work is in a
>> very early stage and a first brainstorming session on what problem this
>> is intended to solve, why one should consider d
ould consider doing it, and possible
requirements is planned for DebConf[1].
Without having any of these, it is hard to comment on anything.
Ansgar
[1]
https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/
On Tue, 2019-06-25 at 16:39 +0800, Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend usin
. Also, parental
| monitoring and guidance can reduce likehood of teens breaking such
| systems. Maybe because teens are largest marketshare for TVs.
Ansgar
- rating "kill -KILL" X-rated for extreme violence
uot;bionic" instead of just writing the version in
sources.list is annoying (I always have to look up the codename to be
sure as I don't use Ubuntu that much).
Ansgar
such things down for Debian for the rare case
someone might read it; there are enough other things that need to be
done.
Ansgar
record indicate that all currently valid certificates
must come from the listed CAs; the CAA record could have been different
when those were issued.)
Ansgar
esterday. The move should be completed with this.
Ansgar
asons.
>
> Use the $300,000 on our bank accounts?
I heard that this didn't work out well the last time ("dunc tank"),
though that was before the time I followed Debian development.
Ansgar
mething Debian
would probably not like that much...)
Ansgar
Adam Borowski writes:
> On Mon, May 13, 2019 at 11:25:11AM +0200, Ansgar wrote:
>> It supports solid compression[1] which
>> compresses multiple files into one block like tar.xz, but unlike tar.xz
>> can use more than one block: "Later versions of 7-zip use a variable
&g
archive; though for 7z one would
need to check if it does the right thing first...
Ansgar
[1] https://en.wikipedia.org/wiki/Solid_compression
n just seek from
one header to the next and only need to do so few times).
Ansgar
Ian Jackson writes:
> Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
>> `ar` needs to be replaced for the file size limitation mentioned in the
>> initial mail: ar represents file size as a 10 digit decimal number[1]
>> which limits the me
atible change, it is an appropriate time to bundle any other
incompatible changes (if there are any). That is why I suggested that
it might be useful to also replace the `tar` archives with another
format.
Ansgar
ished is what is the actual preferred form of
modification (as it is what the maintainer uses), but if so desired one
can still get a "dgit view". (Though for contributing changes to the
maintainer, one should probably base them on the maintainer view...)
In this case the published history also matches the "git histories we
are actually using ourselves", a design goal not met currently; one
could also apply the mangling feature to repositories not published on
the dgit server.
Ansgar
Adam Borowski writes:
> On Wed, May 08, 2019 at 10:35:58PM +0200, Ansgar wrote:
>> Adam Borowski writes:
>> > I've recently did some research on how can we improve the speed of
>> > unpacking
>> > packages. There's a lot of other stages that can b
Jeremy Stanley writes:
> On 2019-05-08 22:35:58 +0200 (+0200), Ansgar wrote:
>> Switching to a different binary format will break various tools. If we
>> want to do this, I wonder if we shouldn't take the chance to move away
>> from tar?
>>
>> We have
the chance to move away
from tar?
We have various applications that only want to extract single members of
the package (changelog, NEWS, copyright, ...); tar is a really bad
format for such an operation. Other formats (zip, 7z, ...) are more
suited for them.
Ansgar
On Tue, 2019-05-07 at 12:51 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > Sam Hartman writes:
> > > OK, I didn't hear that as an answer but think I'm coming to the
Sam Hartman writes:
>>>>>> "Ansgar" == Ansgar writes:
>
> Ansgar> Sam Hartman writes:
> >> I'm having a bit of trouble here and am hoping you can help us
> >> out. Ian asked what git workflow it is that you're talki
aging information), and possibly other directories below base for
build artifacts (instead of unpredictable locations under base/debian).
Which leads back to the beginning of the subthread[1].
[1] https://lists.debian.org/debian-devel/2019/04/msg00462.html
Ansgar
On Fri, 2019-05-03 at 17:39 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream
> moves from tarballs to git"):
> > On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> > > Ansgar writes ("Re: Preferred git branch stru
On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream moves from
> tarballs to git"):
> > On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> > > Ansgar writes:
> > > > Having to
On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> Ansgar writes:
>
> > Having to know about branches, merging, dealing with multiple remotes,
> > ... *is* an entry barrier compared to not having to know about it. Now
> > you have to teach people that before you ev
On Thu, 2019-05-02 at 13:45 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
> > > As a package maintainer, if you don
On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
>
> On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote:
>
> > As an example: to update to a new upstream release, I ideally just have
> > to drop the new upstream tarball, update d/changelog and am done.
> > Compare
elease, I ideally just have
to drop the new upstream tarball, update d/changelog and am done.
Compare with [1] which is much more complicated, even ignoring the extra
complexity using dgit adds compared to just using git.
Ansgar
[1]
https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES
ot;verifying a git
> tag".
Doesn't Git also only use hash algorithms that are no longer recommended
for cryptographic applications? Or have they finished moving to
stronger algorithms?
I don't think we should downgrade to SHA-1 for new services.
Ansgar
kg-deb to
> convert the results to Debian packages?
How should this handle dependencies (probably named differently in
Debian) or maintainer scripts?
Tools like `alien` to convert RPM and Debian packages have similar
limitations and I don't remember them working that well.
Ansgar
Guillem Jover writes:
> On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote:
>> Guillem Jover writes:
>> > 3) Switching packages to the merged-/usr layout could have been
>> >accomplished automatically via debhelper for a coverage of around
>> >99% (?)
ng the packaging system even more, when the
>compat symlinks could have been shipped in the binary packages.
As far as I know maintainer scripts are only required for moving files
from / to /usr when (a) a compat symlink is required, and (b) only when
both merged-/usr and non-merged-/usr is supported.
Ansgar
d environments is in contrast a fairly
friendly failure mode. So it should not be a serious bug (whether RC or
not is something for the release team).
> For the purposes of this e-mail, let's assume that we have a good grasp
> on what a "reasonable standard development workstation install" means.
I doubt we have, but let's ignore that.
Ansgar
the keys.
IMHO installing a non-Debian keyring should *not* make the keys trusted
by APT by default (i.e. with the default answer if debconf is used).
ubuntu-keyring does that; most other keyrings sadly do not follow this.
Ansgar
e from jessie-security; arm64 wasn't
removed from -backports as there is no LTS for backports and jessie-
backports will eventually be archived as is.)
Ansgar
[1] https://www.debian.org/News/2018/20180623
dian in C.UTF-8:
WEEKDAY MMM DD HH:MM:SS TZ
while en_US.UTF-8 has at least DD MMM ... Having
-MM-DD HH:MM:SS[+]
instead would be much nicer if we were to create an arbitrary set of new
rules for a new universal "en" locale ;-) )
Ansgar
,
> which defeats my understanding of the purpose of this proposal. So, for
> example, in ls -l:
I don't think the "C.UTF-8" locale covered by any promises POSIX might
make for "C". (Nor is what happens when no LC_*, LANG vairables are
set at all.)
Ansgar
for example.
No, that already stops working when package are named differently which
is frequently the case. There is no readline-devel package in Debian
and no libreadline-dev in Red Had or Gentoo.
Also what you suggest already exists, for example in the form of
"pacapt" (but there are alternatives too!). What is the benefit of
adding yet another version of these scripts?
Ansgar
@INC by default. It also wasn't seen as
a security problem when I reported it as such (or not worth fixing at
the time), but only years later when someone else reported it again. So
maybe awareness changed a bit.
But "<>" isn't the only problem, there are way too many uses of the
two-argument form of Perl's "open" too...
Ansgar
one of (/run /dev/shm /tmp)
What will happen on systems where users changed the configuration files
and these changes are not applied automatically?
Ansgar
t and is thus not needed.
No, the alternatives system is not really useful for users (as only root
can choose an alternative). Having root choose a single
{editor,pager,browser,...} for all users is not a good solution.
Ansgar
weren't
stripped and from discussion I'm not sure it is clear why, but we agree
that this shouldn't block the current version and should better be
discussed in a bug report.
Ansgar
where this matters; don't ask me about details, I don't know much).
Ansgar
Lorenz writes:
> Ansgar Burchardt:
>>As a possible alternative: ship the runscript and some metadata (which
>>systemd service(s) and/or sysvinit script(s) this corresponds with;
>>which system users would be needed; ...) either in the service package
>>(preferred
; ...) either in the service package
(preferred long-term) or a "runscripts" package (maybe easier for
initial experiments).
Then have runit provide a command that creates the system users, sets up
the runit service and disables the systemd service (which I think was
still missing from the *-run packages).
Ansgar
if a system has merged-/usr
or not. Newly installed systems will have merged-/usr, but no usrmerge
(as debootstrap creates the symlinks), or usrmerge could be removed
after the system has been converted (I did that for my systems).
Ansgar
upporting non-merged-/usr systems since these
> > problems are caused by having to support both, and there is no real
> > benefit in doing that other than pleasing the few people who are scared
> > by changes.
What is this quote supposed to tell us?
Ansgar
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Moving files around in such a matter that they are still available in
>> the old location (via a symlink) is not a very invasive change, so there
>> is only a small risk of problems.
>
> I think it's fair to
B init headers to local init scripts (or just replace them with
systemd units these days), having to purge leftover conffiles from
removed packages or similar changes on upgrades.
If the system is prone to breakage on upgrades in general, I would
expect anyone sensible to fix that.
Ansgar
ys get something with a valid signature
and a code execution bug running...
Ansgar
ree? Signing stuff does not change the freeness of
> > the
> > software.
>
> it does introduce https://en.wikipedia.org/wiki/Tivoisation however.
I don't think it does as `shim` allows to either register your own
signing keys or disable secure boot verification (as long as you have
physical access to the machine).
Ansgar
ve
developers(!) back in 2015 according to a presentation by Devuan
developer Alberto Zuin and Devuan founder Jaromil, and which represents
an exodus for half of the active Debian user base (according to a Devuan
lead developer in a publication in 2018)? They certainly should have
enough resources.
Ansgar
allations of runit
> - 141 installations of openrc, installations of openrc, but it works
> on
> top of sysvinit
> - http://popcon.devuan.org/tmp-www/by_inst.html
>
> So Devuan almost doubles the percentage of sysvinit-
> core installations.
And Ubuntu probably reduces it again by more than that.
Statistics are fun :-)
Ansgar
uded in the binaries and could be
extracted even for proprietary software).
Ansgar
make you go away? That sounds like a
positive effect to me, but for some reason you seem to try and use it as
a threat?
Ansgar
(SCNR)
cases where the init script starts multiple services,
but there are individual units for each service in systemd is
forbidden.
I think this requirement isn't a good idea these days for various
reasons and will file a bug asking to drop it.
Ansgar
On Tue, 2018-10-16 at 09:57 +0200, Martin Steigerwald wrote:
> Ansgar Burchardt - 16.10.18, 08:53:
> > If some people consistently call others a "cancer", accuse them of
> > "vandalizing" open source, spread obvious FUD and so on, then I don't
> > th
Martin Steigerwald writes:
> Ansgar Burchardt - 15.10.18, 16:03:
>> Please no. I don't think it would help Debian to have toxic people
>> maintain packages.
>>
>> (As an example, Devuan's infobot has fun facts like this one:
>> "<+infobot>
means it acts invasive, possessive,
destructive, and generally in an egocentric exacerbating negative way.
``this cancer is extremely poettering'' [...]")
Ansgar
y on those other systems; or you can use
> Recommends: rather than Depends: if you don't want it to be absolute.
Depending on an init system is definitely wrong as it is perfectly fine
to use some service without any init, such as in Docker containers, or
under other supervisors such as runit.
Ansgar
arizing the issue. I'm afraid I must bow out, focus on
> fixing the problem, and leave it to others or to self-study for you to
> understand it, if you wish to.
I can't help but understand your message as "if you don't agree, you
haven't understood" which I don't find very helpful.
Is that what you wanted to say?
Ansgar
think a discussion on -devel@ will reach a
consensus that would take away the responsibility here.
Ansgar
[1]
https://www.debian.org/doc/debian-policy/#packages-with-potentially-offensive-content
tion my favorite
chown -R non-root /var/lib/service
in maintainer scripts...)
Ansgar
Dmitry Smirnov writes:
> On Tuesday, 5 June 2018 5:11:31 PM AEST Ansgar Burchardt wrote:
>> rkt is neither in testing nor stable...
>
> Unfortunately... However it is a static Golang binary with minimum external
> run-time dependencies which makes it possible to reasonably saf
t in
Debian)? *scnr*
Ansgar
> #!/usr/bin/dh-exec
> spm.sh => /usr/bin/spm
/usr/bin/spm is already shipped by another package as noted in the
initial report.
Renaming the binary to simple-password-manager or so would probably
work.
Ansgar
but if it's thought easier to maintain then fine...
That seems like an horrible maintenance nightmare just to avoid even
talking to upstream...
Ansgar
dishwashers, computers, and so on though. :-)
Sorry, could not resist.
Ansgar
tps:// for accessing Git repository; that also works without an
account (for public projects).
Ansgar
quot;Maintainer:" and
> "Uploaders:", what's the point in both fields existing?
The Maintainer field is only allowed to list one person for historic
reasons. So a new field was added to list additional maintainers.
Ansgar
g the removal of a package with open RC
bugs that hasn't been uploaded for a time, isn't just salvaging the
package by adding oneself as a maintainer better?
And if this is the preferred outcome, shouldn't the salvaging be
"easier" than just requesting removal (which is just one bug report
away)?
Ansgar
irements...
I plan to file RC bugs against these packages soon; this thread can
serve as a central place for discussions.
Ansgar
s are not closed by dak and end up getting
closed in a different way.
Ansgar
[1] IIRC when removing >1 source package at the same time
Andrej Shadura writes:
> On 01/02/18 09:40, Ansgar Burchardt wrote:
>> Andrej Shadura writes:
>>> On 31/01/18 21:01, Jeremy Bicha wrote:
>>>>> Here you go, there's #871004 for you. Missed jessie, stretch,
>>>>> not in testing, no uploads since
ird RC bug (the "proposed-RM") and waiting one
month more change anything? Why would someone turn up to fix them now?
Ansgar
Simon McVittie writes:
> On Sun, 07 Jan 2018 at 00:27:15 +0100, Ansgar Burchardt wrote:
>> sysvinit probably only stays in testing because systemd
>> depends on sysv-rc for compatability with LSB init scripts...
>
> I think it did during the default init system transition,
example insserv (#834284) and startpar (#834283). Or
systemd-shim if you want to consider desktop systems too.
Ansgar
tremely poettering'', [...]
I don't think we should waste time to accomodate the needs of such
people.
Ansgar
that can possibly fail.
Anything with failing maintainer scripts is very much not nice,
especially for unexperienced users.
(One the reasons I don't like packages trying to be smart and configure
things, then break in the maintainer script. Dumb packages are more
friendly.)
Ansgar
27;t interesting for users of the
package.
I also don't think we should default to an ancient C++ standard. All
maintained software should hopefully work with C++11 or later by now...
Ansgar
nctions and add compiler-specific
definitions to them isn't that easy. The real easy and lazy option
would be to have a compiler flag to enable it for entire translation
units (probably at the expense of binary size).
Ansgar
g` could also run maintainer scripts in a more controlled
environment so less random variables affect the maintainer scripts.
Ansgar
esn't handle that quite correct yet (it explicitly makes
uploads world-readable which shouldn't happen for security uploads).
Ansgar
on3-googleapi,
usbmuxd, python3-pyicloud, python-yowsup, youtube-dl,
libgfbgraph-0.2-dev, other proprietary web APIs, drivers for SATA disks
("server" runs on SDD/HDD), ...
Ansgar
end mails
about individual packages.
For legacy purposes, the Maintainer field would then list ${source}@tra
cker.d.o and the Uploaders field could be removed.
This would also address the fact that various bits of our
infrastructure don't know about Uploaders (like bugs.d.o only
contacting the Maintainer).
Ansgar
es -S, or whether dak is fixed to allow
> multiple buildinfo files for the same arch (maybe renaming the file itself);
Or fixed to just silently discard .buildinfo files that might not work.
Or reject them always (though that also causes issues because arch:all
uploads also seem to get a _amd64.buildinfo, except when they come from
the buildds).
Ansgar
e it easier to check commit
signatures using the Debian keyrings if one so desires).
Ansgar
aking SMTP to a remote SMTP server is
common enough that these shouldn't Recommend a MTA usually either).
Ansgar
but I had no need for it
myself so far and therefore don't know much about it.
Ansgar
i.ftp-master.d.o. For example some
information about suites:
curl https://api.ftp-master.debian.org/suites
If people need more information avialable, we can add more bits.
Some documentation is available on
https://ftp-master.debian.org/epydoc/dakweb.queries-module.html
Ansgar
quot; section:
> rustc, cargo, libstd-rust*, and rust-*. And all packages named
> node-*, libjs-*, and javascript-* should move to the "javascript"
> section.
I've done this now.
Ansgar
;t the .dsc
itself be need to be signed by a stronger hash? I would expect there
are still a lot more .dsc with "Hash: SHA1" in the archive.
Ansgar
201 - 300 of 544 matches
Mail list logo
