On Tue, Apr 09, 2024 at 06:37:23PM +, Holger Levsen wrote:
> - I very much dislike git-buildpackage, too much magic. I try to avoid it
> where I can.
We still like those VCS-in-VCS workflows over everything else. Those
debian/patches, where you need to call something special and can't just
On Mon, Apr 01, 2024 at 06:36:30PM +0200, Vincent Bernat wrote:
> On 2024-04-01 12:44, Bastian Blank wrote:
> > So in the end you still need to manually review all the stuff that the
> > tarball contains extra to the git. And for that I don't see that it
> > actually giv
Hi
On Mon, Apr 01, 2024 at 12:40:51PM +0200, Ansgar wrote:
> 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`.
Also those key types allow two different uses. Persistent or
non-persistent keys differ
On Mon, Apr 01, 2024 at 12:03:48PM +0200, Bastian Blank wrote:
> On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote:
> > That's not mutually exclusive. When adding an additional git remote
> > and using gbp-import-orig's --upstream-vcs-tag you get the best of
On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote:
> That's not mutually exclusive. When adding an additional git remote
> and using gbp-import-orig's --upstream-vcs-tag you get the best of
> both worlds.
And this will error out if there are unexpected changes in the tarball?
How
Hi
On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > What we can do unilaterally is to disallow vendoring those files.
> These files are supposed to be vendored in release tarballs,
> the sane approach for getting rid of such vendored files would
> be to discourage tarball uploads
On Sun, Mar 31, 2024 at 11:59:35AM +0100, Colin Watson wrote:
> > What we can do unilaterally is to disallow vendoring those files.
> > Does it help? At least in the case of autoconf it removes one common
> > source of hard to read files.
> That's doable unilaterally to some extent, using the
On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote:
> On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > I have seen discussion about shifting away from the whole auto(re)conf
> > tooling to CMake or Meson with there being a reasonable drawback to CMake.
> > Is that something
On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
> > As others have said, the best solution is to relay on HSW for handling
> > the cryptographic material.
> Aren't these answers to different questions?
>
On Sat, Mar 30, 2024 at 07:15:28PM -0700, Otto Kekäläinen wrote:
> I am doing all my builds inside a (Podman) container with the sources
> loop-mounted.
You do, but Debian itself (aka DSA) does not. They still prefer to
trust all 100k packages and run them as root in the init namespace over
the
On Sat, Mar 30, 2024 at 01:30:07PM +0100, Jan-Benedict Glaw wrote:
> On Sat, 2024-03-30 08:02:04 +0100, Gioele Barabucci wrote:
> > On 30/03/24 01:21, Antonio Russo wrote:
> > > 3. Have tooling that automatically checks the sanitized sources against
> > > the development RCSs.
> >
On Wed, Jan 24, 2024 at 11:40:20PM +, Wookey wrote:
> If it only done for security issues, rather than routinely, then that
> shouldn't be that much extra load (does anyone have any idea how much
> extra building we are talking about? Is it trivial, or huge?)
If we do those rebuilds in stable
On Tue, Jan 16, 2024 at 10:59:30AM +0100, Simon Josefsson wrote:
> Rebuilding a bit more than what is strictly needed sounds fine as a
> first solution to me.
Building maybe. But how do you want to publish them? The security
archive is not made to handle that.
> My naive approach on how to fix
On Tue, Jan 16, 2024 at 11:22:48AM +0100, Jérémy Lal wrote:
> I naively believed that golang-* packages expressed those dependencies with
> "Built-Using".
As Built-Using is for license compliance only, no?
See
On Sun, Jan 14, 2024 at 04:24:57PM +0100, Simon Josefsson wrote:
> Isn't that what the text refers to? Vendoring and static linking are
> two examples of the same problem that the security team may encounter.
We accept vendoring of autoconf/automake/gnulib distro wide. Please
show practical
On Fri, Dec 29, 2023 at 11:30:14AM +0100, Simon Josefsson wrote:
> * Package name: ssh3
This package name is clearly not acceptable. SSH is a well known name
and this project is completely unrelated to it.
So this is an accademic project. I would question that it actually
solves the same
Hi Simon
On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote:
> As an analogy, consider the ./configure scripts that is generated by
> autoconf during build of many packages. The script typically generate
> code that is put into config.h that is used (statically) during
> compilation
On Thu, Jan 11, 2024 at 10:50:31AM +0100, John Paul Adrian Glaubitz wrote:
> > As it is now, we will not be able to provide a kernel for maybe all
> > 32bit architectures for Trixie.
> I don't think that this would be a reasonable decision. We're preparing to
> switch
> 32-bit architectures over
Hi
On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.
Okay, maybe more workarounds exist. But none of them look really
promising.
>
Hi
Linux 6.7 fails to build on at least i386 and armhf. Even it now
manages to make the compiler fail to allocate memory:
| cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes
Right now both fail on the same driver, so a short team workaround would
be to disable it.
On Fri, Dec 01, 2023 at 12:20:16AM +, Dimitri John Ledkov wrote:
> And many of them cannot be verified using debian-keyring:
> 2,455 no public key
> 3 wrong key usage
And how many can be verified? Do any show broken signatures?
> Should we stop requiring signed .dsc on uploads?
We had
On Thu, Nov 30, 2023 at 08:24:18PM +0100, Thomas Braun wrote:
> Now I would like to know if being able to run in an IPv6-only environment is
> a must have feature for any debian package?
As Debian uses package builders in this configuration, packages needs to
build in such an environment.
On Sat, Nov 25, 2023 at 10:30:39AM +0100, Bastian Blank wrote:
> Thank you for purposefully not mentioning that this only applies if you
> use the bothed(?) gcc spec override to build with musl instead of glibc.
> Can you show it is broken if using the standard toolchain
Hi Thorsten
On Fri, Nov 24, 2023 at 06:58:40PM +, Thorsten Glaser wrote:
> Matthias Klose dixit:
> >, this is not an RC issue. Please stop playing
> > bug ping pong.
>
> If GCC stops supporting an option it used to support,
> and where the GCC documentation say it’s supported,
> it in my
On Fri, Jul 07, 2023 at 06:07:58PM -0600, Sam Hartman wrote:
> >>>>> "Bastian" == Bastian Blank writes:
> Bastian> Why do we need to have the priority adjusted instead of fix
> Bastian> d-i to install what it knows the user needs?
> Because it's
On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón wrote:
> For the moment, ifupdown is still installed by the debian-installer as
> default network interfaces manager. And after sleeping over it, and
> discussing with debian fellows, I would like to call for consensus to
> rise
On Wed, Jun 28, 2023 at 10:01:13AM +0200, Thomas Goirand wrote:
> It's not. As written by Russ in this thread, filling a bug against
> orphan-sysvinit-scripts so it takes over the abandoned script is. I wouldn't
> mind seeing this mandatory, and written in the policy.
I do. This also does not
On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:
> > Less prone to errors than a manual process might be to watch
> > automatically where legacy startup scripts disappear anyway; it's not
> > that complicated to do. People tend to forget things.
>
> That sounds reasonable. It
On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote:
> To avoid breakage of existing systems and facilitate ongoing support for
> non-systemd inits, I would like to establish a consensus for
> - stating that initscripts remain useful.
> - requiring a coordinated transition of any
On Thu, Jun 22, 2023 at 08:51:01PM +0200, Philipp Kern wrote:
> TBH time is too short to manually provision IP addresses on servers.
And DHCP is gladly enough entirely optional since SLAAC exists. But
for that you need systemd-networkd/systemd-resolved or a whole bunch of
other software.
On Fri, Jun 09, 2023 at 12:25:21PM +0800, Paul Wise wrote:
> Has anyone checked what percentage of these binaries will still run
> adequately after 2038 with 32-bit time_t?
All, because you don't need to provide those programs with a correct
time. But this is all a positive decisions.
>
On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> > modern x86_64 systems
> > 2a. legacy native Linux i386 binaries
> > 2b. legacy Windows i386
On Sun, May 28, 2023 at 08:27:16PM +0200, Ansgar wrote:
> I think this entry from the changelog is meant:
>
> +---
> | 2020-02-15 Florian Weimer
> |
> | COMMIT: 3a0ecccb599a6b1ad4b149dc569c0080e92d057b
> | ld.so: Do not export free/calloc/malloc/realloc functions [BZ
> #25486]
Hi Steve
On Mon, May 15, 2023 at 02:01:15AM +0100, Steve McIntyre wrote:
> Russ has described copying *binaries* out of packages and running them
> elsewhere. I've done that too, from time to time. This is one of the
> things made possible by the ABI contract being followed.
And nothing in that
On Sun, Jan 15, 2023 at 02:35:06AM +0100, Ángel wrote:
> I would change that to:
Please don't. If we change the distribution default for
net.ipv4.ping_group_range, then ping should refrain from ever trying to
check for it and never make the executable privileged.
Bastian
--
There is a
On Thu, Jan 05, 2023 at 12:26:09PM +0100, Paul Gevers wrote:
> Once accepted,
> the proposed workflow should also become documented in Debian policy.
As this is no technical policy, this belongs into the developers
reference.
However,
On Sat, Dec 24, 2022 at 11:44:49AM +0200, Jonathan Carter wrote:
> Will the archive team be moving those over? Is it up to firmware packagers
> to re-upload it to the correct component?
AFAIK this requires a re-upload. However, does the installer properly
include it yet? I need to check that.
On Tue, Oct 18, 2022 at 11:20:10AM +0200, Joerg Jaspert wrote:
> Am 2022-10-18 04:52, schrieb Paul Wise:
> > > Salsa should be there for git (related) things.
> > > NOT as an identity/login provider for Debian
Please formally retract the agreement that was forged two years ago
then. I properly
On Sun, Oct 16, 2022 at 07:22:28PM +0200, Enrico Zini wrote:
> I'm posting this to debian-devel as an early heads-up and a call for
> other maintainers. If nobody steps in my the end of October, I'll post a
> proper sunset announce to debian-devel-announce.
Everyone coming up with solutions,
On Sun, Oct 09, 2022 at 09:41:29AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> This breaks a number of setups like:
>
> - the sbuild autopkgtest
>https://salsa.debian.org/debian/sbuild/-/jobs/3353627/raw
> - the dropbear autopkgtest
>
>
On Tue, Sep 20, 2022 at 08:36:48AM +0800, Paul Wise wrote:
> On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote:
> > Hi, what I usually do with GitHub is to use its API, since it has the
> > advantage of not breaking uscan when they do changes to the web UI.
> Since the API uses pagination,
Hi Yasir
On Thu, Aug 11, 2022 at 03:14:03PM +, Yasir Ashfaq1 wrote:
> Could you please let us know why there is a discrepancy in version of zlib1g
> and zlib1g-dev package or whether there is a possibility that you have missed
> adding updates for s390x.
Debian Buster was moved to LTS
Moin
On Tue, May 10, 2022 at 02:30:04PM -0600, Sam Hartman wrote:
> Build Dependencies
> ==
>
> As a consequence of options 2-4, non-free-firmware would typically need
> to be enabled whenever non-free is enabled.
I don't understand why this is the case? Option 2 just needs
Moin
On Tue, Apr 26, 2022 at 04:14:02PM +0200, Marc Haber wrote:
> On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre
> wrote:
> >We don't have good docs around this in general (hey, it's security
> >software - it's against the law to write good and complete docs!), but
> >I've certainly
On Tue, Apr 19, 2022 at 12:17:06PM +, Jeremy Stanley wrote:
> It's probably what you meant, but just to be clear, as a user I'd
> also want to know which of the firmware packages used/installed were
> pulled from non-free and what devices prompted their addition.
> Something like "The
Hi Sam
On Tue, Apr 19, 2022 at 02:05:20PM -0600, Sam Hartman wrote:
> Marc> Would that not be possible by having an image WITH firmware
> Marc> and an installer asking whether the user wants a free or a
> Marc> usable system?
> For example I would thinki it would be entirely
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> SIMDe (or similar approaches) could be used to build variant(s) of the
> library that have compile-time emulation of SIMD instructions in the
> lower baseline builds of vectorscan.
But why? Who in their right mind would ever try to
On Wed, Mar 09, 2022 at 01:08:59PM +0100, Lucas Nussbaum wrote:
> can we find a middleground where the git workflows don't require staying
> with 1.0? Even if that means switching to 3.0 (quilt) using the
> single-debian-patch approach?
Well. There is a specific source format now for full git
On Sun, Mar 13, 2022 at 11:06:46AM +0100, Marc Haber wrote:
> The anti-systemd faction in Debian is cordially invited to step in,
> bring cron and cronie up to shape, before asking the rest of the
> Distribution to stick with essential system software that has been
> unmaintained for years.
And
Hi
On Fri, Mar 04, 2022 at 03:15:59PM +0100, Baptiste Beauplat wrote:
> Am I mistaken in thinking that's only a case of simply rejecting
> unsigned DKIM email?
This might be, but…
> Return-Path:
> Received: from mentors.debian.net (localhost [127.0.0.1])
> by
On Fri, Mar 04, 2022 at 12:38:02PM +0100, Baptiste Beauplat wrote:
> We recently discovered that Gmail started to bounce email from
> mentors.debian.net with the following message:
Can you please share the complete headers of the bounced message? Aka
the thing in the message/rfc822 part of the
Hi
On Fri, Feb 25, 2022 at 09:50:18AM +0100, Jonas Smedegaard wrote:
> I would certainly be frustrated if someone fast-tracked an NMU with
> structural changes like switching to short-form dh, with the reasoning
> that "the packaged had a smell to it", for a package that I maintain.
Well, do
Hi Julien
On Wed, Jan 26, 2022 at 07:58:23PM +0100, Julien Cristau wrote:
> I think we (DSA) have been reluctant to add new third-party-run services
> under debian.org,
Just being curious: what is your definition of "third-party-run"? As
example: deb.debian.org. It uses Fastly, which is shared
Hi Marc
On Wed, Jan 26, 2022 at 07:25:18AM +0100, Marc Haber wrote:
> Are the IP ranges of the Cloud Providers registered that badly that
> deb.debian.org wouldn't reliably point to the mirrors inside the
> provider's infrastructure? Or are the cloud providers' mirrors
> differnet from what we
On Thu, Dec 30, 2021 at 09:19:35PM +0100, Marco d'Itri wrote:
> systemd-resolved is supposed to forward queries to the upstream resolver
> and always be available on 127.0.0.53, so what does actually change in
> resolve.conf when using it?
Only if you are using the stub resolver.
On Thu, Dec 30, 2021 at 08:26:07AM -0500, Scott Kitterman wrote:
> > Maybe you should stop supporting the non-standard chroot configuration?
> What do you mean by non-standard? It's true that the upstream default is now
> not in the chroot, but it's totally a configuration supported by upstream.
On Thu, Dec 30, 2021 at 01:48:49AM +, Scott Kitterman wrote:
> It does. My question is on the other end of the problem. Once resolv.conf
> is updated, how do I trigger an action for another package? In this case
> it's copy the updated resolv.conf into the chroot and restart postfix. I
On Wed, Dec 29, 2021 at 04:35:22PM -0500, Scott Kitterman wrote:
> The postfix package ships a script in /etc/resolvconf/update-libc.d/ to
> restart
> postfix when resolv.conf is updated. As far as I know, that still works if
> the
> resolvconf package is installed, but if not (i.e. Debian
On Tue, Dec 07, 2021 at 10:45:27PM +0100, Vincent Bernat wrote:
> Same here. And they are now following security updates closely (in the
> past, there could lag two or three weeks behind). Flatpak compiles it
> from source (while UngoogledChromium let contributors compile it and
> publish the
On Fri, Dec 03, 2021 at 11:33:25AM -0500, Theodore Y. Ts'o wrote:
> Some stupid questions that I couldn't answer by reading the man page
> or doing a quick google search
> * How does ld.so --preload *work*?
ld.so is the ELF interpreter. If you run a normal binary, the kernel
rewrites this
On Fri, Dec 03, 2021 at 04:16:04PM +0200, Timo Lindfors wrote:
> Just a random thought: If you have configured a restricted shell (e.g.
> rbash) that only lets you execute commands in PATH, will this make it
> possible to bypass the restriction with "ld.so /tmp/some-random-binary"?
> This is not
On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> Right, thanks for providing a concrete example. A (somewhat) portable
> version would look like this:
> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
You mean
ld.so --preload libeatmydata.so.1.3.0 /bin/ls
?
ld.so
On Sat, Nov 20, 2021 at 11:31:04AM +0100, Thomas Goirand wrote:
> What worries me the most is mips6el, where the linker says "undefined
> reference to `__atomic_load_16'" (and more like this). I don't
> understand because there really is a -latomic parameter to GCC when
> linking, so it should be
On Sat, Nov 13, 2021 at 04:40:04PM -0500, Roberto C. Sánchez wrote:
> I'm not sure if this a directly relevant question (apologies if it is
> not), but is there migration path to allow bringing legacy log data
> *into* the systemd journal[*] to allow for accessing log data through a
> single
On Tue, Nov 09, 2021 at 08:19:40PM +0100, Michael Biebl wrote:
> I'm worried that by saying that unmerged is still supported in 12, we open a
> can of worms and just punt this down to yet another release cycle.
No, unmerged will not be supported in 12. Having the ability to create
something does
On Mon, Sep 20, 2021 at 02:11:06AM +, Paul Wise wrote:
> Normally one would get "Connection refused" when connecting to a port
> that isn't open,
"Connection refused" is generated by TCP reset packets.
> but at this site one gets "No route to host", as if
> there is no
On Sat, Sep 18, 2021 at 02:17:59PM +0530, open infra wrote:
> How build a package A where it has a circular dependent package B (where
> package B is depend on package A).
You try not to, at all costs.
Bastian
--
A woman should have compassion.
-- Kirk, "Catspaw", stardate
On Sun, Jul 18, 2021 at 11:13:37AM +0200, Marco d'Itri wrote:
> On Jul 18, Simon McVittie wrote:
> > If a machine's /usr is not in sync with its /etc and /var, then it is likely
> > to work incorrectly: at a minimum, asking dpkg which packages and versions
> But in my experience (with shared-/usr
Hi
On Fri, Jul 16, 2021 at 03:08:51PM +0200, Жора Волков wrote:
> A DKMS-built kernel module that I have on my system relies on system.map. A
> build script for the module parses that file in order to figure out
> addresses of certain functions.
No normal kernel module requires tinkering with
On Wed, Jul 14, 2021 at 11:59:11AM +0100, Simon McVittie wrote:
> It seems like this would also be good for src:linux, where ABI breaks
> are often tied to security fixes that should enter the archive ASAP.
As security updates are hand approved, accepting by NEW does not help
that much.
Bastian
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
> Asking on #debian-systemd, Marco d'Itri suggested, that we move
> libsystemd-shared into a separate binary package. This would only help, if
> we moved libsystemd-shared into a Multi-Arch location (which means, we'd
> have to carry a
Hi Lucas
I would like to add:
- Removing Berkeley DB.
Bastian
--
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4
On Tue, Apr 06, 2021 at 12:01:58PM +0200, Jonas Smedegaard wrote:
> Description : dkms driver sources for EC ACPI in Purism Librem devices
>
> The driver librem_ec_acpi provides Linux kernel support
> for the ACPI embedded controller of the following devices:
> * Purism Librem 14 laptop
Moin
On Sun, Jan 10, 2021 at 08:20:33PM +0100, Balint Reczey wrote:
> I'm not a fan of CLAs either, but as I understand upstream requiring a
> CLA is not a blocker for compression libraries.
Well, it means that the library might get incompatible with upstream,
because upstream will refuse
Hi Christian
On Fri, Dec 18, 2020 at 09:56:23AM +0100, Christian Kastner wrote:
> Description : Sphinx directive to add unselectable prompt
I'm trying to decipher what this (short) description is trying to tell
me. "Sphinx directive", okay. "prompt" still okay, however "command
line
On Mon, Oct 05, 2020 at 07:52:04AM +, Mo Zhou wrote:
> * License : CC-BY-SA
I hope you checked that?
Example:
| % head -n 6 docs/msg/ZFS-8000-14/index.rst
| ..
|CDDL HEADER START
|
|The contents of this file are subject to the terms of the
|Common Development and
Hi Enrico
On Sun, Sep 13, 2020 at 09:11:04AM +0200, Enrico Zini (DAM) wrote:
> * Minimum key size and acceptable algorithms are actually the domain of
>keyring-maint, and we just check those for them.
>At the time of writing this, a new key must be larger than 1024bits,
>ideally at
On Thu, Sep 17, 2020 at 11:38:46AM +0200, Andreas Tille wrote:
> The package has built before and the latest changes are:
> Am I
> missing something?
It built months before, with a lot of other changes surrounding it.
E.g. glibc
On Thu, Aug 20, 2020 at 10:24:18AM +0200, Bernd Zeimetz wrote:
> On 8/19/20 7:28 PM, Ansgar wrote:
> > Well, I can't fix it without creating dgit-ng (and setting up
> > infrastructure for that) as dgit upstream won't accept patches from me.
> That is just one of the reasons why I think that salsa
Hi
On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote:
> 2) Following changes to /bin/dmesg permissions in package 'util-linux'
> - Ownership changes to root:adm
> - Permissions changed to 0750 (-rwxr-x---)
You mean 0754?
> - Add cap_syslog capability to binary.
Can
On Thu, Jul 16, 2020 at 05:27:40PM -0700, Sean Whitton wrote:
> On Thu 16 Jul 2020 at 05:19PM -07, Sean Whitton wrote:
> > You would need the buggy version of the software if you wanted to
> > make modified versions of the binary data to test for closely related
> > bugs, for example.
And there
On Thu, Jul 16, 2020 at 08:42:24AM -0700, Sean Whitton wrote:
> I would remove the test data because it does not seem DFSG-conformant.
Care to explain? You can't claim DFSG violation without showing which
part.
Also please explain how you would make sure the code is tested.
Bastian
--
Hi Timo
On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote:
> 20.06.20 13:26 Bastian Blank:
> > Since the kernel supports overlayfs since some time now, what blocks
> > it's removal?
> There are Debian installations on filesystems that are incompatible with
> o
Hi Jan
On Sat, Jun 20, 2020 at 12:14:17PM +0200, Jan Luca Naumann wrote:
> At the moment aufs is nearly unmaintained since I do not have time due to
> personal issues. Therefore, I would be happy if there is somebody to
> co-maintain the package.
Since the kernel supports overlayfs since some
On Wed, Apr 29, 2020 at 02:00:05PM +0300, EoflaOE wrote:
> * Package name: core-setup
core-setup is pretty generic as name. Please rename it to something
more descriptive. I don't now if the dotnet stuff got a naming schema.
Bastian
--
There's a way out of any cage.
--
On Tue, Apr 28, 2020 at 02:32:55PM +0200, Bernd Zeimetz wrote:
> If you use ssh, you can create an own account for the ssh key and give
> it very special permissions, if you need it for automatic pushes or
> similar things.
Or add it as writable deploy key to a project.
Bastian
--
I'm a
On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote:
> Actually I think 2FA should be enforced for everybody.
No, we don't enforce 2FA for everybody. And I don't consider it
appropriate to raise the option.
However, you may choose to enforce 2FA for all users of your groups.
Regards,
Hi Bernd
On Fri, Apr 24, 2020 at 11:13:52PM +0200, Bernd Zeimetz wrote:
> On 4/18/20 11:33 PM, Bastian Blank wrote:
> > You are encouraged to use Salsa as an authentication provider for Debian
> > services. GitLab supports plain OAuth2 and OpenID Connect as
> > authentiat
Hi Harald
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote:
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
This is nothing uncommon.
> No tags.
So this upstream doesn't make releases but only
Hi Scott
On Wed, Feb 05, 2020 at 07:44:25AM +, Scott Kitterman wrote:
> >> Of course the fact that I can't use all the tools available to
> >manipulate text
> >> files to follow or analyze logs is problematic. If I'm using
> >journalctl, how
> >> do I replicate 'tail -f
On Wed, Feb 05, 2020 at 09:39:19AM +1100, Dmitry Smirnov wrote:
> For example, if a certain daemon manifested a condition when a message is
> logged too often, then with Rsyslog I could suppress noise by something like
> the following
This is a workaround for another problem. Fix the real
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 20 Jan 2020 16:34:23 +0100
Source: waagent
Architecture: source
Version: 2.2.45-2
Distribution: unstable
Urgency: medium
Maintainer: Bastian Blank
Changed-By: Bastian Blank
Changes:
waagent (2.2.45-2) unstable; urgency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 07 Jan 2020 14:44:41 +0100
Source: lvm2
Architecture: source
Version: 2.03.07-1
Distribution: unstable
Urgency: medium
Maintainer: Debian LVM Team
Changed-By: Bastian Blank
Changes:
lvm2 (2.03.07-1) unstable; urgency=medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 07 Jan 2020 11:21:13 +0100
Source: thin-provisioning-tools
Architecture: source
Version: 0.8.5-4
Distribution: unstable
Urgency: medium
Maintainer: Debian LVM Team
Changed-By: Bastian Blank
Changes:
thin-provisioning-tools
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 06 Jan 2020 17:53:00 +0100
Source: lvm2
Architecture: source
Version: 2.03.02-4
Distribution: unstable
Urgency: medium
Maintainer: Debian LVM Team
Changed-By: Bastian Blank
Changes:
lvm2 (2.03.02-4) unstable; urgency=medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 06 Jan 2020 17:50:40 +0100
Source: dpkg-source-gitarchive
Architecture: source
Version: 0.1.2
Distribution: unstable
Urgency: medium
Maintainer: Bastian Blank
Changed-By: Bastian Blank
Changes:
dpkg-source-gitarchive (0.1.2
On Fri, Jan 03, 2020 at 02:29:37PM -0500, The Wanderer wrote:
> The accepting of init scripts seemed to me like an essential piece of
> making sure those scripts would be present wherever they would be
> needed. Your suggestion above seems to provide a way to make it less
> essential, and thus
On Fri, Jan 03, 2020 at 10:31:53AM -0800, Russ Allbery wrote:
> Support for kFreeBSD and Hurd is obviously a valid argument in favor of
> some level of support for non-systemd implementations.
But then there is the question on how much work it would be to port the
**systemd** implementations to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 03 Jan 2020 14:37:26 +0100
Source: thin-provisioning-tools
Architecture: source
Version: 0.8.5-3
Distribution: unstable
Urgency: medium
Maintainer: Debian LVM Team
Changed-By: Bastian Blank
Closes: 931514
Changes:
thin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 03 Jan 2020 13:23:12 +0100
Source: dpkg-source-gitarchive
Architecture: source
Version: 0.1.1
Distribution: unstable
Urgency: medium
Maintainer: Bastian Blank
Changed-By: Bastian Blank
Changes:
dpkg-source-gitarchive (0.1.1
1 - 100 of 1585 matches
Mail list logo
