Package: wnpp
Severity: wishlist
Owner: Birger Schacht
X-Debbugs-Cc: debian-devel@lists.debian.org, bir...@debian.org
* Package name: fyi
Version : 1.0.1
Upstream Contact: Daniel Eklöf
* URL : https://codeberg.org/dnkl/fyi
* License : MIT
Programming Lang
On 03/03/19 17:59, Kurt Roeckx wrote:
> I think the only sane things are:
> - Use a hardware RNG (CPU, TPM, chaos key, ...)
> - Credit a seed file stored during the previous boot
> - Wait for new entropy from other sources
>
> Note that is can be a combination of all 3.
>
> We currently do not cr
On Sun, 2019-03-03 at 22:55 +0100, Kurt Roeckx wrote:
> On Sun, Mar 03, 2019 at 08:19:44PM +, Ben Hutchings wrote:
> > On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
> > [...]
> > > Most people will actually have at least 2 hardware RNGs: One in
> > > the CPU and one in the TPM. We can m
On Sun, Mar 03, 2019 at 08:19:44PM +, Ben Hutchings wrote:
> On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
> [...]
> > Most people will actually have at least 2 hardware RNGs: One in
> > the CPU and one in the TPM. We can make the kernel trust those as
> > entropy source without using s
On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
[...]
> Most people will actually have at least 2 hardware RNGs: One in
> the CPU and one in the TPM. We can make the kernel trust those as
> entropy source without using something in userspace to feed it.
> I'm not sure in the kernel has the op
I think the only sane things are:
- Use a hardware RNG (CPU, TPM, chaos key, ...)
- Credit a seed file stored during the previous boot
- Wait for new entropy from other sources
Note that is can be a combination of all 3.
We currently do not credit the seed file, for various good
reasons. We shoul
]] Thorsten Glaser
> … this was not true for me. Not before init takes over, anyway (as
> haveged does not have any initramfs integration), but we’re talking
> about “crng init done” here, not “fast init done”. In my scenario,
> haveged was started much too late in the boot to be useful (after
>
> "Thorsten" == Thorsten Glaser writes:
Thorsten> It’s not about what we feed to the kernel, but about the
Thorsten> property of it distributing the input evenly across the
Thorsten> output. The basic tenet here is that, if I have 128 bytes
Thorsten> of random input from the s
Ben Hutchings dixit:
>On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
>>Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
>>> • during postinst, creates a 128-byte random seed file in /
>>
>>Can you confirm that this is done with data from
&
Sebastian Andrzej Siewior dixit:
>so I have one older box that suffers from that. I installed haveged and
>seemed to went away:
I tried that, after the suggestion to use haveged went up, but…
>As far as I understand, it would reach the "init done" state before
>systemd took over, right?
… this
> "Ben" == Ben Hutchings writes:
>> If the seed > files used in two different boots are somewhat
>> correlated, and the > entropy estimation doesn't account for
>> that, the output of /dev/random > may also be somewhat correlated
>> between the boots, which is not > supposed t
On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
[...]
> > to initialise a stretching RNG (arc4random)
>
> Why are you feeding this through a separate hashing function rather
> than letting the kernel PRNG's hasher do it ? I am seriously
> unconvinced that arc4random is a good idea her
On Thu, 2019-02-28 at 11:56 +, Ian Jackson wrote:
> Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> > On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > > Generally you don't ever
> > > need to use /dev/random instead of /dev/urand
Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
> • during postinst, creates a 128-byte random seed file in /
Can you confirm that this is done with data from
getrandom(,,GRND_RANDOM) ? (Presumably with GRND_NONBLOCK too.)
> – after the root filesystem is read-writ
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
>> Ben Hutchings writes: >[Someone:] >> The
>> additional entropy gathered is for extra safety; it is not >>
Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > Generally you don't ever
> > need to use /dev/random instead of /dev/urandom unless you make
> > assumptions about cryptography failing.
>
Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
> Ben Hutchings writes:
> >[Someone:]
> >> The additional entropy gathered is for extra safety; it is not
> >> *depended* on for basic security assumptions.
> > [...]
> It is, because the the
> "Ben" == Ben Hutchings writes:
>> The additional entropy gathered is for extra safety; it is not
>> *depended* on for basic security assumptions.
Ben> [...]
Ben> It is, because the the kernel is told to treat it as providing
Ben> a certain number of bits of entropy.
I
On Tue, 2019-02-26 at 22:29 +0200, Uoti Urpala wrote:
> On Tue, 2019-02-26 at 19:10 +, Ben Hutchings wrote:
> > But if the input to the seed doesn't provide enough entropy, the seed
> > is not completely secret (that is, you can recover it with less work
> > than a brute force search). The ext
On Mon, 2019-02-25 at 14:36 -0500, Sam Hartman wrote:
> > > > > > "Ben" == Ben Hutchings writes:
>
> Ben> The output of the RNG may well become public, for example in
> Ben> document UUIDs. So when estimating the entropy that the new
> Ben> seed file will provide for the next boot, n
> "Ben" == Ben Hutchings writes:
Ben> The output of the RNG may well become public, for example in
Ben> document UUIDs. So when estimating the entropy that the new
Ben> seed file will provide for the next boot, none of the entropy
Ben> in the old seed file should be credited.
On 2019-02-24 19:52:59 [+], Thorsten Glaser wrote:
> tl;dr: it adds entropy during initramfs/as early as possible during
> boot *and* tells the kernel it did so, to make its crng initialised,
> and ensures a subsequent boot has a different seed, also updated
> periodically and on shutdown for a
On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
[...]
> Generally you don't ever
> need to use /dev/random instead of /dev/urandom unless you make
> assumptions about cryptography failing.
[...]
I think I agree with that, but there is no way to add entropy that
unblocks getrandom() without a
On Mon, 2019-02-25 at 16:48 +, Thorsten Glaser wrote:
> Ben Hutchings dixit:
>
> >> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
> >> accredit them yet, just remembers the amount written)
> >
> >How do you determine the number of bytes here?
>
> 32 + arc4random_un
Ben Hutchings dixit:
>> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
>> accredit them yet, just remembers the amount written)
>
>How do you determine the number of bytes here?
32 + arc4random_uniform(256 - 32 + 1)
[…]
>The major input into the new seed file contents
On Mon, 2019-02-25 at 18:27 +0200, Uoti Urpala wrote:
> Ben Hutchings wrote:
> > The major input into the new seed file contents is the old seed file
> > contents. You are adding very little entropy on x86, and possibly
> > almost none on other architectures.
> >
> > Please reconsider this, as th
On Mon, Feb 25, 2019 at 03:53:09PM +, Ben Hutchings wrote:
The major input into the new seed file contents is the old seed file
contents.
Yes, I'd just drop the seed file once used, then have a scheduled job
write a new one at some point in the future if the random quality is
high enough.
On Sun, 2019-02-24 at 19:52 +, Thorsten Glaser wrote:
[...]
> I’ve written something, a linux-any package, that…
>
> • during postinst, creates a 128-byte random seed file in /
> • updates that in a daily cronjob (using same tool as during
> boot except with more bits taken from the kernel)
On Sun, 2019-02-24 at 20:10 +, Thorsten Glaser wrote:
> Hi Philipp,
>
> >FTR this is supposedly fixed on the main architectures featuring an
> RNG
> >in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which
> Ben
>
> that’s what I referred to by…
>
> >>• it does not use/add CPU R
On 24/02/2019 20:00, Philipp Kern wrote:
On 2/24/2019 8:52 PM, Thorsten Glaser wrote:
In buster/sid, I noticed a massive delay booting up my laptop
and some virtual machines, which was reduced by hitting the
Shift and Ctrl keys multiple times randomly during boot; a
message “random: crng init
Uoti Urpala dixit:
>entropy to be secure. Consider the following scenario:
>
>Daemon
There are no daemons running at that time. This is run in
initramfs, just after the root filesystem has been mounted,
with no background tasks save udev running, and network has
not been set up (unless NFS or dro
Hi Philipp,
>FTR this is supposedly fixed on the main architectures featuring an RNG
>in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which Ben
that’s what I referred to by…
>>• it does not use/add CPU RNG output where present
>> ‣ though Linux can now do that itself, some comman
On 2/24/2019 8:52 PM, Thorsten Glaser wrote:
> In buster/sid, I noticed a massive delay booting up my laptop
> and some virtual machines, which was reduced by hitting the
> Shift and Ctrl keys multiple times randomly during boot; a
> message “random: crng init done” would appear, and boot would
> c
Hello fellow developers (and some users),
I would like to present a recent (this week) project of mine.
Background story:
In buster/sid, I noticed a massive delay booting up my laptop
and some virtual machines, which was reduced by hitting the
Shift and Ctrl keys multiple times randomly during bo
Hi,
Just FYI, as RHEL8beta release note says(*) "Python 2.7 is available in
the python2 package. However, Python 2 will have a shorter life cycle and
its aim is to facilitate smoother transition to Python 3 for customers".
I'm not sure but if we would ship python2.7 in bu
On Wed, 2013-03-13 at 10:27 +0800, Paul Wise wrote:
> On Wed, Mar 13, 2013 at 10:13 AM, Hideki Yamane wrote:
>
> > Okay, but they are using patched gcc and binutils for build it.
> > So I guess, first it should be merged to upstream gcc/binutils, then
> > be added to firmware git repo, right?
>
On Wed, Mar 13, 2013 at 10:13 AM, Hideki Yamane wrote:
> Okay, but they are using patched gcc and binutils for build it.
> So I guess, first it should be merged to upstream gcc/binutils, then
> be added to firmware git repo, right?
No, that is not how the firmware-free source package works. It
On Wed, 2013-03-13 at 11:13 +0900, Hideki Yamane wrote:
> On Tue, 12 Mar 2013 19:15:20 +
> Ben Hutchings wrote:
> > This should be added to the linux-firmware.git repository and then to
> > our firmware-free source package. Perhaps you could talk to the
> > Atheros developers and you or they
On Tue, 12 Mar 2013 19:15:20 +
Ben Hutchings wrote:
> This should be added to the linux-firmware.git repository and then to
> our firmware-free source package. Perhaps you could talk to the
> Atheros developers and you or they could prepare a patch for
> linux-firmware.git? I recently added
On Tue, Mar 12, 2013 at 11:48:44PM +0900, Hideki Yamane wrote:
> Hi,
>
> One of my floss friend noticed to me that phoronix reports "Atheros
> Publishes Open-Source WiFi Firmware"
> http://www.phoronix.com/scan.php?page=news_item&px=MTMyNTY
>
> Source is https://github.com/qca/open-ath9k-htc
Hi,
One of my floss friend noticed to me that phoronix reports "Atheros
Publishes Open-Source WiFi Firmware"
http://www.phoronix.com/scan.php?page=news_item&px=MTMyNTY
Source is https://github.com/qca/open-ath9k-htc-firmware and its license
seems to be DFSG-free one.
Now Debian provides i
sorry for the noise.. wrong list due to address auto-completion failure.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503e2131.6020...@netstyle.ch
folgende aenderungen werden in kuerze deployed..
commit e8a6bbdf2efc0ed75058f53e72d8f202f3f0ac27
Author: Daniel Baumann
Date: Wed Aug 29 14:00:38 2012 +0200
Removing hazardous alias of 'ls -la' on '.', this is dangerous,
don't do such things.
commit f715801507bbc2781b771dd732636aaa1222
On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
> After some discussion on how the actual links should be presented so
> that uscan can find them while still keeping the desired UI
> behaviour, the links are now back in and the DEHS data
> for projects hosted on code.google.com should soon be
On Fri, Sep 03, 2010 at 10:02:15PM +0200, David Paleino wrote:
> On Fri, 3 Sep 2010 21:37:21 +0200, Iustin Pop wrote:
>
> > On Fri, Sep 03, 2010 at 09:10:02PM +0200, David Paleino wrote:
> > > On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
> > >
> > > > After some discussion on how the actu
On Fri, 3 Sep 2010 21:37:21 +0200, Iustin Pop wrote:
> On Fri, Sep 03, 2010 at 09:10:02PM +0200, David Paleino wrote:
> > On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
> >
> > > After some discussion on how the actual links should be presented so
> > > that uscan can find them while still
On Fri, Sep 03, 2010 at 09:10:02PM +0200, David Paleino wrote:
> On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
>
> > After some discussion on how the actual links should be presented so
> > that uscan can find them while still keeping the desired UI behaviour,
> > the links are now back in
On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
> After some discussion on how the actual links should be presented so
> that uscan can find them while still keeping the desired UI behaviour,
> the links are now back in and the DEHS data for projects
> hosted on code.google.com should soon b
On Fri, Sep 03, 2010 at 08:12:28PM +0200, Iustin Pop wrote:
> After some discussion on how the actual links should be presented so
> that uscan can find them while still keeping the desired UI behaviour,
> the links are now back in and the DEHS data for projects
> hosted on code.google.com should
Hi all,
[resend since my original mail from Aug 26th got lost]
As promised during Debconf, I went and talked with the code.google.com
people about the changes to the download list which broke uscan. For the
record, the rationale for the changes was (quoted with permission):
> Background: We used
On Wed, May 13, 2009 at 01:58:12AM +0200, Goswin von Brederlow wrote:
> Osamu Aoki writes:
>
> > Hi,
> >
> > When my usual web page updates failed, I was checking my ethernet
> > connection ... I wondered why ... Here is the reason:
> >
> > I might have missed some announcment, ... but it seems
Osamu Aoki writes:
> Hi,
>
> When my usual web page updates failed, I was checking my ethernet
> connection ... I wondered why ... Here is the reason:
>
> I might have missed some announcment, ... but it seems rsync on
> people.debian.org creates directories and files with 700 permission.
> This
Hi,
When my usual web page updates failed, I was checking my ethernet
connection ... I wondered why ... Here is the reason:
I might have missed some announcment, ... but it seems rsync on
people.debian.org creates directories and files with 700 permission.
This is new behavior. If you are synch
On Thu, May 22, 2008 at 12:31:09PM -0400, Felipe Sateler wrote:
> Osamu Aoki wrote:
>
> > Then you are voting for mercurial if you participated in popcon.
> >
> > vote: number of people who use this package regularly;
>
> Note that the vote is not that reliable either: it needs atime, which is
Hi,
On Fri, May 23, 2008 at 02:05:14PM +1000, Brian May wrote:
> Osamu Aoki wrote:
>> Shorter summary of vote data goes as:
>>
>> cvs 5%
>> subversion9%
>> git-core 3%
>> mercurial 0.6%
>> darcs 0.3%
>> bzr 0.3%
>>
> Does monotone not get a mention? or w
Osamu Aoki wrote:
Shorter summary of vote data goes as:
cvs 5%
subversion9%
git-core 3%
mercurial 0.6%
darcs 0.3%
bzr 0.3%
Does monotone not get a mention? or was monotone missed?
Brian May
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
Osamu Aoki wrote:
> Then you are voting for mercurial if you participated in popcon.
>
> vote: number of people who use this package regularly;
Note that the vote is not that reliable either: it needs atime, which is getting
less and less used.
--
Felipe Sateler
--
To UNSUBSCRIBE, email
On Thu, May 22, 2008 at 01:15:18AM +0900, Osamu Aoki wrote:
> One of the most interesting thing I noticed by doing this was change in
> popularity of VCS. (Just 1/2 year r so).
Readers of this thread might be interested in the popularity of VCS used
to _maintain_ Debian packages. Since a few days
* Osamu Aoki <[EMAIL PROTECTED]> [080522 14:36]:
> The large "installed" with low "vote" may be indication that people has
> found some new good alternative for a popular tool of yesterday.
>(RCS -> DVCS such as git, mercurial, ...)
I think this is only a part of an explanation and more suitea
Hi,
I did not mean to say that VCS in low numbers are unpopular. Instead, my
message should be understood as there are many popular VCSs and
popularity of use is moving.
On Wed, May 21, 2008 at 10:27:40PM +0200, Michal Čihař wrote:
> Dne Wed, 21 May 2008 15:10:14 -0500
> Steve Greenland <[EMAIL
Steve Greenland <[EMAIL PROTECTED]> writes:
> FWIW, and I'm not sure it actually conflicts or invalidates or even
> causes questions of the popcon data, but installs, at least, may not
> mean that much. On my main home box, several years old now, I've got
> all of cvs, svn, rcs[1], mercurial, git,
Dne Wed, 21 May 2008 15:10:14 -0500
Steve Greenland <[EMAIL PROTECTED]> napsal(a):
> FWIW, and I'm not sure it actually conflicts or invalidates or even
> causes questions of the popcon data, but installs, at least, may not
> mean that much. On my main home box, several years old now, I've got all
On Wed, May 21, 2008 at 03:10:14PM -0500, Steve Greenland wrote:
> On 21-May-08, 11:15 (CDT), Osamu Aoki <[EMAIL PROTECTED]> wrote:
> > Hi, (Composed as UTF-8 mail with graphic characters)
> >
> > I have been trying to update debian reference. As a part of this
> > effort, I made snapshot of pop
On 21-May-08, 11:15 (CDT), Osamu Aoki <[EMAIL PROTECTED]> wrote:
> Hi, (Composed as UTF-8 mail with graphic characters)
>
> I have been trying to update debian reference. As a part of this
> effort, I made snapshot of popularity of packages.
>
> One of the most interesting thing I noticed by do
Hi, (Composed as UTF-8 mail with graphic characters)
I have been trying to update debian reference. As a part of this
effort, I made snapshot of popularity of packages.
One of the most interesting thing I noticed by doing this was change in
popularity of VCS. (Just 1/2 year r so).
When I start
Hi fellow Debian people,
noticing all the recent discussions about sourcev2/v3, git.tar.gz,
and other VCS-related stuff, I thought I could get away with
dropping a quick pointer to http://vcs-pkg.org, which I hope can
become a central resource for the topics we're discussing.
Also, if you would c
Hello All,
I went through the whole set of failing builds for mips, fixed some
bugs and had at least a cursory look at each package. The result is
the rather terse list I append here.
Thiemo
Debian mips port, buildability status 2007-11-03. See also:
http://buildd.debian.org/~jeroen/status/arc
Hi interested parties,
> On 26-Apr-2007 15:24.21 (BST), Stephan Suerken wrote:
> > Generally speaking about packaging, my intend was to drop "uae" in
> > favour of "e-uae" in post-etch, and I would also like a practical
> > setup to allow group-maintaining (considering the time restrictions
>
* Jay Berkenbilt ([EMAIL PROTECTED]) wrote:
>
> For the small handful of people use dxpc (differential X protocol
> compressor, a useful tool for running X over slow network connections
> even including dialup), you should be aware that I have just uploaded
> 3.9.0-1 to sid. Version 3.9.0 is not
For the small handful of people use dxpc (differential X protocol
compressor, a useful tool for running X over slow network connections
even including dialup), you should be aware that I have just uploaded
3.9.0-1 to sid. Version 3.9.0 is not runtime compatible with older
versions of because of n
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Goswin von Brederlow:
>
>> Mirror size per arch (in MiB):
>>
>> | sarge | etch | sid | all
>> -+---+--+---+---
>> source | 9339 | 9419 | 11495 | 30252
>
> This looks suspicious. I expected that the total number
* Goswin von Brederlow:
> Mirror size per arch (in MiB):
>
> | sarge | etch | sid | all
> -+---+--+---+---
> source | 9339 | 9419 | 11495 | 30252
This looks suspicious. I expected that the total number would be
significantly less than the sum of the suites
Hi,
I got a bugreport requesting exected mirror sizes to be added to the
debmirror documentation and I thought some of you might be intrested
in them too. So heres the stats:
Mirror size for a singe arch and binary only (in MiB):
| sarge | etch | sid | all
-+---+--+--
Would anybody at Debian be interested to discuss my lmbench results attached
below (comparing "vanilla" Linux 2.6..8-rc4 kernel with and without "kernel
preemption" option running on PQ2FADS-VR with MPC 8275) ?
Thanks
> -Original Message-
> From: Povolotsky, Alexander
> Sent: S
Karl M. Hegbloom said on Tue, Jul 22, 2003 at 02:01:19AM -0700:
> http://www.infrastructures.org/papers/bootstrap/bootstrap.html
While this is a good paper, and there are lots of interesting ideas contained
within it that map well to Debian (I've got 50 or so Debian boxes in a
configuration inspir
http://www.infrastructures.org/papers/bootstrap/bootstrap.html
--
Karl M. Hegbloom <[EMAIL PROTECTED]>
Hi,
SDL_ttf's current maintainer is no longer interested in it and
doesn't mind giving it away.
In addition, version 2 has been released for some time now.
Cheers,
--
Jérôme Marant
http://marant.org
On Tue, 24 Apr 2001 05:30:18 -0800, Ethan Benson <[EMAIL PROTECTED]> wrote:
> > [ -x install-upx ] && install-upx /usr/bin/foo /usr/bin/bar
> >
> > to her postinst or
>
> fine
>
> > dh_upx
> >
> > to her rules.
>
> NO! this would absolutly suck. that leaves the admin in the position
> to
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Itai Zukerman wrote:
>
> It seems to me that each maintainer should make the decision of
> whether she wants UPX to apply to any of her binaries. And the
> easiest way to do that, IMO, is to have her add
>
> [ -x install-upx ] && install-upx /usr/bin/f
On Tue, Apr 24, 2001 at 01:14:36PM +0100, Colin Watson wrote:
> Ethan Benson <[EMAIL PROTECTED]> wrote:
> >On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
> >> you want. The postinst code would call the compression routines,
> >> which might not do anything, depending on how the com
On Tue, 24 Apr 2001 13:14:36 +0100, [EMAIL PROTECTED] (Colin Watson) wrote:
> >> you want. The postinst code would call the compression routines,
> >> which might not do anything, depending on how the compressing package
> >> was configured (i.e., it wouldn't call the compressing code directly,
>
Ethan Benson <[EMAIL PROTECTED]> wrote:
>On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
>> you want. The postinst code would call the compression routines,
>> which might not do anything, depending on how the compressing package
>> was configured (i.e., it wouldn't call the compres
> "Aaron" == Aaron Lehmann <[EMAIL PROTECTED]> writes:
Aaron> I would hope that they have the same permissions as the
Aaron> originals. And I don't want to imagine what might happen with
Aaron> a suid excecutable...
The unstable version of UPX (1.11) doesn't use the tempfile approach
anymo
Sun, Apr 22, 2001 at 11:52:55PM -0700 wrote:
> On Sun, Apr 22, 2001 at 11:39:07PM -0700, David Whedon wrote:
> > Recent versions of upx can compress a linux bzImage (I've seen 13% shaved
> > off
> > a bzImage). debian-installer may use it to squeeze more onto the single
> > floppy (kernel + ini
On Mon, Apr 23, 2001 at 11:35:12AM +0100, Colin Watson wrote:
> Incidentally, I assume the temporarily decompressed executables created
> by UPX are mode 700?
I would hope that they have the same permissions as the originals. And
I don't want to imagine what might happen with a suid excecutable...
Alexander Hvostov <[EMAIL PROTECTED]> wrote:
>Since UPX only runs when a program is loaded, and only takes a few seconds
>to do its thing, I see no reason why weaker (eg, 486) machines couldn't
>handle it. Even on old 386 machines, the slowdown shouldn't be much of a
>headache, unless what's being
On Sun, Apr 22, 2001 at 11:39:07PM -0700, David Whedon wrote:
> Recent versions of upx can compress a linux bzImage (I've seen 13% shaved off
> a bzImage). debian-installer may use it to squeeze more onto the single
> floppy (kernel + initrd with modules).
Isn't that slightly redundant? A bzIma
Recent versions of upx can compress a linux bzImage (I've seen 13% shaved off
a bzImage). debian-installer may use it to squeeze more onto the single
floppy (kernel + initrd with modules).
David
Sat, Apr 21, 2001 at 06:25:10PM -0700 wrote:
> On Sat, 21 Apr 2001, John H. Robinson, IV wrote:
>
On Sat, Apr 21, 2001 at 11:50:44AM -0700, John H. Robinson, IV wrote:
> On Sat, Apr 21, 2001 at 11:41:56AM -0700, Alexander Hvostov wrote:
> > On Sat, 21 Apr 2001 11:40:15 -0700 "John H. Robinson, IV" wrote:
> >
> > > however, on something like boot-floppies, this might be a
> > > goddess-send.
>
On Sun, 22 Apr 2001 06:02:30 -0800, Ethan Benson wrote:
> On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
> > If not, I suggest a debhelper command to add the necessary code to
> > the postinst. Packages that use this should, of course, depend on the
> > binary-compressing package,
On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
>
> If not, I suggest a debhelper command to add the necessary code to
> the postinst. Packages that use this should, of course, depend on the
> binary-compressing package, which would provide the one-time question
why should they de
On Sun, 22 Apr 2001 00:57:54 +0200, <[EMAIL PROTECTED]> wrote:
> On Sunday 22 April 2001 00:45, Itai Zukerman wrote:
> > Why not compress the binaries in the postinst, maybe after asking the
> > admin for permission?
>
> Well, if I had to answer "no" to compression for binary in every new package
On Sat, Apr 21, 2001 at 07:42:00PM -0300, Carlos Laviola wrote:
> There is: just upx -d it. (you can even run md5sum before and after
> compression/decompression to find out for yourself that the decompressed file
> is the same as before.)
Will upx -d work on a binary that was compressed with an o
On Sat, Apr 21, 2001 at 12:20:21PM +0200, Eduard Bloch wrote:
> What is upx good for?
> For all applications that are not used in critical environment, i.e.
> without enough free disc space, or when they are started to often, so
> the decompression time may be too long.
> For example, I will compre
On Mon, Sep 20, 1999 at 06:02:47PM -0400, Greg Johnson wrote:
> Here's one (happend to me). I have a '+' at the end of my /etc/passwd file
> for nis. sash tried to add the new root acccount at teh end of /etc/passwd
> AFTER the +. didn't work.
That was sash 3.3-5
Sash 3.3-6 already addresses t
On Mon, Sep 20, 1999 at 02:46:09PM -0700, Joey Hess wrote:
> Raul Miller wrote:
> > Also, if you can anticipate any failure modes where sash would damage
> > the password file I'd appreciate hearing about them. It's already
> > the case that if sash has any problem writing out the new password
> >
On Mon, Sep 20, 1999 at 02:20:12PM -0400, Raul Miller wrote:
> Also, if you can anticipate any failure modes where sash would damage
> the password file I'd appreciate hearing about them. It's already
> the case that if sash has any problem writing out the new password
> file that it won't install
Raul Miller wrote:
> Also, if you can anticipate any failure modes where sash would damage
> the password file I'd appreciate hearing about them. It's already
> the case that if sash has any problem writing out the new password
> file that it won't install it.
I think you should just use useradd
On Mon, Sep 20, 1999 at 01:37:43PM -0400, Andrew Pimlott wrote:
> Will this affect people who upgrade? It would be very unpleasant to upgrade
> from slink and have a new root user.
Hmmm...
> Even for new installs, I disagree with your decision. sash is useful
> without another root account; howe
On Sun, Sep 19, 1999 at 10:53:01PM -0400, Raul Miller wrote:
> Raul Miller wrote:
> > > They don't touch the root account. Instead, they clone
> > > it as sashroot and set the shell on the cloned account.
> > >
> > > This is mentioned in the package description.
>
> On Sun, Sep 19, 1999 at 03:39
1 - 100 of 113 matches
Mail list logo
