Am 14.07.21 um 13:47 schrieb Michael Biebl:
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and
auto-accept
packages from the given source package that match the regex
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without man
Hi Guillem,
thanks for your feedback
Am 09.07.21 um 13:46 schrieb Guillem Jover:
If the private library has no backwards or forward compatibility (due
to the SONAME used) the time window where the library does not match
the expectations of the stuff linked to it might indeed be too big.
The l
Am 09.07.2021 um 13:01 schrieb Timo Röhling:
* Michael Biebl [2021-07-09 12:29]:
That tightly versioned dependency doesn't help unfortunately. There is
still a time window between the new libsystemd-shared and the new
systemd being unpacked.
There's also a time window between fil
Am 09.07.2021 um 11:37 schrieb Timo Röhling:
* Michael Biebl [2021-07-09 11:01]:
Splitting out libsystemd-shared (once) will make PID1 very brittle. It
can lead to situations where old systemd + new libsystemd-private is
installed. If the installation is aborted at this point, you have an
Am 09.07.21 um 10:28 schrieb Helmut Grohne:
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
Option 2 would be to drop Multi-Arch: foreign from systemd. This would mean,
that packages like libpam-systemd/libnss-systemd can no longer be installed
for a foreign architecture (even
Am 09.07.21 um 10:28 schrieb Helmut Grohne:
I concur with Marco here and I argue that splitting the library is my
preferred solution. I confirm that you'd need to move the library for
this to work. For the other points I do not follow. I think it would be
ok to move the library using code inside
Hi,
a couple of days ago, the following bug report was filed against systemd
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
I'm quoting the relevant parts
I noticed that systemd-machined was failing to start on an arm64
box. This box had armhf enabled, and turns out systemd had been
Am 12.03.21 um 21:51 schrieb picca:
Michael Biebl writes:
Have you installed a graphical user interface like e.g. GNOME?
yes Gnome
I'm not sure, why you install GNOME on a server.
I guess you need to figure out first, which component triggered the
suspend request.
Do you know h
Am 12.03.21 um 21:16 schrieb Picca Frédéric-Emmanuel:
Package: general
Severity: normal
X-Debbugs-Cc: pi...@debian.org
Hello, I just wanted to report an issue I am facing with my servers.
I used the bullseye beta3 of the installer, but If I remember correctly
it was already the same with buster.
Am 19.02.21 um 15:50 schrieb Marc Haber:
On Fri, 19 Feb 2021 10:34:45 +0100, Florian Lohoff wrote:
All locate variants are a PITA on servers, especially when virtualized.
Imagine a 100+ VM hypervisor at 6:30 starting an updatedb job on all VMs
in parallel. I debugged stuff like that for custome
Am 07.01.21 um 22:39 schrieb Michael Hudson-Doyle:
I'm hardly an expert in such things but it looks to me as if gcc is
ordering things differently between the two builds:
https://tests.reproducible-builds.org/debian/dbd/unstable/arm64/systemd_247.2-4.diffoscope.html#systemd-tests_---.---_arm--.
[crossposting this to the reproducible-build mailing list. Please CC on
replies, as I'm not subscribed]
Am 07.01.21 um 18:24 schrieb Michael Biebl:
Hi,
as can be seen at [1], systemd does not build reproducibly on armhf and
arm64 (while there is no problem on amd64 and i386).
The probl
Hi,
as can be seen at [1], systemd does not build reproducibly on armhf and
arm64 (while there is no problem on amd64 and i386).
The problem is, I have no idea what the diffoscope diff [2] means and
how I can make the package build reproducibly everywhere or how I can
further investigate thi
Hi,
with systemd 247.2-2, the default cgroup hierarchy has been switched to
unified (i.e. cgroupv2).
If you want to read more about the benefits of cgroupv2 vs cgroupv1, I
would suggest [1].
In Debian, all major container tools should support cgroupv2.
My special thanks go to Ryutaroh Matsumot
Am 20.10.20 um 15:16 schrieb Jonas Smedegaard:
> This was just now brought to my attention:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105
>
> Do I understand correctly that Debian now ignore OpenSSL
> incomatibilities with GPL?
>
> I.e. do we no longer need to either a) seek sp
Hi,
there has been a lot of talk recently about how master is a loaded term
that should be avoided.
If I read the news correctly, github and others are going to change the
default master branch to main.
I don't really have any strong opinion on that matter myself.
That said, what I care about is
Am 04.05.20 um 09:55 schrieb Raphael Hertzog:
> On Sat, 02 May 2020, Scott Kitterman wrote:
>> Personally, I don't see any real benefit of standardizing on (making up an
>> example here) debian/.build over debian/build.
>
> Same here. The arguments against debian/build are very weak. If we care
>
Am 29.04.20 um 19:37 schrieb Simon McVittie:
> On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote:
>> I think you should
>> file the bugs at severity:minor, given the amount of involved packages,
>> and the fact that you state we might not be able to remove gtk2 in many
>> many years.
>
Am 26.04.2020 um 23:47 schrieb Paride Legovini:
>
> Another good one with builtin backup functionality is Aegis [1,2]. It's
> GPLv3 and available via f-droid.
>
Thanks, haven't heard of it before but looks interesting.
Michael
--
Why is it that all of the instruments seeking intelligent life
Am 26.04.20 um 14:36 schrieb Mattia Rizzolo:
> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>> There are even cli tools that do the same stuff. I'd guess there is at least
>> one on Debian.
>
> Indeed, after I first lost a phone, and a second one broke, leaving me
> with a quite
Am 24.04.20 um 10:12 schrieb Phil Wyett:
> See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958182
Could we have a official statement whether alioth-lists.debian.net is
going away (anytime soon) or not? I hope not, fwiw.
Michael
signature.asc
Description: OpenPGP digital signature
Am 23.04.2020 um 16:59 schrieb Simon Richter:
> As far as I can see, there is no similar mechanism in systemd that allows
> blanket refusal or logging of unknown services, only masking of known
> services by name. The method of using a custom target comes closest, is
> there a namespace of target
Am 23.04.20 um 00:43 schrieb Thomas Goirand:
> On 4/22/20 4:11 PM, Sam Hartman wrote:
>> And a native interface for a sysadmin overriding that (masking).
>
> Unless I'm mistaking, that's not useful if you want to disable starting
> the daemon before installing it (ie: before the .service exists i
Am 14.04.20 um 11:49 schrieb Michael Biebl:
> Am 14.04.20 um 10:26 schrieb Markus Frosch:
>
>> What are your thoughts on that? Is there any other thread
>> discussing this? The current bugs for apt touching on virtual
>> package don't really mean this behavior.
Am 14.04.20 um 10:26 schrieb Markus Frosch:
> What are your thoughts on that? Is there any other thread
> discussing this? The current bugs for apt touching on virtual
> package don't really mean this behavior.
I can not reproduce your problem in a sid chroot.
When nginx (nginx-full to be precise
Am 15.02.20 um 23:11 schrieb Guillem Jover:
> On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote:
>> On Feb 15, Sven Joachim wrote:
>>> True, but there seem to be a relatively high number of systems where an
>>> old unowned version of some library is lying around under /lib (possibly
>>> bec
Am 15.02.20 um 19:48 schrieb Sven Joachim:
> True, but there seem to be a relatively high number of systems where an
> old unowned version of some library is lying around under /lib (possibly
> because the dpkg database became corrupted at some point and so dpkg
> forgot about the file; see the dp
Am 06.02.20 um 09:22 schrieb Adam D. Barratt:
> On 2020-02-06 08:12, Paul Gevers wrote:
>> Hi,
>>
>> On 06-02-2020 00:07, Adam D. Barratt wrote:
>>> On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote:
On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
wrote:
> Because this chan
Am 05.02.20 um 07:49 schrieb Michael Biebl:
> Am 05.02.20 um 07:01 schrieb Scott Kitterman:
>
>> Not particularly useful IMO. In /var/log/mail.log I can see log entries
>> from
>> all the programs configured to log to the mail facility. That way I can see
>> the
Am 05.02.20 um 06:08 schrieb Russell Stuart:
> journald has nits I mention below, but I was prepared to put up with
> them and drop rsyslog until one day a server stopped in a nasty way and
> journalctl refused to display what lead up to the crash because it's
> binary logs were corrupt. As far as
Am 05.02.20 um 07:01 schrieb Scott Kitterman:
> Of course the fact that I can't use all the tools available to manipulate
> text
> files to follow or analyze logs is problematic.
Fwiw, you can still run
journalctl -f | grep bla | awk and what not
which will filter / process incoming messages
or j
Am 05.02.20 um 07:01 schrieb Scott Kitterman:
> Not particularly useful IMO. In /var/log/mail.log I can see log entries from
> all the programs configured to log to the mail facility. That way I can see
> the interaction between them. On a typical server that is for sending mail I
> often ne
Hi Steve
Am 01.02.20 um 14:36 schrieb Steve McIntyre:
> Michael Biebl wrote:
>>
>> with today's upload of systemd 244.1-2 I finally enabled persistent
>> journal by default [1]. It has been a long requested feature.
>>
>> The package will create a director
Hi,
with today's upload of systemd 244.1-2 I finally enabled persistent
journal by default [1]. It has been a long requested feature.
The package will create a directory /var/log/journal on upgrades and new
installs, which enables persistent journal in so called auto mode.
If you decide, that yo
Am 09.01.20 um 13:08 schrieb Michael Stone:
> On Wed, Jan 08, 2020 at 07:12:17PM -0800, Russ Allbery wrote:
>> Michael Stone writes:
>>> On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:
>>
This is the main reason I haven't switched to systemd timers for my
personal crontab, I h
Hi Chris
Am 18.07.19 um 04:07 schrieb Chris Lamb:
> It also has a first-class Ansible module which (given a flood of
> firewall options around when I needed to pick something in haste
> around the time of the stretch release…) was actually the deciding
> factor for me:
>
> https://docs.ansible.
Am 17.07.19 um 13:16 schrieb Michael Biebl:
> Am 17.07.19 um 13:04 schrieb Helmut Grohne:
>> On Tue, Jul 16, 2019 at 11:07:15AM +0200, Arturo Borrero Gonzalez wrote:
>>> Also, I believe the days of using a low level tool for directly configuring
>>> the
>>>
Am 17.07.19 um 13:04 schrieb Helmut Grohne:
> On Tue, Jul 16, 2019 at 11:07:15AM +0200, Arturo Borrero Gonzalez wrote:
>> Also, I believe the days of using a low level tool for directly configuring
>> the
>> firewall may be gone, at least for desktop use cases. It seems the industry
>> more
>> or
Am 08.07.19 um 22:04 schrieb Moritz Mühlenhoff:
> Theodore Ts'o schrieb:
>> Back in the days of boot/root installation floppies, saving every last
>> byte was clearly important.
>
> It's probably worth discussing/investigating whether udebs in general still
> make sense for d-i in 2019?
>
> It w
Am 07.07.19 um 15:43 schrieb Ben Hutchings:
> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote:
> [...]
>> No binary maintainer uploads for bullseye
>> =
>>
>> The release of buster also means the bullseye release cycle is about to
>> begin.
>> Fr
Am 14.06.19 um 22:51 schrieb Adam Borowski:
> Hi!
> Fedora has an awesome feature for packagers: scratch builds. It would be
> great if we could steal the idea.
>
> I find myself doing incremental uploads just to fix bugs that the previous
> upload revealed on some weird arch. At home, I can rea
Am 06.06.19 um 23:35 schrieb Julian Andres Klode:
> Hi folks,
>
> seeing that Federico Mena Quintero has taken over bzip2 development
> and is in the process of porting it to Rust[1], we should consider
> removing bzip2 support from apt, dpkg, etc. following the release
> of buster.
Reading https
Am 23.04.19 um 10:32 schrieb Michael Biebl:
> Am 22.04.19 um 03:11 schrieb Dmitry Smirnov:
>> Source: rsyslog
>> Version: 8.1901.0-1
>> Severity: wishlist
>>
>> https://www.rsyslog.com/doc/v8-stable/configuration/modules/mmdblookup.html
>>
>> Enabling &
Am 23.04.19 um 11:12 schrieb Michael Biebl:
> But splitting each tiny module into a separate package adds significant
> overhead packaging-wise.
(not to forget NEW round trips)
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from
Am 10.01.19 um 15:51 schrieb Stefan Fritsch:
> On Thu, 10 Jan 2019, Michael Biebl wrote:
>>> ACK, we also had to do the same in Grml[.org] and our latest release
>>> (2018.12). Now we automatically enable haveged when users boot using
>>> the ssh boot option (wh
Am 10.01.19 um 14:23 schrieb Michael Prokop:
> * Raphael Hertzog [Thu Jan 10, 2019 at 12:24:45PM +0100]:
>> On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote:
>
>>> Pointers, please? Let's see them and investigate. The primary issue
>>> I've been aware of to date has been on Fedora systems, and it's d
Am 19.11.18 um 15:55 schrieb Dirk Eddelbuettel:
>
>
> tl;dr: We may be messing up /bin and /usr/bin on some platforms
>
>
> Sorry for the alarming headline but #913982 was filed, indepedently
> corrobated and simultaneously discovered by upstream.
>
> GNU R has long been relying on sed, tar,
Am 15.11.18 um 01:14 schrieb Michael Biebl:
> Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
>> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
>
>>>> I don't have experience with archive management for non-release
>>>> architectures at all.
>
Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
>>> I don't have experience with archive management for non-release
>>> architectures at all.
>>
>> The problem that we have is that it's not possible to upload a package
>> to Debian which doe
On 13.11.18 13:37, Mattia Rizzolo wrote:
> No. It's a bug in your package, please fix it.
Please user-tag this bug report with
User: m...@linux.it
Usertags: usrmerge
This will allow us to better track [1] such issues.
Regards,
Michael
[1]
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=u
Am 04.11.18 um 20:30 schrieb Jeremy Bicha:
> On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings wrote:
>> I do like the proposal of adding a librsvg-c for just the architectures
>> that don't have Rust (yet).
>
> This sounds reasonable. Thanks Samuel for the suggestion. Any
> volunteers to maintain th
Am 25.10.18 um 09:44 schrieb Bas Couwenberg:
> On 2018-10-25 08:56, Yangfl wrote:
>> A potential fix for that might be replace the md5.h header with
>>
>> #define LIBMD_MD5_ALADDIN
>> #include
>>
>> remove building for md5.c, and add
>>
>> Build-Depends: libmd-dev (>= 1.0.1)
>
> That is not a sol
Am 16.10.18 um 22:24 schrieb Ian Jackson:
> Is this advocacy subthread really useful ? If we have bugs to report
> in systemd stuff we should report them in the BTS, not debate them on
> debian-devel.
>
> Adam Borowski writes ("Re: Debian Buster release to partially drop
> non-systemd support"):
Am 16.10.18 um 21:36 schrieb Adam Borowski:
> Systemd's algorithm for btrfs RAID is:
So your complaint is specific to btrfs RAID which afaik is still
considered unstable?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.
Am 16.10.18 um 09:57 schrieb Martin Steigerwald:
> 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
>> think they would fit in well in Debian's culture where they would
Am 26.09.2018 um 15:47 schrieb Jeremy Bicha:
> So is it appropriate to bump an epoch in Debian to match an important
> downstream's epoch?
I don't think it is.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Des
Am 26.09.2018 um 19:50 schrieb Holger Wansing:
> Hi,
>
> Debian testing autoremoval watch wrote:
>> installation-guide 20180603 is marked for autoremoval from testing on
>> 2018-10-11
>>
>> It is affected by these RC bugs:
>> 898665: installation-guide: [installation-guide] change "Alioth" and "
Am 24.09.18 um 19:19 schrieb Christoph Biedl:
> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.
So if other distros
Am 24.09.18 um 16:24 schrieb Sean Whitton:
> Hello,
>
> On Sun 23 Sep 2018 at 11:49PM +0200, Michael Biebl wrote:
>
>> Another idea could be to inform upstream of this situation. Maybe they
>> are willing to bump the version number from say 0.2 to 1.2
>
> Aurélien
Am 23.09.18 um 22:53 schrieb Aurélien COUDERC:
> FTP masters rejected the upload of the new elisa 0.2.1-1 as the package has a
> lower version than the former Elisa project
1.0.9+bzr1614-1.1 was the last version in the archive.
Not knowing how mature the new elisa project is, strictly speaking th
Am 18.09.18 um 12:00 schrieb Michael Biebl:
> I assume you (re)start your service in postinst? In this case you need a
> running systemd >= 235 at that point.
> We do re-exec systemd in postinst, but a versioned Breaks or Conflicts
> does not give you the guarantee that systemd.p
Am 18.09.18 um 09:21 schrieb Ondrej Novy:
> Hi,
>
> my package src:swift is not compatible with old systemd, because I'm
> using CacheDirectory in unit file. CacheDirectory is supported from
> systemd 235.
>
> I think correct solution is to add to binary package this relation:
> Breaks: systemd (
Am 06.08.2018 um 20:52 schrieb Josh Triplett:
> (Note that putting a line in your cron entry to exit if under systemd still
> means cron needs to go run that script and have it exit, which is not ideal.)
It's maybe not ideal but what I would suggest. The recommended way to
check whether systemd is
Hi
Am 29.07.2018 um 12:57 schrieb Lars Wirzenius:
> In September 2018, I will request that vmdebootstrap be removed from
> Debian. Please switch to a better tool now. From the NEWS file:
>
>vmdebootstrap is not going to be included in the release of Debian
>buster. Please switch to anothe
Am 19.04.2018 um 08:37 schrieb Andreas Tille:
> On Wed, Apr 18, 2018 at 09:52:18PM +0500, Andrey Rahmatullin wrote:
>> On Wed, Apr 18, 2018 at 04:00:51PM +0100, Ian Jackson wrote:
>>> Instead, tools grew to tolerate commas here rather than treat them as
>>> separators (because they would mishandle
Am 26.02.2018 um 10:29 schrieb Bastian Blank:
> Hi Michael
>
> On Mon, Feb 26, 2018 at 09:46:22AM +0100, Michael Meskes wrote:
>> do we have something like virtual entities for systemd service files? In SysV
>> we could require that mail-transport-agent was started before starting a
>> service. Bu
Am 25.02.2018 um 23:42 schrieb Don Armstrong:
> On Sun, 25 Feb 2018, Dimitri John Ledkov wrote:
>> A couple of conffiles were /etc/X11/Xsession.d/00upstart and
>> /etc/X11/Xsession.d/99upstart which assumed that upstart would be
>> alwasy be available, and in bionic after the above described update
Am 14.02.2018 um 14:31 schrieb Jeremy Bicha:
> On Wed, Feb 14, 2018 at 7:57 AM, Vincent Bernat wrote:
>> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>>
> Would it hurt to take those epoch bumps into Debian?
Depends on what you mean by hurt. I see epochs being used w/o much
>>>
Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
> On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> this will be true with X 1:1.6 as well.
> Or with 1.8+really1.6.
But this problem will fix itself (after
Am 03.02.2018 um 18:03 schrieb Andreas Schwarz:
> Package: wnpp
> Severity: wishlist
> Owner: Andreas Schwarz
>
> * Package name: lsmount
> Version : 0.2.1
> Upstream Author : Andreas Schwarz
> * URL : https://www.lsmount.org
> * License : ISC
> Programming
Am 31.01.2018 um 22:49 schrieb Don Armstrong:
> On Wed, 31 Jan 2018, Abou Al Montacir wrote:
>> Me too likes to extend the removal notice for few weeks/months.
>> Especially removal from testing when outside freeze periods.
>
> Packages removed from testing outside of the freeze can be easily
> re
Am 31.01.2018 um 20:14 schrieb Andrej Shadura:
> Hi everyone,
>
> It has happened to me in the recent years quite a few times that a
> package which I was using has a RoQA bug filed against it, and the
> package's got removed at a very short notice.
>
> For example, in #616376, gbdfed was removed
Am 06.01.2018 um 23:35 schrieb Adam Borowski:
> On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote:
>> On Jan 06, Simon Richter wrote:
>>
>>> As it is now, we have a lot of people who are maintaining their own
>>> packages outside of Debian. Can we get enough support to reintegrate
>>> b
Am 30.12.2017 um 14:27 schrieb Alex Mestiashvili:
> On 12/30/2017 01:46 PM, Michael Biebl wrote:
>> Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
>>
>>> There are some cases when using sysvinit is preferred over systemd.
>>> AFAIK there is no way drop some
Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
> There are some cases when using sysvinit is preferred over systemd.
> AFAIK there is no way drop some capabilities with systemd geared linux
> containers while it is possible with sysvinit.
It's the first time I hear about this. Can you please e
Am 01.12.2017 um 13:15 schrieb Arturo Borrero Gonzalez:
> On 1 December 2017 at 12:23, Michael Biebl wrote:
>> Am 01.12.2017 um 07:34 schrieb Paul Wise:
>>> On Fri, Dec 1, 2017 at 1:36 AM, Arturo Borrero Gonzalez wrote:
>>>> * no support for RW on NTFS drives, only
Am 01.12.2017 um 07:34 schrieb Paul Wise:
> On Fri, Dec 1, 2017 at 1:36 AM, Arturo Borrero Gonzalez wrote:
>
>> * no support for the wifi interface of the dekstop machine (this was
>> expected, fixed by installing non-free package by hand, since no
>> network)
>
> It would have been best for him
Am 22.11.2017 um 14:29 schrieb Paul Wise:
> On Wed, Nov 22, 2017 at 8:42 PM, Phil Wyett wrote:
>
>> In my honest opinion, rating certain content types within a package should be
>> done along the lines of PEGI[1]. A self regulatory rating done as part of a
>> social policy and administered by the
Am 21.10.2017 um 11:45 schrieb Christoph Biedl:
> Or: Introduce package namespaces, this is a big change. The existing
> flat model one with somewhat hundred thousand (wild guess) entries over
> the past 25 years worked quite well most of the time, although not
> always (git, node). But it's obvio
Am 03.10.2017 um 19:37 schrieb Felipe Sateler:
> I don't think that's necessary as init is Important: yes, and both
> systemd and sysvinit will have to gain a dep on e2fsprogs.
Why exactly? To fsck/mount ext234 file systems?
Keep in mind that sysvinit/systemd don't depend on xfsprogs, etc either.
Am 18.09.2017 um 18:00 schrieb Jonathan Carter (highvoltage):
> Well, it's not official yet of course but salsa.debian.org is running
> GitLab and it seems like the likely Alioth replacement.
Do I need to create a new user account for salsa.debian.org or can I use
my existing Debian account?
s
Am 12.07.2017 um 18:58 schrieb Matt Zagrabelny:
>
>
> On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl <mailto:bi...@debian.org>> wrote:
>
> Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > My finger memory will still type tcpdump -i eth0 before the brain c
Am 12.07.2017 um 20:40 schrieb Roger Lynn:
> On 10/07/17 19:40, Marvin Renich wrote:
>
>
>
>> There is an easy fix to revert the default behavior while still allowing
>> knowledgeable sysadmins to get the new behavior. On the other hand,
>> those who need to administer systems but are not sysad
Am 12.07.2017 um 17:35 schrieb Marc Haber:
> My finger memory will still type tcpdump -i eth0 before the brain can
> intervene ten years from now.
thankfully tcpdump (and lots of other tools) have nice shell completion.
tcpdump -i works great her.
--
Why is it that all of the instruments seeki
Am 11.07.2017 um 12:14 schrieb Guus Sliepen:
> Ok, it should be clear now that the new way of naming interfaces is not
> ideal, but the older ways weren't either. Let's have a look at what we
> want:
>
> - A simple name for systems with a single Ethernet and/or Wireless
> interface (the simple d
Am 01.07.2017 um 17:25 schrieb Sean Whitton:
> On Wed, Jun 28, 2017 at 06:34:01PM +0200, Michael Biebl wrote:
>> systemd provides a facility called systemd-sysusers which allows to
>> describe system user accounts declaratively. Maybe we could leverage that.
>>
>>
Am 27.06.2017 um 09:34 schrieb Niels Thykier:
> After this, we need something other than triggers. Triggers are great
> for regenerating global caches but they are not good at delegating
> targeted functionality out like:
>
> * This package needs user X to be created dynamically with home set
>
Am 24.06.2017 um 17:01 schrieb Simon McVittie:
> On Sat, 24 Jun 2017 at 16:04:32 +0200, Michael Biebl wrote:
>> Am 24.06.2017 um 15:09 schrieb Michael Gilbert:
>>> I entirely lost interest in the problem it was trying to solve when
>>> the init system "debate&q
Am 24.06.2017 um 15:09 schrieb Michael Gilbert:
> I entirely lost interest in the problem it was trying to solve when
> the init system "debate" concluded. It should be removed.
FYI, I've filed #865752 for that.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life
Am 23.06.2017 um 13:22 schrieb Colin Watson:
> --- a/init-select.cfg
> +++ b/init-select.cfg
> @@ -1,1 +1,1 @@
> -GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT
> $(/usr/lib/init-select/get-init)"
> +GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT $([ ! -x
> /usr/lib/init-select/
Am 06.06.2017 um 15:55 schrieb Adam Borowski:
> gvfs: atril easytag thunar
> * BAD: gvfs is a major annoyance and a security hole
"Annoys Adam Borowski" is not a very convincing argument.
As for "security hole", I'm not sure what exactly you have in mind
there. I don't see any open CVEs or bugs ta
Am 06.06.2017 um 18:06 schrieb Russ Allbery:
> Adam Borowski writes:
>> libpam-systemd: xfce4-power-manager xfce4-session
>> * BAD: Depends:systemd, utterly pointless without it.
>
> This is a whole other discussion, but we had *endless* discussions of
> this, and there are very sound technical
Am 10.04.2017 um 03:20 schrieb Sean Whitton:
> On Sun, Apr 09, 2017 at 11:53:54PM +0200, Martin Steigerwald wrote:
>> At least ublock origin is available as Debian package for Chromium (as well
>> as
>> Firefox) meanwhile. But in experimental only. And it appears to be the only
>> extension for C
Am 07.04.2017 um 01:07 schrieb Nikolaus Rath:
> Maybe I'm just exceedingly unlucky, but I have yet to find a laptop
> where all of the following works:
>
> - Suspend
> - Hibernate
> - Airplane-mode Hotkey (especially hard apparently)
> - Volume Hotkeys
> - Brightness Hotkeys
> - Suspend/hibernate
Am 25.03.2017 um 01:17 schrieb gregor herrmann:
> On Fri, 24 Mar 2017 23:09:37 +0100, Michael Biebl wrote:
>> Installing debhelper (+dependencies) takes about 5s here (on a 6 year
>> old laptop with SSD+eatmydata). Most of that time seems to be spent in
>> man-db's p
Am 24.03.2017 um 23:09 schrieb Michael Biebl:
> Installing debhelper (+dependencies) takes about 5s here (on a 6 year
> old laptop with SSD+eatmydata). Most of that time seems to be spent in
> man-db's postinst.
> # time apt install -y debhelper
> Reading package list
Am 24.03.2017 um 13:46 schrieb Adam Borowski:
> Hi!
> Thought I'd share a trick I'm using: as debhelper's dependencies chain became
> really fat, you can gain a drastic speed-up (especially for small packages)
> by preinstalling debhelper into your base sbuild/pbuilder/etc image.
Installing debhel
Am 09.03.2017 um 04:24 schrieb Russ Allbery:
> Adam Borowski writes:
>
>> I'd like to discuss (and then propose to -policy) the following rule:
>
>> # Libraries which don't provide a convenient means of conditionally loading
>> # at runtime (this includes most libraries for languages such as C),
Am 07.03.2017 um 23:11 schrieb Sean Whitton:
> On Tue, Mar 07, 2017 at 11:08:33PM +0100, Mattia Rizzolo wrote:
>> For as long as RoQA go, everybody is QA.
>
> Thanks.
If I see a package which looks unmaintained, is possibly RC buggy and
doesn't look like worth keeping in Debian, I've filed RoAQ R
101 - 200 of 755 matches
Mail list logo
