Lukas Märdian writes:
> On 23.09.24 12:27, Ansgar 🙀 wrote:
>> On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
>>> On 22.09.24 15:58, Ansgar 🙀 wrote:
On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
>>> The benefit that Netplan would provide in such cases is that
>>> debian-in
Lukas Märdian writes:
> On 04.09.24 17:26, Marco d'Itri wrote:
>> Do we even have general documentation about configuring networking?
>
> Yes, there is a "NetworkConfiguration" page on the wiki and the Debian ref:
>
> * https://wiki.debian.org/NetworkConfiguration
I dont thinj this page is usefu
PICCA Frederic-Emmanuel writes:
> What about dog fooding ?
>
> for now we can setup a schroot and sbuild very easily and start to build a
> local repository in minutes.
>
> But when it comes to install gitlab and the CI system it is another story. So
> we rely on the central salsa instance.
f
> My overall impression is that this is a bold attempt, but the document could
> do
> with some copy-editing to whittle it down, make it more focussed, and possibly
> narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be
> done further down the line in a follow-up DEP?
I
Bastien Roucariès writes:
>> b) but if im in a terminal (even if running in gnome) then i want a
>> terminal-based editor (based on what i installed)
>
> depends for me I prefer to run under emacsclient so you could do
> something like
> SENSIBLE_EDITOR='if [ -t 0 ]; then sensible-editor-GNOME ;
Bastien Roucariès writes:
> Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
> that sh -c accept
>
> My goal is to create a sensible-editor.desktop that will lauch by
> default the sensible-editor of choice
>
> For this I plan:
> - to allow by alternative mechanism to have an s
Otto Kekäläinen writes:
> Could you point me to some Debian Bug # or otherwise share examples of
> cases when a build succeeded locally but failed on official Debian
> builders due to something that is specific for sbuild/schroot?
I believe both these uploads
https://tracker.debian.org/news/128
Russ Allbery writes:
> Simon McVittie writes:
>
>> I know fail2ban and logcheck do read plain-text logs (although as
>> mentioned, fail2ban already has native Journal-reading support too), and
>> I would guess that fwlogwatch, snort and xwatch probably also read the
>> logs.
>
> logcheck also ha
Simon McVittie writes:
> On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
>> The list of affected packages according to apt-cache showpkg is not
>> that long either:
>>
>> logcheck
> However, for packages that want to read a traditional /var/log/syslog
> or similar, notably logch
Holger Levsen writes:
> I'm a bit surprised how many people seem to really rely on data in /tmp
> to survive for weeks or even months. I wonder if they backup /tmp?
I use /tmp for things that fall somewhere between "needs a backup" and
"unimportant, can be deleted whenever". I think all of the i
Luca Boccassi writes:
> qwhat would
> break where, and how to fix it?
Another one for you to investigate: I believe apt source and 'apt-get
source' download and extract things into /tmp, as in the mmdebootstap
example mentioned by someone else, this will create "old" files that
could immediately
Luca Boccassi writes:
> Hence, I am not really looking for philosophical discussions or lists
> of personal preferences or hypotheticals, but for facts: what would
> break where, and how to fix it?
- tmux stores sockets in /tmp/tmux-$UID
- I think screen might use /tmp/screens
I suppose if you
Luca Boccassi writes:
> On Mon, 6 May 2024 at 15:42, Richard Lewis
> wrote:
>>
>> Luca Boccassi writes:
>>
>> > Hence, I am not really looking for philosophical discussions or lists
>> > of personal preferences or hypotheticals, but for facts: what
Luca Boccassi writes:
> Hence, I am not really looking for philosophical discussions or lists
> of personal preferences or hypotheticals, but for facts: what would
> break where, and how to fix it?
cleaning /tmp or /var/tmp: users may lose files if they dont realise a
directory tmp can be clea
ispensable-geospatial-tool-you-didnt-know-you-were-missing/
Regards,
Richard Duivenvoorde
, but I also get why they may want
to restrict it.)
If Python is what you want, you could use waf, but there is one big
downside... You have to repack the upstream tarball:
https://wiki.debian.org/UnpackWaf
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
. It seems potentially confusing if some of the
relationships fields are included and some are not.
This proposal sounds generally good. I'll have to defer to others who
know more about potential corner cases.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Package: wnpp
Severity: wishlist
Owner: Richard Hansen
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: keyd
Version : 2.4.3
Upstream Contact: Raheman Vaiya
* URL : https://github.com/rvaiya/keyd
* License : Expat
Programming Lang: C
Helmut Grohne writes:
> I incline to agreeing with the scenario you depict. This can reasonably
> happen. I also think that David made a good case for it being unlikely
> to manage oneself into the buggy situation that way. And then the
> consequence is that you lost some possibly important files
Package: wnpp
Severity: wishlist
Owner: Richard Duivenvoorde
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: laz-perf
Version : 3.4.0
Upstream Contact: Howard Butler
* URL : https://github.com/hobuinc/laz-perf
* License : APLv2
Programming Lang
such a lintian check.
This repos from Trent Buck has a lot of research -
https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES
Indeed.
--
Richard
(strcmp(pathname, special) == 0) {
return;
}
}
unlink(pathname);
}
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
latively fixed (e.g. /bin, /usr/bin,
/lib), that might be workable.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
g that
should block the transition. By all means, transition and we will sort
things out.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
[ -e /etc/packagename ]
then
mv /var/lib/packagename /etc/packagename
fi
fi
fi
That said, I'm not sure what Policy has to say about this. It seems to
me that you want the package to do things right moving forward, and you
want to support clean upgrades, so this seems like the approach that
gets both of those.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
public
domain (at least not while it is still of useful/non-historical value).
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
ities Debian has for that. Would it be a
binNMU of everything?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
o existing packages.
--
Richard
'ed in to ntpc.py
by the build process).
I hope that helps.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
frequently. Would they likely exceed 22 in the near
future? If so, you might just do 22.3+really10.0.0+dfsg+~cs16.6.17-1 and
when they get to 23, it goes back to normal, without the epoch.
--
Richard
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
ftpmaster removal of src:ntp?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
values the idea of using the pristine
upstream tarball. Granted, sometimes that goal has to yield to higher
priority things, like DFSG compliance.
How do you feel about the pristine tarball concept?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
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
g with native format packages with Debian
revisions. They work just fine. For a small paockage, this is often
a good choice, because it avoids dealing with patches at all.
I don't follow the "avoid dealing with patches at all" piece here.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
(6)
#849265,
https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2017-January/032300.html
Should we really empty out the extra_groups list default?
With the exception of users, I wouldn't expect adduser to put people in
special groups by default. If those groups do nothing, I guess it's
moot. But in principle (and in the past), those groups give special
permissions and I would NOT expect that, nor want that.
--
Richard
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
ftp-master tool is relevant)
hard fail if going from non-date-based to date-based at the front of the
version string.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
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
ide of the certificate validity period?
This is a concern too. I did some brainstorming about this on the NTPsec
list a couple years ago, but neither I nor anybody else has implemented
this (nor do I have plans to do so myself):
https://lists.ntpsec.org/pipermail/devel/2019-February/007576
;re going to promote chrony instead, then I think we need some
more discussion and there would be more work, as it seems we should
then replace systemd-timesyncd with chrony in default installs too.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
I decided it was better to use a different namespace. This
does mean that Debian ntpsec is patched and diverges a bit from upstream
NTPsec.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
obably a lot)
longer, until it's no longer reasonable to install a .deb containing
non-usrmerged paths (which might be old or from a third party).
Am I missing something here?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
cmd to set CipherString, Ciphersuites, and MinProtocol per
$DAYJOB's general TLS policy. It may also be because of issues with
GnuTLS, I can't remember (and my comments/config messages don't indicate
that).
--
Richard
se. But
that's not the case right now and at this point, it's been ELEVEN YEARS.
It's time to move forward.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
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
ing time is low.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
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:
[...]
ding this file from an Ansible template and
most of it (by volume) is built by loops.
In the trivial case, it's 19 lines of netplan (16 if you exclude the
stock comment) vs 25 lines of systemd-networkd, both in single files.
That's not a huge difference.
--
Richard
shes to
override the TC, they need to propose a GR.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
way. That
said, Debian Policy is not binding on them anyway.
If it _is_ harmful for /etc/shells to reference shells that do no exist,
then maintaining the list automatically (by whatever mechanism,
including the current approach but fixing the bugs) makes sense.
--
Richard
How close is upstream to 3.0? If not close, are they willing to bump to
3.0 anyway to avoid this versioning issue?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
first discussed. Back then and today, agreed, it does not make sense
there.
IMO, it makes sense on both servers and desktops, so rather than
through tasksel, I would think it's a useful default to have on all
non-virtual installations.
Richard
I for now do not deny or admit officially. Marc, are you someone with
authority? I will clarify myself later, pretty lease
On wo, 2020-12-23 at 20:08 +0100, Marc Haber wrote:
> On Wed, 23 Dec 2020 19:43:18 +0100, Richard
> wrote:
> >I want to clarify I feel not up to seriously
I want to clarify I feel not up to seriously reading and thinking about
a response after a day of work, groceries and soms fastfood. But then I
saw master Geert responding in my topic. This I am glad to. I also want
to clarify, I amaware of both Humour and high level of intelect. I want
to learn fr
I have mailed a few official e-mails and some persons (surname@debian) i
have a request
On di, 2020-12-22 at 23:28 -0500, Calum McConnell wrote:
> On Tue, 2020-12-22 at 21:34 +0100, Richard wrote:
> > why no respond >:
>
> Sir,
> This is a volunteer organization. Any
why no respond >:
Package: wnpp
Severity: wishlist
Owner: Richard Lough
* Package name: golang-github-kubuxu-go-os-helper
Version : 0.0.1-1
Upstream Author : Jakub Sztandera
* URL : https://github.com/Kubuxu/go-os-helper
* License : Expat
Programming Lang: Go
Description
Package: wnpp
Severity: wishlist
Owner: Richard Lough
* Package name: golang-github-texttheater-golang-levenshtein
Version : 1.0.1-1
Upstream Author : Kilian Evang
* URL : https://github.com/texttheater/golang-levenshtein
* License : Expat
Programming Lang
;m not sure if additional text is
necessary to clarify this, especially since this isn't actually binding
on Kali anyway. But at the same time, I have no objection to that
additional text either.
--
Richard
signature.asc
Description: OpenPGP digital signature
ng term for that distinction in various places, including
dpkg-vendor.
--
Richard
signature.asc
Description: OpenPGP digital signature
Haloo Debian,
Ik heb wat e-mails verstuur den wil nu eindelijjk meedoen maar dan moet
iemand wel reageren op mijn e-mails?
Groeten,
Richard Waterbeek
Nederland
ersion of '1.1.0'
> So, I will need to add an epoch to the version to package it directly
> from its upstream repo.
Have you asked upstream if they would be willing to bump the version to
6.0 or something?
--
Richard
signature.asc
Description: OpenPGP digital signature
s_ than this could break builds. For example, if I have a
"free package in contrib that require[s]... non-free packages" (Policy
2.2.2) and the buildd doesn't include non-free, it will FTBFS when it
should build.
Am I missing something here? If I'm understanding everything co
cts/DebSrc3.0#How_to_use_multiple_upstream_tarballs_in_3.0_.28quilt.29_format.3F
[2]
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
--
Richard
signature.asc
Description: OpenPGP digital signature
t
"master", but "upstream/latest" is correct if it is the gbp
upstream-branch representing imported upstream tarballs.
--
Richard
signature.asc
Description: OpenPGP digital signature
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
tent with
debian/changelog, which traditionally uses "unstable" not "sid". It also
makes debian/experimental an outlier that cannot be made consistent
(because there is no character code name for experimental AFAIK).
--
Richard
signature.asc
Description: OpenPGP digital signature
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
er upstream.
Then you don't need a branch name in debian/control.
--
Richard
signature.asc
Description: OpenPGP digital signature
n/{master,latest}, is that out of a considered preference over
debian/unstable or out of inertia / following other packages / following
DEP-14? In other words, how many people _care_ either way?
--
Richard
signature.asc
Description: OpenPGP digital signature
/unstable is no
more trouble.
[1] https://lists.debian.org/debian-devel/2019/11/msg00084.html
[2] https://lists.debian.org/debian-devel/2019/11/msg00085.html
--
Richard
signature.asc
Description: OpenPGP digital signature
Package: wnpp
Severity: wishlist
Owner: Richard Hansen
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: libcgi-application-plugin-debugscreen-perl
Version : 1.00
Upstream Author : Atsushi Kobayashi
* URL :
https://metacpan.org/release/CGI-Application
acing a host named "name" to "name-new". This
prompt helps you keep track of whether you are on the current production
system or the -new system you are configuring. It is functionally
equalivalent to:
ps_h='\[\e[1;37m\]\[\e[1;41m\]\h\[\e[0m\]'
--
Richard
signature.asc
Description: OpenPGP digital signature
> my thoughts exactly.
Agreed. Nothing else in the debian directory is hidden. I think the
burden should be on justifying why this should be the one hidden directory.
--
Richard
signature.asc
Description: OpenPGP digital signature
there was
another reason, not under debate, for why it was rejected. This thread
was only to address the QR code question.
--
Richard
signature.asc
Description: OpenPGP digital signature
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
dirs as user home directories.
I actually use both /srv/ftp and /srv/tftp, but I still don't think
those are acceptable defaults.
> I wonder if any of these should be changed?
FWIW, I would say yes.
--
Richard
signature.asc
Description: OpenPGP digital signature
not DFSG compliant?
> only from components provided by Debian.
While I agree it would be better in Debian to use a Debian image instead
of an Alpine one and to use Debian packages, that is separate from DFSG
compliance and a much lower severity issue.
--
Richard
signature.asc
Description: OpenPGP digital signature
quot; pushing for the
> most security possible. Even real experts sometimes lose sight of the
> balance between usability and security. Unfortunately, there are a lot
> more "wannabes" than real experts, and the "wannabes" are typically much
> more vocal.
While I understand your point, I think it would be better to focus on
the arguments rather than the people making them.
--
Richard
signature.asc
Description: OpenPGP digital signature
ill be motivated to fix it (either the root issue or
by changing the setting). If you default to compatible, very few people
will find the option and tweak it, so most people will lose out on the
security. If there is massive breakage, you can back it off, of course.
--
Richard
signature.asc
Descr
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
hould be
installed on the buildd and then the package should be rebuilt from
source, with _that_ result being put into the archive. This doesn't
protect against the trojaned-compiler problem, but it does at least
ensure that the package builds from source.
--
Richard
signature.asc
Description: OpenPGP digital signature
cks/space/blog/linux/SystemdTimersAndErrors
[3] https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimersMailNotes
This one quotes my comment on article [2]:
[4]
https://utcc.utoronto.ca/~cks/space/blog/sysadmin/NotificationsVersusLogs
--
Richard
signature.asc
Description: OpenPGP digital signature
e, the user would have to disable the systemd timer and add the
symlink. I'd mention this in the NEWS.
With this proposeal, the maintenance script should also stop checking
CRON= (or for the systemd timer), and CRON= should be removed from
/etc/default/spamassassin (though that needs to be done AFTER the check
above fires).
--
Richard
signature.asc
Description: OpenPGP digital signature
If you wanted, you could migrate from /etc/cron.daily to /etc/cron.d and
then apply this approach, but you'd still have the "local modifications"
problem.
If you are willing to drop support for direct local modifications, then
you could use cron.d and disable the script in cron.dail
you asked upstream to ship the tests in the tarball?
--
Richard
signature.asc
Description: OpenPGP digital signature
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
evel at the time. I have tried to set In-Reply-To
directly, but this is my first attempt at doing so. In these situations, I
would normally download the mbox archive, import it, and reply to the message
that way, but mbox archives are seemingly unavailable (at least to non-DDs?)
for Debian lists.
--
Richard
signature.asc
Description: OpenPGP digital signature
Package: wnpp
Owner: Cyril Richard
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org
* Package name: spview
Version : 2.0.0~beta1
Upstream Author : Cyril Richard
* URL : https://gitlab.com/lock042/spview
* License
1 - 100 of 603 matches
Mail list logo
