* Simon McVittie:
> - OK: any-i386, any-amd64
SSE2 is part of amd64 and i386, and has strict alignment requirements.
This is why stack alignment bugs in the toolchain are usually fatal.
(We still support SSE2-less i386 installations, I think, but some
libraries will use SSE2 when available.)
i38
2014-11-22 22:10 GMT+01:00 Simon McVittie :
> On 22/11/14 19:54, Matthias Klumpp wrote:
>> (Maybe systemd has smarter methods for that case which I don't know of)
>
> I think RequiresMountsFor is what you're looking for.
>
> ConditionFileExists is not the right thing here: the Condition* family
> m
Quoting Tollef Fog Heen (2014-11-22 21:52:10)
> ]] Jonas Smedegaard
>
>> Quoting Russ Allbery (2014-11-22 18:01:12)
>>> I also like the idea of not having ssh depend on all local file
>>> systems to be mounted. I think it's going to be pretty rare to have
>>> a system that has /lib and /etc mou
On Sat, Nov 22, 2014 at 10:37 PM, brian m. carlson
wrote:
> On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote:
>> * Henrique de Moraes Holschuh , 2014-11-21, 17:34:
>> >i386:
>> > __asm__("pushf\norl $0x4,(%esp)\npopf");
>>
>> It works! Actually, it works so well it makes puts("hell
Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg
* Package name: pprepair
Version : 0.0~20140611-c70373b
Upstream Author : Ken Arroyo Ohori Hugo Ledoux
Martijn Meijers
* URL : https://github.com/tudelft3d/pprepair
* License : GPL-3.0+ or Commercial
On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote:
> * Henrique de Moraes Holschuh , 2014-11-21, 17:34:
> >i386:
> > __asm__("pushf\norl $0x4,(%esp)\npopf");
>
> It works! Actually, it works so well it makes puts("hello world") die with
> SIGBUS. :-(
Yeah, that's my experience, too
On 22/11/14 19:54, Matthias Klumpp wrote:
> (Maybe systemd has smarter methods for that case which I don't know of)
I think RequiresMountsFor is what you're looking for.
ConditionFileExists is not the right thing here: the Condition* family
more or less means "if the condition is absent, behave a
]] Jonas Smedegaard
> Quoting Russ Allbery (2014-11-22 18:01:12)
> > I also like the idea of not having ssh depend on all local file
> > systems to be mounted. I think it's going to be pretty rare to have a
> > system that has /lib and /etc mounted but can't start ssh. In theory,
> > that's
* Henrique de Moraes Holschuh , 2014-11-21, 17:34:
i386:
__asm__("pushf\norl $0x4,(%esp)\npopf");
It works! Actually, it works so well it makes puts("hello world") die
with SIGBUS. :-(
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Sat, Nov 22, 2014 at 07:17:55PM +, Simon McVittie wrote:
> If sshd uses (or can be made to use) IP_FREEBIND to remove the potential
> dependency on bringing up network interfaces, then
> /lib/systemd/system/ssh.service could have DefaultDependencies=no,
> RequiresMountsFor=/usr /lib /etc, a
2014-11-22 20:30 GMT+01:00 Russ Allbery :
> Jonas Smedegaard writes:
>> Quoting Russ Allbery (2014-11-22 18:01:12)
>
>>> I also like the idea of not having ssh depend on all local file systems
>>> to be mounted. I think it's going to be pretty rare to have a system
>>> that has /lib and /etc moun
Jonas Smedegaard writes:
> Quoting Russ Allbery (2014-11-22 18:01:12)
>> I also like the idea of not having ssh depend on all local file systems
>> to be mounted. I think it's going to be pretty rare to have a system
>> that has /lib and /etc mounted but can't start ssh. In theory, that's
>> po
On 22/11/14 17:01, Russ Allbery wrote:
> I think it's going to be pretty rare to have a system that
> has /lib and /etc mounted but can't start ssh. In theory, that's possible
> with a split / and /usr, but as we've discussed in other threads, that's
> an extremely unusual configuration these days
Quoting Russ Allbery (2014-11-22 18:01:12)
> I also like the idea of not having ssh depend on all local file
> systems to be mounted. I think it's going to be pretty rare to have a
> system that has /lib and /etc mounted but can't start ssh. In theory,
> that's possible with a split / and /usr
The Wanderer writes:
> On 11/22/2014 at 03:44 AM, Philip Hands wrote:
>
>> Hi Simon,
>>
>> Thanks for the explanation -- all makes a lot more sense now.
>>
>> I'm much less tempted to rant about how large chunks of /lib should
>> be moved to /etc (which is very good, because I don't suppose I'd
Adam Borowski writes:
> There's currently no way to express which mounts are needed for which
> functionality.
While that's true, I'm not sure that fine-grained control of this is
required here. We can get a long way with just a way to indicate whether
a mount is important or unimportant. And
On Saturday, November 22, 2014 05:06:25 PM Jakub Wilk wrote:
> * Wouter Verhelst , 2014-11-22, 08:25:
> >>It appears that the appropriate resolution of #769106 [1] is to add a
> >>new pre-depends on python-minimal in python.
> >>
> >>This issue at hand is that at the time python2.7-minimal is
> >>
* Wouter Verhelst , 2014-11-22, 08:25:
It appears that the appropriate resolution of #769106 [1] is to add a
new pre-depends on python-minimal in python.
This issue at hand is that at the time python2.7-minimal is
configured, python is unpacked, but python-minimal is not. Since
python-2.7-m
There's no limit on age, but an FTBFS is a serious bug; there are
regular automated checks for this (e.g. https://bugs.debian.org/768691
), but manual reports are also welcome.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact l
Hi,
Troy Benjegerdes:
> How hard would it be to add hooks/helpers to dpkg-buildpackage to know how
> to deal with git and mercurial repositories, and deterministically generate
> the 'source' tar.gz from the repo?
>
Exactly: Get source by adding a vcs-git-commit: field which points to the
sources
On Sat, 22 Nov 2014 16:19:10 +0100
Svante Signell wrote:
> Hello,
>
> I wonder how old a package build can be to be part of the release.
> Some packages are built up to a year ago, and rebuilding them now
> FTBFS. What to do, file a bug or accept status quo?
>
> Thanks!
In summary: Everything
Hello,
I wonder how old a package build can be to be part of the release. Some
packages are built up to a year ago, and rebuilding them now FTBFS. What
to do, file a bug or accept status quo?
Thanks!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscri
On Fri, Nov 21, 2014 at 10:25:43AM +0100, Matthias Urlichs wrote:
> Hi,
>
> Russell Stuart:
> > Admittedly this meshes well with my experience that they are often
> > fairly lax about what they put in those tarballs. Their "make
> > distclean" scripts are often not as good as they could be
>
> O
Package: wnpp
Severity: wishlist
Owner: Rolf Leggewie
* Package name: libfte
Version : 0.1.0
Upstream Author : Kevin P Dyer
* URL : http://fteproxy.org
* License : GPL
Programming Lang: Python
Description : encryption library to thwart deep packet insp
Hi,
Adam Borowski:
> * systemd: in preinst, check if any fstab lines without noauto or nofail
> are not currently mounted -- if so, abort the installation as it would
> result in an unbootable system.
>
In theory, sshd could start much earlier.
Right now it (indirectly) depends on networking
Hi,
Norbert Preining:
> > > Is there *any* way to *force* systemd to start lightdm ...?
>
Booting with "systemd.unit=lightdm.service" should work,
at least if its dependencies are set up correctly.
(Disclaimer: I didn't test that.)
Alternately you can boot with "systemd.unit=multi-user.target",
On Fri, Nov 21, 2014 at 05:51:47PM -0800, Russ Allbery wrote:
> As I understand it, sysvinit didn't care whether mountall.sh succeeded or
> failed.
This doesn't come from ignorance.
What can you do in this situation?
* throw your hands up, abort booting. Hope the admin enjoys a drive to
the d
On 11/22/2014 at 03:44 AM, Philip Hands wrote:
> Hi Simon,
>
> Thanks for the explanation -- all makes a lot more sense now.
>
> I'm much less tempted to rant about how large chunks of /lib should
> be moved to /etc (which is very good, because I don't suppose I'd be
> the first to suggest it ;-
On Sun, Nov 02, 2014 at 12:37:06PM +0100, Ralf Jung wrote:
> Hi,
>
> >>> - Debian should ship a default set of firewall rules. Are we the only
> >>> distro which doesn't do this? I mean a basic ruleset which drops
> >>> incoming, accepts outgoing and accepts related,establised is so easy to
> >>>
Hi Simon,
Thanks for the explanation -- all makes a lot more sense now.
I'm much less tempted to rant about how large chunks of /lib should be
moved to /etc (which is very good, because I don't suppose I'd be the
first to suggest it ;-) )
Simon McVittie writes:
> On 21/11/14 17:07, Philip Hand
Matthias Urlichs writes:
> Hi,
>
> Philip Hands:
>> Is there any way this isn't going to be an enormous surprise to people
>> that are used to the way that Debian usually treats /etc?
>>
> Well, instead of "edit /etc/default/FOO and search for the flag to disable
> the daemon" or the programmati
31 matches
Mail list logo
