-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 14 May 2012 01:11:08 +0200
Source: netbase
Binary: netbase
Architecture: source all
Version: 5.0
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco d'Itri m...@linux.it
Description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 14 May 2012 02:45:06 +0200
Source: kmod
Binary: kmod module-init-tools libkmod2 libkmod-dev libkmod2-udeb
Architecture: source i386 all
Version: 8-1
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri m...@linux.it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 14 May 2012 05:17:39 +0200
Source: ifmail
Binary: ifmail ifgate ifcico
Architecture: source all i386
Version: 2.14tx8.10-21
Distribution: unstable
Urgency: low
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco d'Itri m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 14 May 2012 03:44:44 +0200
Source: libberkeleydb-perl
Binary: libberkeleydb-perl
Architecture: source i386
Version: 0.51-1
Distribution: unstable
Urgency: low
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco d'Itri m
On May 12, Adam Borowski kilob...@angband.pl wrote:
Thus, let's just switch dpkg-deb's default to xz. Lowering bandwidth usage
is worth the extra build time cost.
Agreed, this looks like a good idea.
--
ciao,
Marco
signature.asc
Description: Digital signature
On May 11, Nikolaus Rath nikol...@rath.org wrote:
Wrong: since you have to copy the whole file to override it, and files
in /lib have no conffiles handling, after an upgrade you will not know
what was changed by you and what was changed upstream.
I think everyone here agrees with that.
On May 11, Gergely Nagy alger...@balabit.hu wrote:
And in etc-overrides-lib, config files still remain in /etc. Its just
the defaults that live elsewhere. That the defaults are files, and are
under /lib, is an implementation detail, similarly how gconf defaults
live under
On May 11, Gergely Nagy alger...@balabit.hu wrote:
Long story short, I still don't see what the fuss is about.
Apparently the reason is that you do not understand the problem, since
you keep getting back to the not relevant issue of software which
supports placing configuration directives in
On May 11, Thomas Goirand z...@debian.org wrote:
Long story short, I still don't see what the fuss is about.
The fuss is about we're being told that there will be silent
overwriting of configuration files without being prompted about
changes, which potentially, will make it horrible to
On May 11, Michael Biebl bi...@debian.org wrote:
You can either copy the file or use the .include directive (which was
already mentioned) and only override the settings you need.
Not with udev or kmod.
The problem with etc-overrides-lib is that a file must be copied in
full from /lib to
On May 10, Bjørn Mork bj...@mork.no wrote:
Agree. Copying a large set of default policies into /etc just because
they *can* be overridden is not user friendly. And it does not make the
defaults any more configuration either. It just hides important local
changes and makes it difficult both
On May 10, Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org wrote:
There are cases where file in /etc overrides only the directives present
in /etc and not the rest. I prefer this way.
Fine, but they are not the cases which we are discussing.
--
ciao,
Marco
signature.asc
On May 09, Arto Jantunen vi...@debian.org wrote:
In addition to that it would be nice if everyone could agree to not work
against a certain init implementation (for example by refusing to
include the startup file for that init when someone else has written one
and submited it as a wishlist
On May 08, Gergely Nagy alger...@madhouse-project.org wrote:
but sometimes it is necessary to do unusual things in init scripts to
properly intregrate a service into the system. How to deal with that?
Write shell wrappers that are executed from systemd?
If absolutely neccessary, that is
On May 09, Tollef Fog Heen tfh...@err.no wrote:
This is something I'm pondering if we should handle in either a systemd
trigger or a tool that packages shipping systemd files can call to tell
the user about any changes. (Basically a wrapper around ucf, probably.)
The more I think about it,
On May 07, Ben Hutchings b...@decadent.org.uk wrote:
Means that services can be started (and stopped?) in response to events
such as hardware discovery, incoming network connections, the status of
other services, and so on. (With dependencies still taken into
account.)
I want to add another
On May 02, Debian Bug Tracking System ow...@bugs.debian.org wrote:
-Architecture: any
+Architecture: linux-any
Robert, don't you have anything better to do with your time than NMU'ing
other people's packages with cosmetic issues?
I obviously do not want to dictate how you should spend your
On May 04, Wookey woo...@wookware.org wrote:
That doesn't look cosmetic to me. That looks like an FTBFS fix for
kfreeBSD, which he gave you 5 months to do yourself before NMUing it.
Since the package did not work before and will not work after, I do not
consider this strictly a FTBFS bug.
--
On Apr 30, Thomas Goirand z...@debian.org wrote:
On 04/30/2012 05:25 AM, Marco d'Itri wrote:
This has been happening more and more after SuSE has become irrelevant.
What (or what time) are you talking about?
Has SuSE ever been relevant? :)
In this context it was, because it was the other
On Apr 29, Harald Jenny har...@a-little-linux-box.at wrote:
Wouldn't this solve the whole dilemma in a policy compliant and easy
enough fashion that it could be used or what error is there in my idea?
If fixing a real world problem requires so much overhead because of
policy concerns then it
On Apr 29, Russ Allbery r...@debian.org wrote:
desires. The disruption doesn't seem worth it even if we had consensus
What kind of disruption are you thinking about?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Apr 29, Harald Jenny har...@a-little-linux-box.at wrote:
Agreed but how long would it take to fix the policy vs how long would it
take to produce this package in the face of next stable release?
The current situation does not even cause any practical problems, just
a policy violation.
--
On Apr 29, Russ Allbery r...@debian.org wrote:
What kind of disruption are you thinking about?
Existing users who are familiar with Exim and who would get Postfix on a
new install and be surprised.
This does not really look like a big surprise.
If somebody is familiar enough with Exim to
On Apr 29, Russ Allbery r...@debian.org wrote:
The giant endless flamewars on debian-devel required to make a decision to
change anything. :)
Unrelated: you have just shown what poisons Debian and has been keeping
us behind innovation for the last years.
Not the flamewars themselves, most of
On Apr 29, Roger Leigh rle...@codelibre.net wrote:
I hope I'm not alone in feeling quite uneasy about the implications
of the above.
We can all be uneasy about it until we are blue in the face, but since
Red Hat maintains most Linux core components and we do not, there is not
much we can do
On Apr 29, Jonathan Nieder jrnie...@gmail.com wrote:
Red Hat employs some eminently friendly and reasonable people.
I am on friendly terms with many Red Hat people, but it is a fact that
they take design decisions which are aligned with the needs of RHEL
and these needs are often far from what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 30 Apr 2012 05:44:07 +0200
Source: whois
Binary: whois
Architecture: source i386
Version: 5.0.16
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco d'Itri m...@linux.it
Description
Is this the right time to do it?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Apr 25, Patrick Lauer patr...@gentoo.org wrote:
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
Not true. systemd and upstart do not make /everybody/ happy, but nothing
does.
I'd like to ask
On Apr 15, Daniel Baumann daniel.baum...@progress-technologies.net wrote:
packages should have a debconf question for the document root,
No, because this would require making every package significantly more
complex. Not just because of asking the question, but the configuration
files would
On Apr 09, Roger Leigh rle...@codelibre.net wrote:
majority, it's going to be increasingly untested. Do we want to
continue to maintain something that will be increasingly
unsupportable, or complete the migration cleanly before that point?
Kill it. With fire.
WRT actually doing this, the
On Apr 10, Russell Coker russ...@coker.com.au wrote:
The perils of commercial social networking are becoming more widely known, as
demonstrated by the above post by Charles Stross and the article he cites.
Actually I cannot see any reason why software exposing this kind of
issues could not
On Apr 02, Michael Welle mwe012...@gmx.net wrote:
In life I tend to look for role models above me, not below me. Why
imitate people or companies that do a bad job? We can do better. And of
course, to come back to my initial email, I doubt that using the
blacklist service makes anything easier
On Mar 31, Josselin Mouette j...@debian.org wrote:
I’ve not seen many people interested specifically in upstart in this
discussion, apart from Canonical employees.
I am interested in upstart and I am not a Canonical employee, but
I refrained from discussing which init system is better because
On Mar 22, Samuel Thibault sthiba...@debian.org wrote:
So you believe that systemd
Please let's not forget that this is not about systemd: we have not even
started yet the flame war to decide if we should use systemd or upstart.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Mar 22, Samuel Thibault sthiba...@debian.org wrote:
Because the issue at stake might lie in systemd itself, not the unit
file.
While obviously the C components of other init systems are bug free.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Mar 21, Svante Signell svante.sign...@telia.com wrote:
And how do you expect non-experts be able to solve problems when they
pop up. Buying consultant services from the experts?
Non-experts are not able to solve any problem, so this is not an issue.
--
ciao,
Marco
signature.asc
On Mar 21, Bernhard R. Link brl...@debian.org wrote:
Non-experts are not able to solve any problem, so this is not an issue.
I'm really fed up with this elitism.
I am fed up with other cathegories of people, but for some reason the
Debian listmasters requested that I do not discuss this here.
On Mar 21, Thomas Hood jdth...@gmail.com wrote:
The proposal to drop support for kernels other than Linux has already
been adequately aired. For the sake of focus I'd like to make the
assumption in this thread that support for alternative kernels and
architectures will not be dropped on
On Mar 17, Josselin Mouette j...@debian.org wrote:
I doubt that this is possible except for the most trivial cases (which
are not interesting), because the three init systems do not have the
same features and they have different semantics.
It is for trivial cases (90% of init scripts)
On Mar 16, Alexander Wirt formo...@debian.org wrote:
What attack? Toys are not evil, I like toys.
But an OS developed by 10 people for maybe 100 people is still a toy.
Yeah, like Linux too not so long ago. With people like you we would still
have to use Windows.
Predicting the future has
On Mar 17, Thomas Goirand z...@debian.org wrote:
Have you noticed that both myself and Phil Hands took the
decision to write a sysv init lib, to avoid code duplication?
That alone is a good thing, no?
It's not, because the goal should be to deprecate init scripts like
other distributions did.
On Mar 16, Lars Wirzenius l...@liw.fi wrote:
They have some technical and other differences, and have upstream
developers who can be considered controversial in various ways by
various people in Debian.
How are the upstart developers controversial? Did I miss something?
it yet. (As
On Mar 16, Marc Haber mh+debian-de...@zugschlus.de wrote:
On Fri, 16 Mar 2012 14:26:35 +0100, m...@linux.it (Marco d'Itri) wrote:
The problem is the lack of code for the toy ports,
It would really be nice if you could at least try to not plant
unnecessary attacks against people who have
On Mar 16, Vincent Danjean vdanjean...@free.fr wrote:
* We could try to define a file format that allow a conversion (by a
separate specific tool or at runtime) to various init systems.
This would avoid to be blocked by the syntax/features of one source
init system.
I doubt that this is
On Mar 15, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
Okay, I am not a DD,
This pretty much explains why you are not qualified to partecipate to
this discussion.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Mar 15, Martin Wuertele m...@debian.org wrote:
Let me quote section 4 first sentence of the social contract: We will
be guided by the needs of our users and the free software community..
This is correct, and it is why we should work to solve the problems of
the platform which has over 1000
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 Mar 2012 02:21:00 +0100
Source: kmod
Binary: kmod module-init-tools libkmod2 libkmod-dev libkmod2-udeb
Architecture: source i386 all
Version: 6-2
Distribution: unstable
Urgency: low
Maintainer: Marco d'Itri m...@linux.it
On Mar 06, Wouter Verhelst wou...@debian.org wrote:
Should Debian reject using any widely deployed and important system
component just to support toy ports which are used by a dozen of people?
Except that kFreeBSD is not a toy port.
FreeBSD is a serious operating system that is used by
On Mar 05, Marc Haber mh+debian-de...@zugschlus.de wrote:
Should Debian restrict itself to being a Linux platform just to have
systemd?
If it is worth it, yes.
Should Debian reject using any widely deployed and important system
component just to support toy ports which are used by a dozen of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 05 Mar 2012 22:56:19 +0100
Source: whois
Binary: whois
Architecture: source i386
Version: 5.0.15
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco d'Itri m...@linux.it
Description
On Mar 04, Goswin von Brederlow goswin-...@web.de wrote:
Also, why does refcounting have to be perfect?
What would break if it did not actually check that the two files
provided by the same package for different architectures are identical?
Everything that can go wrong when splitting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sat, 03 Mar 2012 16:53:33 +0100
Source: kmod
Binary: kmod module-init-tools libkmod2 libkmod-dev libkmod2-udeb
Architecture: source i386 all
Version: 6-1
Distribution: unstable
Urgency: low
Maintainer: Marco d'Itri m...@linux.it
On Mar 01, Russ Allbery r...@debian.org wrote:
The situation with refcounting seems much less fragile than the situation
without refcounting to me.
I totally agree.
Also, why does refcounting have to be perfect?
What would break if it did not actually check that the two files
provided by the
On Feb 29, Goswin von Brederlow goswin-...@web.de wrote:
Lets hope it is improving. But that only shows that depending on
controversial linux features should still be a concern.
Expect more of the same (IIRC in the next upload), because the udev
upstream maintainer likes to use modern kernel
On Feb 29, Russell Coker russ...@coker.com.au wrote:
One thing that would be really convenient in such situations is the ability
to
have the old and new versions of the package installed such that the new
version would run the old version if appropriate.
Yes. Except that this was not
On Feb 28, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
The Linux kernel project has some serious and ongoing structural
problems and I think it's very important that as a project we keep our
options open.
Even if I were willing to accept this argument as valid[1], it's worth
On Feb 28, Svante Signell svante.sign...@telia.com wrote:
means permanently tying ourselves to the Linux kernel.
Definitely, and this is not in line with Debian goals.
Says who?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Feb 28, Steve Langasek vor...@debian.org wrote:
Yes, that's probably a reasonable threshold. What should packages like
miredo and wide-dhcpv6-client do? Both of these hooks have to do with
Maybe they could stop pretending that the ifupdown configuration model
can properly support multiple
On Feb 26, Goswin von Brederlow goswin-...@web.de wrote:
By that reasonsing we should not support bsd, hurd, mips, arm, ppc,
ia64, s390 either. Hell lets drop i386 too.
Indeed. The reason we support niche architectures and toy ports is that
some people are interested in doing the work, and
On Feb 23, Bernhard R. Link brl...@debian.org wrote:
If two init system are too much to support, I'd suggest to stay with
the init working for everyone and not support systemd at all.
Not an option: we really need an events-based init system.
If you want legacy at all costs, I think that
On Feb 23, Russell Coker russ...@coker.com.au wrote:
What are the big costs of supporting other init systems?
Systemd supports /etc/init.d/* scripts and I believe that upstart does the
same.
The big cost is not in managing individual simple daemons, but in
everything else which you can
On Feb 23, Goswin von Brederlow goswin-...@web.de wrote:
Say you have a desktop system but also have apache, postgresql, ... for
some developement work installed. First thing you need when you turn it
on is your desktop. The apache and postgresql do not need to be running
for you to log in
On Feb 21, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
Please do not make udev mandatory. There are still refuseniks out
there and I can see why they make that choice.
Statistics show that they are not relevant.
Duplicating code paths has a cost, and it's big when one of them is
never
On Feb 21, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote:
The biggest disadvantage of systemd is surely that it is Linux-only and
probably won't work with other kernels in near future, so it's absolutely
desirable to support several init systems in Debian.
No, it's not. If we
On Feb 22, John D. Hendrickson and Sara Darnell johnandsa...@cox.net wrote:
Is init not a timeless thing unworthy to plot the removal of ?
No. We badly need an event-driven boot process, be it either upstart or
systemd.
--
ciao,
Marco
signature.asc
Description: Digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sun, 19 Feb 2012 13:07:21 +0100
Source: kmod
Binary: kmod module-init-tools libkmod2 libkmod-dev libkmod2-udeb
Architecture: source i386 all
Version: 5-2
Distribution: experimental
Urgency: high
Maintainer: Marco d'Itri m...@linux.it
On Feb 18, Roger Leigh rle...@codelibre.net wrote:
• There are currently two init scripts, hwclockfirst.sh and
hwclock.sh. The reasons for these two originally existing
Why do you still bother with init scripts? With very good approximation,
nowadays all systems which need hwclock (i.e. are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sun, 19 Feb 2012 01:42:27 +0100
Source: tcp-wrappers
Binary: tcpd libwrap0 libwrap0-dev
Architecture: source i386
Version: 7.6.q-23
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco
On Feb 13, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
The rule would be that if:
* A file is being opened in a sticky directory
* The file is going to be created by this operation
* O_EXCL was not specified
then the syscall fails with EPERM.
This should be easy to implement as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sun, 12 Feb 2012 04:48:24 +0100
Source: kmod
Binary: kmod module-init-tools libkmod2 libkmod-dev libkmod2-udeb
Architecture: source i386 all
Version: 5-1
Distribution: experimental
Urgency: low
Maintainer: Marco d'Itri m...@linux.it
As the maintainer of a few (popular) library packages I consider
splitting these packages a complex and annoying workaround for
deficiencies in tools.
It is not true that splitting the package is a one time action, every
release which adds new files will require dealing with the split.
Why was
On Feb 09, Steve Langasek vor...@debian.org wrote:
I think there are pretty solid benefits to proceeding with a dpkg that
allows sharing files across M-A: same packages.
Agreed. Fix the tools instead of breaking the standard to adapt to
broken tools.
Myself, I like the idea of the implicit
On Feb 07, Thomas Goirand z...@debian.org wrote:
Are you trying to make the point that, with containers,
you wouldn't need ssh, and you would with VMs? If so,
With *OpenVZ* I do not need sshd, ftpd and cron in the guest because
I can use the one in the host.
It's a custom environment, but I
On Feb 03, Bastian Blank wa...@debian.org wrote:
http://blog.bofh.it/debian/id_413
This example shows nothing new. If you have CAP_SYS_MOUNT, you can also
just mount the root filesystem into your own tree.
Linux-VServer does not help against processes with too much
capabilities, not sure
On Feb 02, Russell Coker russ...@coker.com.au wrote:
Are there many users who need root containment but who won't have the
resources to run Xen or KVM when the support for Squeeze ends?
Are there many users who like to waste resources (mostly RAM, here) for
no good reason?
--
ciao,
Marco
On Jan 30, Holger Levsen hol...@layer-acht.org wrote:
http://blog.bofh.it/debian/id_413
would you mind filing a bug about this?! Refering to your blog post is nice,
Yes, since the upstream maintainers do not consider this to be a bug.
--
ciao,
Marco
signature.asc
Description: Digital
On Jan 30, Adam Borowski kilob...@angband.pl wrote:
lxc wasn't anywhere near feature parity with vserver/openvz then.
And it still isn't.
It would be nice to have some documentation about how lxc is different from
them, and how to work around bugs and limitations. I for one spent ~10
Let's
On Jan 27, Wouter Verhelst wou...@debian.org wrote:
Do I understand you correctly that an empty configuration file in /etc
will override its 'full' equivalent in /usr? I.e., just an empty file
full of comments saying this is what you can do with this file will
break some things?
This is
On Jan 28, Philip Hands p...@hands.com wrote:
Marvelous -- I particularly like his Separate /usr has become
increasingly unsupported anyway. which reminds me of the argument for
Software Patents in Europe, which is that the EPO have been issuing
Software Patents in defiance of the law for
On Jan 20, Goswin von Brederlow goswin-...@web.de wrote:
But I guess the solution for this would be to have udev make /dev/r/usr
the real device and /dev/mapper/r-usr a symlink.
No, because udev does not creates/renames devices anymore.
(This makes devtmpfs mandatory, BTW.)
--
ciao,
Marco
On Jan 20, Henrique de Moraes Holschuh h...@debian.org wrote:
Marco, at which point did Debian userspace started requiring devtmpfs?
The next udev release.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Jan 13, Federico Di Gregorio f...@debian.org wrote:
Consiglio vivamente il laptop per i periodi di morta o per
lavoricchiare o sboronare sul tuo codice con qualcuno appena
incontrato.
Mhh... Con il telefono posso fare molto. :-)
Ma ammesso di portarlo, ci sono prese per tutti o bisogna
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sun, 08 Jan 2012 20:47:12 +0100
Source: kmod
Binary: kmod module-init-tools libkmod1 libkmod-dev libkmod1-udeb
Architecture: source all i386
Version: 3-1
Distribution: experimental
Urgency: low
Maintainer: Marco d'Itri m...@linux.it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 06 Jan 2012 15:04:11 +0100
Source: tin
Binary: tin
Architecture: source i386
Version: 1:2.1.0-1
Distribution: unstable
Urgency: low
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco d'Itri m...@linux.it
Description:
tin
Ci siete già stati e raccomandate di andarci?
Quest'anno qualcuno parte dall'Italia?
Non ci sono mai stato, sto pensando se andare.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Jan 03, Russ Allbery r...@debian.org wrote:
Yes. But it needs to actually be a co-maintainer, or it needs to be
someone who's offering to be a new upstream, not someone who is willing to
produce a one-time fix to the problem.
And we are not discussing a missing fix, but radically modifying
On Jan 03, Yaroslav Halchenko deb...@onerussian.com wrote:
just thought of it: another possible complication of this approach (mv
/usr/bin/screen /tmp/screen-4.0) might be -- tools depending on
screen (e.g. byobu) might be in the cold water if the default screen in
the PATH cannot do its
On Jan 03, Axel Beckert a...@debian.org wrote:
Thanks for the comment. Cc'ing the relevant bug again, as this is
crucial information when I work on fixing the bug.
If /tmp is noexec then the administrator mounted it this way and knows
about it. So if he is smart enought to mount /tmp noexec
On Jan 03, Edward Allcutt edw...@allcutt.me.uk wrote:
On Tue, 3 Jan 2012, Marco d'Itri wrote:
It does not matter, this is needed strictly for the time of the upgrade
process.
Just how short do you expect this to be? I'm sure many of us
dist-upgrade daily and (shock! horror!) don't reboot
On Jan 03, Didier Raboud o...@debian.org wrote:
3) In a screen-cleanup init script, test the inexistance of the flag and
the
existance of /usr/bin/screen-old; in that case, `rm` it.
(+ appropriate version and sanity checks, + idempotency)
This is bad, because to solve a possible 30
On Dec 31, Russ Allbery r...@debian.org wrote:
ACK. Sometimes upstreams doing really stange things (maybe because they
dont have any package management in mind), that should be fixed. If
upstream doesnt do those fixes, distros have to catch in.
Sometimes, I think Red Hat makes some of
On Jan 01, Riku Voipio riku.voi...@iki.fi wrote:
Would we really need that? If I understand correctly, the / to /usr will
merely mean that
People who want to have /usr on separate partition will need initramfs.
Correct.
It does not even mean that they would need to use initramfs-tools,
On Jan 02, Axel Beckert a...@debian.org wrote:
A) Add an option to screen so the screen client speaks the old
protocol to the running server protocol. This IMHO would be best
solution and one without a big impact. It's also something which
As long as the needed patch is simple. But if it
On Dec 30, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
Every package which will accept a configuration file in /etc should
ship such a file in /etc, even if it contains only comments. In this
This train has already passed and you lost it, sorry.
And where do you want to put the
On Dec 30, Sven Hoexter s...@timegate.de wrote:
due to demand by a coworker I've taken #625611 and started to prepare
a package for the exFAT fuse driver and the utils package.
Debian, as policy, ignores patents which are not being actively and
widely enforced.
So feel free to upload.
--
On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote:
I think that stephan is right here. Every package using files in /etc
It DOES NOT MATTER who is right, some upstreams have decided otherwise.
At least udev, systemd and next month module-init-tools do override the
configuration
On Dec 26, Russell Coker russ...@coker.com.au wrote:
For many of the things that can be done by loading a kernel module an
attacker
can achieve similar goals by replacing libc or by using ptrace to install
hostile code in a long-running process that runs as root.
Or load code in the kernel
On Dec 26, Thomas Goirand z...@debian.org wrote:
On 12/22/2011 07:19 PM, Philip Hands wrote:
I'm still yet to understand the significant upsides of this proposal
So far, the only upside that has been written here, if I understand
well, is less patches for upstream udev, which is important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 23 Dec 2011 23:55:47 +0100
Source: whois
Binary: whois
Architecture: source i386
Version: 5.0.14
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco d'Itri m...@linux.it
Description
901 - 1000 of 2882 matches
Mail list logo
