On 2024-12-03 15:45, Marc Haber wrote:
On Tue, Dec 03, 2024 at 10:18:46PM +0100, Gioele Barabucci wrote:
Normalization is always lossy, at least in principle.
Applications that employ normalization accept that tradeoff in order to gain
something valuable: in this case the ability to have a Ohm
On 2024-04-02 11:05, Russ Allbery wrote:
Meson honestly sounds great, and I personally love the idea of using a
build system whose language is a bit more like Python, since I use that
language professionally anyway. (It would be nice if it *was* Python
rather than yet another ad hoc language, bu
On 2024-02-22 12:32, Niels Thykier wrote:
I am omitting Breaks, Conflicts, and Replaces because I am not aware of
any users of these at the moment. I am open to adding them, if there is
a strong use-case.
I think you should include them (and Enhances as Sam Hartman mentioned)
for consistency.
On 2023-07-03 14:21, RL wrote:
Russell Coker writes:
https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
I think we should make it a release goal to have as many daemons as
possible running with systemd security features to aim for a low score
from "systmd- analyze security".
It wou
I know I haven't thought about this as much as others, so I might be
naively missing something here.
Is the broader context here that this is an alternative to teaching dpkg
about aliasing? That is, we just arrange the transition correctly such
that we get out of the aliased situation as part
On 2023-06-09 11:26, Helmut Grohne wrote:
When upgrading (or
removing that package), dpkg will attempt to remove /bin (which in its
opinion is an empty directory and the last consumer is releasing it).
However, since dpkg has no clue about file types, it doesn't actually
know that this is a direc
I support transitioning to 64-bit time_t. Thank you for taking this on!
Gentoo has a similar migration:
https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration
They mention, "We likely have to complete Modern C porting first to
remove any instances of -Wimplicit-function-declaration ot
On 4/20/23 14:48, Perry Naseck wrote:
Hello!
I am in the process of updating/upgrading a package from an init.d
service to a Systemd service. Are there any recommended guidelines for
this process?
My generic advice would be: start your thinking from a perspective of
"how should this work in
I maintain a package where upstream has dropped the years. I was told
that multiple big tech companies with serious lawyers looked at this and
felt it was fine.
I fully support:
- upstreams dropping years from copyright notices
- Debian not requiring maintainers to preserve years in
deb
On 10/26/22 13:20, Moritz Mühlenhoff wrote:
Wookey wrote:
So the immediate issue now is whether or not to enable this by default
in bookworm?
The majority of packages will not be rebuilt until the release
How hard would it be to rebuild everything?
I don't actually know what facilities Debi
On 9/8/22 23:07, Qx wrote:
1)i have coded a tool which I would like to release for ubuntu. Can
someone please advice as to how this is correctly done?
You sent this to a Debian list.
If you want to package the software for Debian (which will then flow
downstream into Ubuntu), start with the D
On 6/2/22 14:15, Alec Leamas wrote:
Hi Audrey
On 02/06/2022 20:16, Andrey Rahmatullin wrote:
On Thu, Jun 02, 2022 at 07:19:56PM +0200, Alec Leamas wrote:
Dear list,
I try handle a package which installs a partly compiled,
architecture-dependent python module. Until now this has been done in
On 5/19/22 05:42, Pirate Praveen wrote:
So current version in the archive is 22.2.3+dfsg+~12.2.3-1
The fixed version we want is 10.0.0+dfsg+~cs16.6.17-1
I have no dog in this fight as they say, but...
How fast does upstream bump versions? With a 10.x, I wonder if it might
be relatively frequ
On 4/27/22 12:57, Nilesh Patra wrote:
I am looking for more opinions.
Patch every instance of /srv/shiny-server to /var/lib/shiny-server. The
admin can customize from there.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
If you use ntp, I would appreciate if you could test the transition to
ntpsec. ntpsec 1.2.1+dfsg1-5 has been uploaded to experimental and
cleared the NEW queue.
Bernhard Schmidt suggested and I used
1:4.2.8p15+dfsg-2~$(DEB_VERSION_UPSTREAM_REVISION) as the version for
the transitional packag
On 3/15/22 10:36, Ian Jackson wrote:
Lucas Nussbaum writes ("Re: proposed MBF: packages still using source format
1.0"):
As explained in https://lists.debian.org/debian-devel/2022/03/msg00165.html
I proceeded with the MBF for packages that match
not (debian_x or (vcs and vcs_status != 'ERROR' a
On 3/9/22 23:47, Marc Haber wrote:
On Wed, 9 Mar 2022 14:35:52 -0600, Richard Laager
wrote:
If the admin can change the default DIR_MODE that applies to system user
home directories, then any postinst script doing `adduser --system`
needs to also explicitly chmod its home directory if it
On 3/9/22 14:00, Marc Haber wrote:
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager
wrote:
On 3/8/22 10:49, Marc Haber wrote:
(1a) would it be necessary to handle --system accounts differently? I
think yes. > (1b) should we stay with 0755 for --system accounts?
I don't
On 3/9/22 10:38, Ian Jackson wrote:
This prohibition exists solely because of a doctrinal objection to
native-format packages with Debian revisions.
As I understood it, the idea was that you could just increment the
"actual" version number. I'm failing to see the advantage of
incrementing "a"
On 3/8/22 10:49, Marc Haber wrote:
(1)
#202943, #202944, #398793, #442627, #782001
The bug reporters are requesting the default for DIR_MODE to be changed
from 0755 to 0700, making home directories readable for the user only.
Policy 10.9 states that directories should be 0755, but the policy
edit
On 1/19/22 15:04, Bernhard Schmidt wrote:
On 19.01.22 20:34, Richard Laager wrote:
2. I create transitional binary packages in src:ntpsec:
I got to thinking about this more. This won't work, because src:ntp is
1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch
On 1/23/22 10:04, Thomas Dickey wrote:
In #1003769, Andreas Metzler wrote:
1. The upload introduces an epoch because the upstream version went from
mmdd to 2.0.mmdd. Given that the new version scheme seems to
have found acceptance in e.g. Fedora /I/ do not see a better way. Could
you ask
On 1/20/22 8:04 AM, Thomas Goirand wrote:
On 1/19/22 20:34, Richard Laager wrote:
For people that want something more than systemd-timesyncd, e.g. to
get NTS, I think either are acceptable choices. It seems that the
consensus for new installs is towards chrony over ntpsec. But I don't
On 1/19/22 3:13 PM, Bernhard Schmidt wrote:
I agree we should have a look at this (either ntpsec or chrony, both do
NTS), but I think this should be done completely independently of the
ntp.org->ntpsec migration.
+1 that promoting NTS is orthogonal.
If the bigger problems below are solved, it
On 1/19/22 9:49 AM, Bernhard Schmidt wrote:
AFAICT other than systemd-timesyncd being installed by default we don't
have a "default" NTP daemon in Debian.
I'm not sure how much more "default" it can be than installed by
default. So I'd say we do have a default: systemd-timesyncd.
So we shoul
[I'm the Debian ntpsec maintainer.]
On 1/18/22 11:21 AM, Paride Legovini wrote:
> I'd prefer making ntp a dummy package depending on ntpsec rather than
> having src:ntpsec takeover bin:ntp.
If I understand correctly, you're suggesting src:ntp builds bin:ntp that
is a dummy package which depends
On 11/17/21 8:18 PM, Zack Weinberg wrote:
However, I think it was the responsibility of the developers of usrmerge
to find out how bad that problem actually was, rather than dismissing it.
And, as it has proven to be a genuinely critical problem, it is also their
responsibility to fix it, per the
On 11/11/21 1:23 PM, Michael Biebl wrote:
Nowadays I'm not so sure anymore, e.g. I'm even considering disabling
GnuTLS support in librelp.
Just wondering if anyone would object to such a change?
I would not. I force OpenSSL anyway. That is at least in part so we can
use tls.tlscfgcmd to set
On 11/10/21 12:50 PM, Andrej Shadura wrote:
On Wed, 10 Nov 2021, at 19:18, Sam Hartman wrote:
I understand that it's generally better to fix bashisms in configure
scripts.
Is it possible to force autoconf to prefer bash for a given configure
script if it's difficult or undesirable to fix bashism
On 10/7/21 11:35 AM, Russ Allbery wrote:
Richard Laager writes:
I haven't looked into the specifics of this situation, but in general,
tests should be run against the same versions of dependencies that the
actual code will use, for what should be obvious reasons. If Debian ha
On 10/7/21 4:40 AM, Pirate Praveen wrote:
What you are proposing would require the package maintainer to adapt these
tests to versions available (many times with different API versions) in Debian
and the easier choice is disabling tests.
I haven't looked into the specifics of this situation,
On 9/28/21 11:49 AM, Vincent Bernat wrote:
❦ 28 September 2021 11:16 -05, Richard Laager:
As to what should be the distro default, I'm not sure I am convinced
either way, but to argue the other side... There is some value in
using netplan by default. Some random thoughts:
[...]
On 9/28/21 8:44 AM, Vincent Bernat wrote:
❦ 28 September 2021 01:29 -05, Richard Laager:
As to what should be the distro default, I'm not sure I am convinced
either way, but to argue the other side... There is some value in
using netplan by default. Some random thoughts:
[...]
On 9/27/21 9:15 PM, Marco d'Itri wrote:
On Sep 28, Noah Meyerhans wrote:
Should it be mentioned what the new recommended DHCP server for general
use will be?
ISC Kea?
I haven't converted to it, but that's their replacement for dhcpd.
I think that a good default would be systemd-networkd fo
On 8/27/21 10:20 AM, Theodore Ts'o wrote:
Does someone need to create patches to dpkg which attempt to teach it
that /bin/foo and /usr/bin/foo are the same file, if there exists a
symlink from /bin to usr/bin?
Yes. I can't speak to the dpkg internals, but conceptually, this seems
like the righ
On 6/14/21 7:39 AM, Helmut Grohne wrote:
At this time, my personal preference would be turning /etc/shells into a
symbolic link to an autogenerated file.
Is there a harm in /etc/shells containing shells that are not installed
on the system? If not, then we could ship a single /etc/shells in
b
On 5/23/21 8:34 AM, Sudip Mukherjee wrote:
And, as a result, upstream kernelshark is now at v2.0 but the Debian
packaged version is at v2.9.1 and I will need to add an epoch to the
version to package it directly from its new upstream repo.
Current version: 2.9.1-1
Proposed version: 1:2.0-1
How
On 11/29/20 10:11 AM, Paride Legovini wrote:
> I tried to do a synthesis of past August/September thread on the
> finalization of DEP-14 [1], see:
>
> https://salsa.debian.org/dep-team/deps/-/merge_requests/1/diffs
This all looks great to me!
> I tried to stick to what I believe we had consensus
On 11/29/20 1:33 PM, RhineDevil wrote:
> A viable solution for achieving this may be using an optional -f/--flavour
> parameter
Is flavour intended to be something like Debian vs. Devuan vs. Ubuntu?
If so, could you please use "vendor" instead, since that is the
pre-existing term for that distinc
On 10/13/20 11:40 AM, Sudip Mukherjee wrote:
> libtracevent is currently being packaged from the linux kernel source
> and as such it has the version of '5.8.14-1' same as the kernel. As
> reported in #971976, the upstream libtraceevent now lives in its own
> repo and has a version of '1.1.0'
> So,
On 9/30/20 4:45 PM, Paul Wise wrote:
> The
> official buildds, for packages in main, seem to include contrib but
> not non-free binary packages in the chroot's apt sources.list files.
> Both contrib and non-free source packages are available in the chroots
> apt sources.list files. This appears to
On 9/14/20 2:04 PM, Andreas Tille wrote:
> in the Debian Med team there are two GSoC students very busy to write
> autopkgtests for (in the long run) all our packages (if possible).
That is an excellent thing to do.
> On Sun Sep 13 18:00:08 BST 2020, Thorsten Alteholz wrote:[3]
>> please don't h
On 9/11/20 11:26 AM, Xavier wrote:
> $ salsa --group xx-team --all --no-fail rename_branch \
> --source-branch=upstream --dest-branch=master
Should "upstream" be "upstream/latest"?
As I understand it, "master" is correct if it is the upstream git
"master", but "upstream/latest" is cor
On 9/7/20 5:33 AM, Raphael Hertzog wrote:
> On Sat, 05 Sep 2020, Richard Laager wrote:
>> I do not see why we have to prohibit occasional uploads to experimental
>> from debian/unstable. If this is permitted, then that also avoids the
>> busywork of creating debian/experime
at also avoids the
busywork of creating debian/experimental in that scenario.
On 8/30/20 4:27 PM, Raphael Hertzog wrote:
> Hello,
>
> On Sun, 30 Aug 2020, Richard Laager wrote:
>> You could use debian/experimental all the time and then merge down to
>> debian/unstable only when
On 8/30/20 12:02 PM, Sean Whitton wrote:
> Hello Raphael,
>
> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
>> index 0316fe1..beb96ea 100644
>> --- a/web/deps/dep14.mdwn
>> +++ b/web/deps/dep14.mdwn
>> +In the interest of homogene
I think I now have a better handle on how/why I disagree with the DEP-14
recommendation language.
On 8/30/20 8:36 AM, Raphael Hertzog wrote:
> On Sat, 29 Aug 2020, Richard Laager wrote:
>> That said, I do understand we give a lot of deference to developers'
>> workflows. So I
On 8/29/20 5:16 PM, Simon McVittie wrote:
> On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote:
>> However, this is still saying that one should prefer debian/latest over
>> debian/unstable, and that debian/unstable is (sort of) only for use when
>> you're also
On 8/29/20 5:19 PM, Russ Allbery wrote:
> The problem in my case with not putting a branch name in Vcs-Git is that,
> for packages for which I'm also upstream, the default branch in the
> repository named in that header is the upstream development branch, which
> contains no Debian packaging files
On 8/29/20 3:33 PM, Russ Allbery wrote:
> I think the primary thing that bothers me about this workflow is that
> experimental becomes an ephemeral branch, which appears and disappears
> based on the vagaries of the release cycle.
To me, that feels like the branch is an accurate representation of
On 8/28/20 6:01 PM, Raphael Hertzog wrote:
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is pref
Some notes from our defaults at $DAYJOB. I can't take credit for most of
this. These were ideas I've picked up from various people along the way.
# Prevent users from accidentally overwriting files with redirection.
set -o noclobber
Warning: While I'm the one that added it, sometimes I don't lov
On 5/3/20 5:54 PM, Holger Levsen wrote:
> On Sun, May 03, 2020 at 10:56:32PM +0200, Simon Richter wrote:
>> Frankly, I don't see the point in hiding the directory. The only person
>> who'd ever look into that directory would be someone inspecting what
>> happened during a build process, and all tha
On 3/30/20 2:34 PM, Sean Whitton wrote:
> The text quoted from the -private IRC channel is a bit misleading. I
> was the one who rejected the upload, and it was not actually because of
> the QR codes, but for other reasons.
I think it was pretty clear from the original email that there was
anothe
On 3/16/20 12:25 PM, Emmanuel Kasper wrote:
> For extended functionality, I build some of the disk images with a
> package from contrib, namely virtualbox-dkms
Could you use KVM (and if necessary, libvirt) instead?
--
Richard
signature.asc
Description: OpenPGP digital signature
t is a form of version control system log,
I'm a big fan of using git-buildpackage and `gbp dch`. My current
workflow (somewhat "copied" from e.g. lintian) is that debian/changelog
contains a stub like this until it is time to tag a Debian package release:
ntpsec (1.1.8+dfsg1-4+git
On 2/6/20 9:41 AM, Daniel Baumann wrote:
> On 2/6/20 4:10 AM, Richard Laager wrote:
>> That's been my interpretation too. My expectation as a sysadmin is that
>> /srv is available for my _exclusive_ use.
>
> in the case of vsftp and tftpd-hpa, there's a debconf ques
On 2/5/20 7:36 PM, Paul Wise wrote:
> AFAICT from Debian's FHS
> documentation, since /srv is laid out differently on different hosts
> packages should not rely on a particular layout. My interpretation is
> of this is that packages should never touch /srv unless directed to do
> so by the sysadmin
On 2/5/20 5:05 PM, Dmitry Smirnov wrote:
> It should be on abuser
Saying "abuser" is inflammatory, especially as no abuse has been proven.
Please stop.
> to explain that it was not possible to build a
> service in a fully DFSG compliant manner
Why is the current solution not DFSG compliant?
>
[ Note: I have reordered the quoted text blocks. ]
On 1/29/20 8:28 AM, Marvin Renich wrote:
> On the other hand, I do agree with using unstable and testing to
> determine the level of disruption, on the condition that there is a
> _commitment_ to removing the feature before stable release if the
>
On 1/28/20 9:23 PM, Craig Small wrote:
> My personal preference is to lock them down by default, by setting both
> to mode 2.
FWIW: I agree. Unless massive breakage is expected, the default should
be the most secure option. If you default to secure and that breaks
something, people will be motivate
Package: wnpp
Severity: wishlist
Owner: Richard Laager
* Package name: talkatu
Version : 0.1.0-dev
Upstream Author : Gary Kramlich
* URL : https://bitbucket.org/rw_grim/talkatu/
* License : GPL-2+
Programming Lang: C
Description : GTK+ widgets for
Package: wnpp
Severity: wishlist
Owner: Richard Laager
* Package name: libgnt
Version : 2.14.0-devel
Upstream Author : Pidgin Developers
* URL : https://bitbucket.org/pidgin/libgnt/
* License : GPL-2+
Programming Lang: C
Description : GLib Ncurses
Package: wnpp
Severity: wishlist
Owner: Richard Laager
* Package name: gplugin
Version : 0.29.0
Upstream Author : Gary Kramlich
* URL : https://bitbucket.org/rw_grim/gplugin/
* License : GPL-2+
Programming Lang: C
Description : GObject based plugin
On 1/17/20 6:55 AM, Sam Hartman wrote:
>> "Johannes" == Johannes Schauer writes:
>
> Johannes> or have a mechanism that allows maintainers to tell buildds
> "please build this
> Johannes> source package with build profiles X and Y enabled". That would
> then build the
> Johannes
On 1/8/20 1:02 PM, Michael Stone wrote:
> As a third party with no particular ax to grind on this, I do wonder
> what the advantage is to adding another mechanism for this particular
> use case, given the need to somehow handle upgrades involving an
> existing (presumably working?) solution.
At my
On 1/8/20 4:25 PM, Josh Triplett wrote:
> (I would suggest doing the same for the cron job, for new installations:
> put the script itself in /usr/lib/spamassassin or similar, and document
> that people can enable it by either enabling the systemd timer, linking
> the script from cron.daily, or cop
On 1/7/20 3:18 PM, Noah Meyerhans wrote:
> Current the cron.daily script is a no-op by default, and functionality
> is enabled by setting CRON=1 in /etc/default/spamassassin. For users
> running systemd, I'd expect to ship a timer unit that is disabled by
> default, and have them enable it with:
>
On 12/12/19 2:48 AM, Jean-Michel Vourgère wrote:
> Upstream of phppgadmin has nice unit tests in its github.com repository, but
> they use a .gitattributes file [1] to strip these tests files from the
> distributed tar files: All the unit tests are missing from the orig.tar.
Have you asked upstr
On 11/20/19 3:01 PM, Sean Whitton wrote:
> For example, I would request obsolete-national-encoding@debian/copyright
> rather than national-encoding@debian/copyright.
Or perhaps obsolete-encoding@?
--
Richard
signature.asc
Description: OpenPGP digital signature
On 11/7/19 7:40 AM, Thorsten Glaser wrote:
> I also often deal in software which
> has more… flexibility than the DEP 5 format allows, or where it is
> plain simpler.
Would you be willing to share an example, at a minimum just the name of
the package?
--
Richard
On 11/5/19 9:51 PM, Nicholas D Steeves wrote:
> Richard Laager writes:
>> I'd love to see more information about a recommended branch
>> structure. FWIW, I've been using branches named for each release
>> (e.g. "sid" is the default, but I also have "b
This all looks very good.
Presumably the repository / Salsa project name should match the source package
name? If so, that might be good to note, at least as the default.
I'd love to see more information about a recommended branch structure. FWIW,
I've been using branches named for each release
73 matches
Mail list logo
