it looks like I'm going to have to switch to apt.)
It's probably a good idea to move away from dpkg-ftp as it doesn't seem
to support signed Release files from a cursory look at the old package
from snapshot.debian.org.
Ansgar
- who again wonders how much fun one could have
Shouldn't -O0 come close to that expectation?
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5347c8b4.7040...@debian.org
robably need to replace systemd-sysv with systemd-shim (to satisfy
the dependency libpam-systemd) and install the package shipping
/sbin/init instead (whatever it is called).
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscrib
Package: wnpp
Severity: wishlist
Owner: Ansgar Burchardt
* Package name: psurface
Version : 2.0.0
Upstream Author : Oliver Sander
* URL : http://numerik.mi.fu-berlin.de/dune/psurface
* License : LGPL-3+ or GPL-2 with runtime exception
Programming Lang: C
of using
triggers? That way completions would also be available for software
installed into /usr/local (not using dpkg) without having to run some
command.
Regards,
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? C
Package: wnpp
Severity: wishlist
Owner: Ansgar Burchardt
* Package name: libmoosex-chainedaccessors-perl
Version : 0.02
Upstream Author : Moritz Onken
* URL : http://search.cpan.org/dist/MooseX-ChainedAccessors/
* License : Artistic or GPL-1+ (like Perl
he newer version to "rolling" for all
architectures except s390. This way all users not using s390 could
already upgrade to the new version.
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/s2saaf2tqba@bistromathics.mathi.uni-heidelberg.de
aining
problems is always welcome [3].
See also [2] for the pkg-perl instance of PET2.
If you want, I can setup a PET2 instance for pkg-haskell.
Regards,
Ansgar
[1] <http://lists.debian.org/debian-devel-games/2011/05/msg00117.html>
[2] <http://pet.43-1.org/pkg-perl/pet
gt; good work... I just got a very quick fix of d-i.alioth.d.o by Stephen
> and it's always appreciated to have such responsiveness).
There is a list at http://titanpad.com/yyhfwA9Pyr
Regards,
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of &q
es it, I'll be happy. Until then, protests without action
> will make absolutely no difference.
The "interested party" might also not know how packages are maintained
in Debian. And I don't think it is helpful to "threaten" upstream with
removal of his softwa
per to maintain
packages in Debian).
Regards,
Ansgar
[1] <http://bugs.debian.org/602694>
[2] <http://bugs.debian.org/579791>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tybu3ifu@marvin.43-1.org
Package: wnpp
Severity: wishlist
Owner: Ansgar Burchardt
* Package name: python-pyramid-beaker
Version : 0.5
Upstream Author : Agendaless Consulting and Contributors
* URL : https://github.com/Pylons/pyramid_beaker
* License : BSD-like
Programming Lang
lag
to
ExecStart=/usr/bin/some-daemon --some-other-flag
or a built-in default in some-daemon changing with the same effect.
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
; that existing installations should retain their init system
> – which goes along with “upgrades should not change the sy‐
> sytem state” generall – as much as possible.
No, the ctte did not say that. We had a flamewar about that
interpretation before.
Ansgar
--
To UNSU
On 11/28/2014 03:24 PM, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Ansgar Burchardt wrote:
>> No, the ctte did not say that. We had a flamewar about that
>> interpretation before.
>
> That was almost word by word from
> https://lists.debian.org/debian-devel-announce/20
Nov 18 13:15 runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 16 Nov 18 13:15 runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root 13 Nov 18 13:15 runlevel6.target -> reboot.target
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a sub
ed of processors,
and system architecture are probably more helpful than just the kernel
version the system is running.
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ere are no useless processes around either
If the service is not installed (a good default?), just use a static motd.
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c1259e.7040...@43-1.org
were not in backports before).
However unstable and experimental share overrides, that is uploads to
experimental do not have to pass NEW when the package is already in
unstable (and the other way around).
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a su
; demote to "optional"
- w3m:
I think text-mode browsers are not worth including in the default
install. It is *very* rare to not have another computer to use.
Plus in the worst case the package is still just an apt-get away.
-> demote to "optional"
- whois:
Too special to include in standard install.
-> demote to "optional"
Any comments and/or suggestion for other changes?
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3qurhhm@deep-thought.43-1.org
I'd wager most use of w3m is for local-only web resources on servers.
But is this enough reason to keep w3m at priority standard? Personally I
would rather use "ssh -D" or such than bothering with a rather limited
text-mode browser.
Ansgar
--
To UNSUBSCRIBE, email to debian
On 05/06/2015 11:34 AM, Martin Zobel-Helas wrote:
> On Tue May 05, 2015 at 20:45:09 +0200, Ansgar Burchardt wrote:
>> * Packages currently at "important":
>> - cron:
>> Not needed in chroot/container environments.
>> -> demote to "stan
Package: wnpp
Severity: wishlist
Owner: Ansgar Burchardt
* Package name: python-pyramid-chameleon
Version : 0.3
Upstream Author : Pylons Project and Contributors,
http://www.pylonsproject.org/
* URL :
http://docs.pylonsproject.org/projects/pyramid
r to normalize the .changes name for all uploads) or change the
filename the buildds use to make clashes with maintainer uploads less
likely.
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.
nore invalid signatures for
repositories, cf. https://bugs.debian.org/787174. It is a really unsafe
option that should probably not be used in any automated way, though I
have seen people do so in several places.
Regards,
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wi
7;m thinking of dune-* / libdune-*-dev here,
but the same probably applies to other packages like deal.ii as well.
Does anyone see any problems with this plan?
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
Hi,
On 07/09/2015 06:39 PM, Bas Wijnen wrote:
> On Thu, Jul 09, 2015 at 05:26:32PM +0200, Ansgar Burchardt wrote:
>> I'm wondering about the shared library packaging requirements in Policy
>> for the special case of scientific libraries that are not intended to be
>> use
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
ys get something with a valid signature
and a code execution bug running...
Ansgar
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
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
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
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
; ...) 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
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
where this matters; don't ask me about details, I don't know much).
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
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
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
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
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
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
such things down for Debian for the rare case
someone might read it; there are enough other things that need to be
done.
Ansgar
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/
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
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
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,
>
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
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
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
elf to your preferred value. For example:
export SHELL=/home/user/.bin/the-best-shell-of-all
(The details might vary depending on the shell you are currently in.)
usrmerge does not affect this at all.
Ansgar
d would raise an objection of my
> own.
/sbin not in PATH by default makes many more veteran users unhappy.
Especially as even su (not `su -`) no longer does that (an incompatible
change in one of the last Debian releases).
Ansgar
ieve the hardware token to have a backdoor, exploiting it
might still require physical access to the token.
Ansgar
``
(The PIN can still be cached.)
For OpenSSH it might also be more convenient to use Webauthn, that is,
the keys generated using `ssh-keygen -t ed25519-sk` or `-t ecdsa-sk`.
Ansgar
>
ulib is just older and targeted at the C ecosystem which still has
worse tooling that pretty much everything else.
Ansgar
continuing to
support i386 has likely costs much higher than the replacement cost of
said hardware... Which is probably why nobody really seems sufficiently
motivated to actually invest resources. (Or do you?)
Ansgar
should leave the
decision whether/how to log to the admin.
However there are false positives: for example xinetd already dropped
the recommendation some time ago (Oct 2023)[1]. Maybe you used
information from stable to generate the list?
Ansgar
[1]:
https://tracker.debian.org/news/1474312/accepted-xinetd-123154-1-source-into-unstable/
in command
+---
I suggest to implement a new utility named
`/usr/bin/posix-which2` utility if you do not want that ;-)
(Only after proper standardization of course.)
Ansgar
had
It is sufficient to ensure there is only one provider of the "default"
package. This is currently done for the default MTA: packages needing a
MTA depend on "default-mta | mail-transport-agent". The only provider
(in Debian) of default-mta is exim4-daemon-light, so exim4 is selected
by default if no other MTA is installed.
Ansgar
ted to
> continue maintaining sysvinit scripts?
Well, the quoted decision doesn't suggest active maintenance. Just
ignore it, but don't remove it (random additional configuration(!)
files shouldn't be too bad). So keep them, ignore them and in 10 years
we will eventually remove them ;)
Ansgar
IW, there is now a request for the technical committee related to
this thread, see https://bugs.debian.org/835507
Ansgar
ease cycle).
Please remember that this still allows / and /usr to reside on different
filesystems: in this case the initramfs has to make sure /usr is mounted
as well. This is already required for various reasons (again, see [1]).
Ansgar
[1] https://lists.debian.org/debian-devel/2016/01/msg00
Ansgar Burchardt wrote:
> debootstrap in unstable can now install with merged-/usr, that is
> with
> /bin, /sbin, /lib* being symlinks to their counterpart in /usr. Run
>
> debootstrap --merged-usr testing .../testing http://deb.debian.org/
> debian
>
> to give it a t
On Tue, 2016-09-27 at 15:42 +0500, Andrey Rahmatullin wrote:
> On Tue, Sep 13, 2016 at 10:36:58PM +0200, Ansgar Burchardt wrote:
> >
> > debootstrap in unstable can now install with merged-/usr, that is
> > with
> > /bin, /sbin, /lib* being symlinks to their co
, see
the first paragraph in [1].
[1] <https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries>
Ansgar
tes should
also be available via https:// now.
Ansgar
uded in generated files to ensure
they are identical on all architectures (or at least to try to do so).
If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
probably be set to the date of the last sourceful upload (instead of
just using the most recent changelog entry).
Ansgar
itish git branch) ?
The source for the sbuild variant used on the buildds lives in a branch
of the sbuild repository (`buildd-0.65` for the current version I
think).
Ansgar
using a configuration management system in general.
Maybe we should look at [1] for some ideas here.
Ansgar
[1] http://0pointer.net/blog/projects/stateless.html
users:(("gpg-agent",pid=20584,fd=5),("systemd",pid=1911,fd=22))
+---
(which reminds me of `ip` vs. `ifconfig` on interfaces with multiple
IPv4 addresses. `ifconfig` will show only one of them...)
Ansgar
vice manager.
>
> In fact I didn't have libpam-systemd installed for some strange
> reason, but installing it hasn't helped. (All the symptoms I report
> above are with it installed.)
How did you not have libpam-systemd installed? network-manager has
Depends: policykit-1 and policykit-1 has Depends: libpam-systemd.
Ansgar
aybe?
With elogind do you mean https://github.com/wingo/elogind? That
project doesn't look very active.
Is there any active project trying to reimplement the logind API?
Including access to devices (which X wants these days)?
Ansgar
On Fri, 2017-01-06 at 07:48 +0100, Adam Borowski wrote:
> On Thu, Jan 05, 2017 at 12:19:08PM +0100, Ansgar Burchardt wrote:
> > With elogind do you mean https://github.com/wingo/elogind? That
> > project doesn't look very active.
> >
> > Is there any active p
;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
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
tremely poettering'', [...]
I don't think we should waste time to accomodate the needs of such
people.
Ansgar
example insserv (#834284) and startpar (#834283). Or
systemd-shim if you want to consider desktop systems too.
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,
ird RC bug (the "proposed-RM") and waiting one
month more change anything? Why would someone turn up to fix them now?
Ansgar
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
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
irements...
I plan to file RC bugs against these packages soon; this thread can
serve as a central place for discussions.
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
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
tps:// for accessing Git repository; that also works without an
account (for public projects).
Ansgar
dishwashers, computers, and so on though. :-)
Sorry, could not resist.
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
> #!/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
t in
Debian)? *scnr*
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
tion my favorite
chown -R non-root /var/lib/service
in maintainer scripts...)
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
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
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
means it acts invasive, possessive,
destructive, and generally in an egocentric exacerbating negative way.
``this cancer is extremely poettering'' [...]")
Ansgar
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>
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
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
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)
uded in the binaries and could be
extracted even for proprietary software).
Ansgar
401 - 500 of 562 matches
Mail list logo
