Source: xutils-dev
Version: 1:7.7+6.1
Severity: normal
User: debian-devel@lists.debian.org
Usertags: loong64
X-Debbugs-Cc:
debian-devel@lists.debian.org,zhangjial...@loongson.cn,zhangdan...@loongson.cn
Hi!
Multiple X packages currently fail to build from source on loong64 due
to missing architec
Package: dpkg-dev
Followup-For: Bug #1021292
X-Debbugs-Cc: woo...@wookware.org, debian-devel@lists.debian.org
> We decided that the best thing to do was create a new hardening flags
> feature called 'branch' to add to the existing set. This enables
> -mbranch-protection=standard on arm64, and
> -f
Package: debtags
Severity: wishlist
While tagging the gnucobol package, I discovered there is no tag for the
cobol language. I propose to add a tag devel::lang:cobol for this
purpose. Perhaps also add implemented-in::cobol for completeness, to
match other programming languages?
--
Happy hacking
Package: task-desktop
Version: 3.49
The rationale for this change is IMO not correct.
Michael Biebl wrote:
| all important cron jobs have a corresponding .timer unit
This is not a sufficient condition. Firstly, it is necessary for all
cron jobs, not just ones considered `important', to have a
Hello,
On Mon 24 Dec 2018 at 05:37pm -0300, Felipe Sateler wrote:
> I (not speaking for the whole team), have no objection to this patch.
> However, it was pointed out to me that virtual packages require policy
> updates[1], first starting as a debian-devel discussion. So I'm starting
> this now
]] Felipe Sateler
Two minor typos.
> The proposed virtual packages are:
>
> logind: a org.freedesktop.login1 D-Bus API implementation
«an org…»
> default-logind: should be provided by the distributions default logind
> provider (currently pam-systemd)
distribution's.
Otherwise, this looks
On Mon, Dec 24, 2018 at 05:37:56PM -0300, Felipe Sateler wrote:
> On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski wrote:
> > Could you please either take this patch or propose a different approach?
> > I have received no feedback other than a brief unconclusive remark on IRC.
>
> Sorry for the radi
Hi,
On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski wrote:
> Hi!
> Could you please either take this patch or propose a different approach?
> I have received no feedback other than a brief unconclusive remark on IRC.
>
Sorry for the radio silence. Let's try to remedy that.
> The clock for Buste
On 20 April 2018 at 15:46, Marvin Renich wrote:
> Package: base-files
> Version: 10.1
> Severity: wishlist
>
> * Stephan Seitz [180420 07:38]:
>> On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote:
>> > But being human I prefer names over numbers, even if it's just for
>> > aesthetic re
* Emilio Pozuelo Monfort [180420 11:00]:
> On 20/04/18 16:46, Marvin Renich wrote:
> > I would also like /etc/debian_version to contain both number and name,
> > but I suspect there is some resistance to this on the grounds that
> > scripts may be using $(cat /etc/debian_version) for comparisons.
Marvin,
> I have often wanted to have on my system a text file containing the
> correspondence between code name and release number.
This appears to be already in the archive in a number of places.
For example, in `debdate`, `debian-handbook` or even in the `debian-
timeline` package if you spea
On 20/04/18 16:46, Marvin Renich wrote:
> I would also like /etc/debian_version to contain both number and name,
> but I suspect there is some resistance to this on the grounds that
> scripts may be using $(cat /etc/debian_version) for comparisons.
> Perhaps /etc/debian_codename? Since debian_vers
Package: base-files
Version: 10.1
Severity: wishlist
* Stephan Seitz [180420 07:38]:
> On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote:
> > But being human I prefer names over numbers, even if it's just for
> > aesthetic reason - "buster" is just more comfortable than "debian10".
>
Adam Borowski wrote:
> If you want a fair comparison:
> -rw-r--r-- 1 kilobyte kilobyte 98826240 Jun 16 20:26 octave-4.2.1.tar
> -rw-r--r-- 1 kilobyte kilobyte 15826565 Jul 7 17:13 octave-4.2.1.tar.lz
> -rw-r--r-- 1 kilobyte kilobyte 15174400 Jul 7 17:13 octave-4.2.1.tar.xz
>
> xz wins by 4.2%, wit
Adam Borowski writes:
> Thus, I'd recommend dropping lzip completely. It's worse and obscure.
> With every distro having standardized on xz, providing lzip tarballs is
> a pure waste of space.
Personally, I don't see why anyone should care which compression formats
upstream provides as long as
On Fri, Jul 07, 2017 at 11:01:12AM -0400, Lennart Sorensen wrote:
> On Mon, Jul 03, 2017 at 12:38:59PM +0100, Thomas Pircher wrote:
> > in the example you mentioned upstream have added xz to the set of archives
> > they distribute their source in. Currently[1] the GNU Octave source code is
> > bein
On Mon, Jul 03, 2017 at 12:38:59PM +0100, Thomas Pircher wrote:
> Hi Maria,
>
> in the example you mentioned upstream have added xz to the set of archives
> they distribute their source in. Currently[1] the GNU Octave source code is
> being distributed as .gz, lz and .xz tarballs.
>
> I don't get
Matthias Klumpp wrote...
> So, lzip isn't adopted widely, that's certainly not because of Debian
> or any other Linux distribution.
The war is over, the winner is VHS.
Trying to get lzip support in wider usage is somewhat a boot-up
problem: Few people see an advantage in doing this, so it doesn'
On Mon, 3 Jul 2017 16:25:37 +0200, Maria Bisen
wrote:
>2017-07-03 15:11 GMT+02:00 Matthias Klumpp :
>> So, lzip isn't adopted widely, that's certainly not because of Debian
>> or any other Linux distribution.
>
>I agree, but I thought that Debian adopting lzip could make lzip more
>widely adopted;
On Mon, 03 Jul 2017 12:38:59 +0100, Thomas Pircher
wrote:
>I don't get it; what exactly is the problem when upstream distributes
>their source in multiple formats, including .xz and .lz, among others?
That the lzip community knows that the lzipped sources will almost
never be decompressed by any
Hi Matthias,
2017-07-03 15:11 GMT+02:00 Matthias Klumpp :
>
> So, lzip isn't adopted widely, that's certainly not because of Debian
> or any other Linux distribution.
>
I agree, but I thought that Debian adopting lzip could make lzip more
widely adopted; and that's why I started this thread. Now
2017-07-03 14:42 GMT+02:00 Maria Bisen :
> [...]
> 4- As a result, lzip is almost never used alone (without xz), and Debian can
> justify forever the lack of lzip support
>
> You need to consider all four points to understand the issue.
No, please read again the mails previous developers wrote. Lz
Hi Thomas,
Thomas wrote:
> I don't get it; what exactly is the problem when upstream distributes
their
> source in multiple formats, including .xz and .lz, among others?
Please check again point 1 and 2. See below:
1- Somebody from Debian says: "if a lot of upstream tarballs start to be
nativel
Maria Bisen writes ("Re: Please add lzip support in the repository"):
> Moreover, software errors have already killed people:
Good grief.
This conversation is:
1. determined advocacy from an external project
2. going badly
3. not capable of leading to any productive outcome
li
On 2017-07-03 11:41, Maria Bisen wrote:
3- Somebody else, also from Debian, asks the upstream above to bring
back
the xz tarball
4- As a result, lzip is almost never used alone (without xz), and
Debian can
justify forever the lack of lzip support
Hi Maria,
in the example you mentioned upst
Hi,
Russ Allbery wrote:
>> As an user of Octave who wish to see more lzip adoption, I don't think
>> this to be fair.
> Octave's use of lzip is completely unrelated to Debian asking for xz.
> Providing xz in no way prevents Octave from also providing lzip. I think
> you are inventing a conflict
Paul Wise wrote...
> On Thu, Jun 15, 2017 at 9:05 PM, Christoph Biedl wrote:
>
> > I'm not keen on extending regular expressions like
> >
> > \.(gz|bz2|lzma|xz)$
> >
> > that I have in many places again and again.
>
> That sort of hard-coding should stop,
Understandable and desirable, but p
Maria Bisen writes:
> Also, I think the issue here it's not just proponents of lzip "coming
> here", but Debian people "going out", in what I reckon can be a conflict
> of interest.
This isn't what "conflict of interest" means. This is just an interest.
There is no conflict.
Currently, Debian
Hi Russ,
Russ Allbery wrote:
> Debian has never expressed any opinion about lzip outside of our project
> mailing lists. The only reason why it's even on our radar is that
> proponents of lzip keep *coming here* and trying to push it on us. Some
> of them are polite about it, and we've had poli
Maria Bisen writes:
> After reading again Guillem Jover's answer it seems to me that the only
> marketing campaign here is Debian against lzip. Even if you don't like
> something, for whatever personal reasons, I don't think it's fine to
> influence thousands of people, and Debian has the capacit
Hi,
Sorry for the delay, but I think this needs a clarification.
Ian Jackson wrote:
> For Debian binary and source packages, there is no benefit in ECC
> in the compression layer.
>
> I'm not sure why all of this isn't obvious.
>
> As an aside: I am sceptical of the value of ECC as part of a gen
Henrique de Moraes Holschuh writes ("Re: Please add lzip support in the
repository"):
> On Fri, 16 Jun 2017, Adrian Bunk wrote:
> > On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
> > >...
> > > We pretty much need Debian pac
On Fri, 16 Jun 2017, Adrian Bunk wrote:
> On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
> >...
> > We pretty much need Debian packages to be 100% correct in the first
> > place, they are not going to be subject to lossy recovery from
> > corruption (which is where lzi
Adrian Bunk wrote:
> On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
[...]
>> So, it would make more sense to have a par2 (or create a modern version
>> of it, actually) ECC layer on top of the compression layer, at which
>> point we can use one of the already supporte
On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
>...
> We pretty much need Debian packages to be 100% correct in the first
> place, they are not going to be subject to lossy recovery from
> corruption (which is where lzip is supposed to be much better than xz):
> we nee
On 2017-06-16 12:42:00 +0200 (+0200), Maria Bisen wrote:
[...]
> When I saw in the gcc thread that there's only one distribution
> not supporting lzip
[...]
Following the GCC discussion you linked, I believe it was actually a
reference to SLES lacking any package of lzip at all:
https://gcc.g
Russ Allbery wrote:
> Oh, you're concerned with what upstream tarballs Debian can consume
> without repackaging.
>
> I don't see any reason why this should prevent GCC from releasing tarballs
> compressed with lzip if they want to. They certainly wouldn't stop
> releasing tarballs in other format
> lzip 1.19 is available just in Debian experimental, because we are in
> final-countdown nearly-absolute freeze: we will release the next Debian
> stable this weekend, with lzip 1.18.
>
> lzip 1.19 should be uploaded to Debian unstable sometime after we
> release, at its debian maintainer discreti
On Thu, Jun 15, 2017 at 08:30:33PM -0700, Russ Allbery wrote:
> writes:
>
> > First of all, thank you for your kind and sympathetic message. I'm
> > referring to the second option you mentioned. We are using gcc, and it
> > seems that a reason to not use lzip in gcc is that Debian doesn't
> > sup
writes:
> First of all, thank you for your kind and sympathetic message. I'm
> referring to the second option you mentioned. We are using gcc, and it
> seems that a reason to not use lzip in gcc is that Debian doesn't
> support source tarballs in lzip format.
Oh, you're concerned with what upstr
On Thu, 15 Jun 2017, mariabi...@gmail.com wrote:
> PS: lzip version available in Debian is 1.16, but the last one is 1.19. Maybe
> it's time to update! :)
lzip 1.19 is available just in Debian experimental, because we are in
final-countdown nearly-absolute freeze: we will release the next Debian
On Thu, 15 Jun 2017, Christoph Biedl wrote:
> Also I doubt the reduced disk space and network bandwitdth usage of any
> new kid on the block (there's also zstd) really justifies the work
> needed to implement the support in the many tools that deal with the
> files. I might be convinced otherwise.
Hi,
Russ Allbery wrote:
> > Maria Bisen writes:
> > It's been drawn to my attention the topic included in this thread:
> > https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
> > I've got the feeling that the distribution the thread talks about is
> > precisely yours, Debian's. As stated there,
Hi Guillem,
Guillem Jover wrote:
> On Thu, 2017-06-15 at 17:22:53 +0500, Andrey Rahmatullin wrote:
> > On Thu, Jun 15, 2017 at 01:55:10PM +0200, Maria Bisen wrote:
> > > It's been drawn to my attention the topic included in this thread:
> > >
> > > https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
Maria Bisen writes:
> It's been drawn to my attention the topic included in this thread:
> https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
> I've got the feeling that the distribution the thread talks about is
> precisely yours, Debian's. As stated there, giving support to lzip in
> Debian see
Stuart Prescott writes ("Re: Please add lzip support in the repository"):
> > What is `apt-helper cat-file' and how does it help ?
>
> On stretch:
>
> $ apt-file search apt-helper
> apt: /usr/lib/apt/apt-helper
Ah. I looked on PATH. I expect "Fr
Hi!
On Fri, 2017-06-16 at 00:35:37 +1000, Stuart Prescott wrote:
> > What is `apt-helper cat-file' and how does it help ?
> $ apt-file search apt-helper
> apt: /usr/lib/apt/apt-helper
> $ /usr/lib/apt/apt-helper download-file
> http://deb.debian.org/debian/dists/sid/main/binary-amd64/Packages.x
> What is `apt-helper cat-file' and how does it help ?
On stretch:
$ apt-file search apt-helper
apt: /usr/lib/apt/apt-helper
$ /usr/lib/apt/apt-helper
apt 1.4.6 (amd64)
Usage: apt-helper [options] command
apt-helper [options] cat-file file ...
apt-helper [options] download-file uri
Paul Wise writes ("Re: Please add lzip support in the repository"):
> On Thu, Jun 15, 2017 at 9:05 PM, Christoph Biedl wrote:
> > I'm not keen on extending regular expressions like
> >
> > \.(gz|bz2|lzma|xz)$
> >
> > that I have in many place
Hi!
On Thu, 2017-06-15 at 17:22:53 +0500, Andrey Rahmatullin wrote:
> On Thu, Jun 15, 2017 at 01:55:10PM +0200, Maria Bisen wrote:
> > It's been drawn to my attention the topic included in this thread:
> >
> > https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
> >
> > I've got the feeling that the
On Thu, Jun 15, 2017 at 9:05 PM, Christoph Biedl wrote:
> I'm not keen on extending regular expressions like
>
> \.(gz|bz2|lzma|xz)$
>
> that I have in many places again and again.
That sort of hard-coding should stop, if you see it somewhere please
switch to using apt, either via the apt lib
Maria Bisen wrote...
> I've got the feeling that the distribution the thread talks about is
> precisely yours, Debian's. As stated there, giving support to lzip in
> Debian seems feasable and easy. Could it be possible, then, to add
> lzip support? : )
If I understand correctly, it's about using
On Thu, Jun 15, 2017 at 01:55:10PM +0200, Maria Bisen wrote:
> It's been drawn to my attention the topic included in this thread:
>
> https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
>
> I've got the feeling that the distribution the thread talks about is
> precisely yours, Debian's. As stated th
Hi Debian developers,
It's been drawn to my attention the topic included in this thread:
https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
I've got the feeling that the distribution the thread talks about is
precisely yours, Debian's. As stated there, giving support to lzip in
Debian seems feasab
package: ftp.debian.org
x-debbugs-cc: debian-devel@lists.debian.org
severity: wishlist
Hi,
(I'm not really using golang, so I'm not the best person to comment on the
description.)
On Thu, Dec 08, 2016 at 10:36:38PM +0100, Joerg Jaspert wrote:
> > The following might work as a description for suc
Processing control commands:
> reassign -1 wnpp
Bug #825137 [general] general: Please add ISSE to Debian repositories
http://isse.sourceforge.net/
Bug reassigned from package 'general' to 'wnpp'.
Ignoring request to alter found versions of bug #825137 to the same values
Control: reassign -1 wnpp
Control: retitle -1 RFP: ISSE: An Interactive Source Separation Editor
On 05/24/2016 01:04 AM, gnumedia wrote:
> Please add ISSE to Debian repositories when you can.
There is a procedure in Debian for requesting software to be packaged,
by opening a so-called RFP
Package: general
Severity: wishlist
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
Hello Debian Maintainer
This is the first time I have requested a package for Debian.
Please add ISSE to Debian repositories when you can. It is a useful
tool
Why on earth is that landing on debian-devel@?
Thorsten Glaser (2014-12-02):
> On Mon, 1 Dec 2014, Cyril Brulebois wrote:
>
> > > Could you please add support for the Tanglu[1] Debian derivative?
>
> > Without having looked at it yet: thanks.
>
> > Yes, plea
2014-12-02 15:19 GMT+01:00 Thorsten Glaser :
> On Mon, 1 Dec 2014, Cyril Brulebois wrote:
>
>> > Could you please add support for the Tanglu[1] Debian derivative?
>
>> Without having looked at it yet: thanks.
>
>> Yes, please. One bug report per feature is th
On Mon, 1 Dec 2014, Cyril Brulebois wrote:
> > Could you please add support for the Tanglu[1] Debian derivative?
> Without having looked at it yet: thanks.
> Yes, please. One bug report per feature is the best way.
I thought d-i was frozen and debootstrap was to absolutely
not be
On Fri, Nov 15, 2013 at 5:05 AM, Adam D. Barratt
wrote:
> On 2013-11-15 8:32, Andrei POPESCU wrote:
>
>> On Jo, 14 nov 13, 12:39:04, Craig Miller wrote:
>>
>>> Please add expect-lite package to Squeeze & Wheezy
>>>
>> [...]
>
> Since you will
On 2013-11-15 8:32, Andrei POPESCU wrote:
On Jo, 14 nov 13, 12:39:04, Craig Miller wrote:
Please add expect-lite package to Squeeze & Wheezy
[...]
Since you will be the Maintainer of the package I think you wanted to
file an ITP (Intent to Package) and not an RFP (Request to package).
Pl
Control: reassign -1 wnpp
Control: retitle -1 ITP: expect-lite -- easy to use version of expect
Control: owner -1 Craig Miller
On Jo, 14 nov 13, 12:39:04, Craig Miller wrote:
> Package: expect-lite
> Severity: normal
>
> Dear Maintainer,
>
> Please add expect-lite package t
ed in [1] and in a IRC
discussion with don we (ansgar, gregoa, jwilk, bremner, paultag, myself)
seemed to agree to this name proposal.
Hence, please add a "sponsorship-requests" pseudo-package with
debian-ment...@lists.debian.org as a package owner and we can get started.
[1] http://
--
please add this id - ajeet.seofl...@gmail.com. I am new to SEO so kindly
help
Hi SEO
Please add my ID for Link Exchage
*ejaz.webmas...@gmail.com*
raj.san...@gmail.com
Hi all
I am a freelancer(Link building) and looking for other freelancer to work
together.
Please contact through mail.
Thanks
Mark
HI Dear,
please add my ID for Link Ex.
i have new Back links.
--
*Best Regards*
Anika
(¨`•.•´¨) Always
`•.¸(¨`•.•´¨) Keep
(¨`•.•´¨)¸.•´ Smiling!
`•.¸.•´
Thank you Very much.:)
Dear webmaster
Please add my id, my id is- * rozip...@gmail.com*
thank you
with regards
Miss rozi
Package: developers-reference
Version: 3.4.0
Severity: wishlist
Hello,
this started at http://lists.debian.org/debian-devel/2008/06/msg00309.html.
On Fri, 13 Jun 2008 23:27:02 +0200, Frank S. Thomas wrote:
> On Friday 13 June 2008 18:22, Christian Perrier wrote:
>> Quoting Luca Capello ([EMAIL P
@begin note to debian developers
dear debian developers: would someone _please_ explain to marc that,
as exim4 is the default mailer for debian, that he is in quite a
serious position of responsibility, and that exim4 needs to cater for
_everybody_'s needs, with the minimum amount of disruption to
On Sun, Jul 23, 2006 at 07:47:16PM +0200, Ludovic Brenta wrote:
> OK, filed #379451 (serious, because it blocks the Ada transition). I
> note however that dak has 58 outstanding bugs, the newest of which is
> 63 days old and the oldest is 4 years and 106 days old today.
Your bug has already been
On Sun, Jul 23, 2006 at 01:56:09PM -0600, LaMont Jones wrote:
> Been out for a bit - updated.
You did not do mine. Pretty please, I am begging for it. Please remove
the line concerning iroffer.
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys & Net
On Fri, Jul 21, 2006 at 10:03:56PM +0200, Ludovic Brenta wrote:
> It has been a week since I sent the request below, and I received no
> answer. I am resending to the three maintainers of
> Packages-arch-specific, and CCing debian-devel.
Been out for a bit - updated.
lamont
--
To UNSUBSCRIBE,
Aurélien GÉRÔME writes:
> Hi Ludovic,
>
> On Sat, Jul 22, 2006 at 06:56:06PM +0200, Ludovic Brenta wrote:
>> So, my idea of a buildd pseudo-package in the BTS was a god one after
>> all. Or, is the 'dak' package an appropriate place for such requests?
>
> An excellent one, indeed!
OK, filed #3794
Hi Ludovic,
On Sat, Jul 22, 2006 at 06:56:06PM +0200, Ludovic Brenta wrote:
> So, my idea of a buildd pseudo-package in the BTS was a god one after
> all. Or, is the 'dak' package an appropriate place for such requests?
An excellent one, indeed!
> Does anyone on this list feel like joining the
Kurt Roeckx writes:
> I've actually requested the same changes for ada.
>
> I've always been annoyed by the lack of response we get when
> sending updates for it. There are other changes I'm waiting for.
So, my idea of a buildd pseudo-package in the BTS was a god one after
all. Or, is the 'dak'
On Fri, Jul 21, 2006 at 10:03:56PM +0200, Ludovic Brenta wrote:
> It has been a week since I sent the request below, and I received no
> answer. I am resending to the three maintainers of
> Packages-arch-specific, and CCing debian-devel.
>
> I've restricted the list of supported architectures to
It has been a week since I sent the request below, and I received no
answer. I am resending to the three maintainers of
Packages-arch-specific, and CCing debian-devel.
I've restricted the list of supported architectures to those where
gnat-4.1 not only exists but also builds its shared libraries.
Package: debian-policy
Version: 3.6.1.1
Severity: wishlist
Hello, I am following the steps in virtual-package-names-list.txt[1] in
order to add (or not add) the virtual package name 'x-display-manager'
to the authorative list of virtual package names.
The virtual package x-display-manager is desc
Sam Watkins wrote:
> On Thu, Jan 13, 2005 at 02:09:41PM -0500, Kevin McCarty wrote:
>
>> the software contains what appears to be code derived from cernlib
>> (GPL) [3] and Xclass (LGPL) [4] while having a license incompatible
>> with either.
>
> They likely are allowed to use cernlib, however x
Sam Watkins wrote:
> I wrote to them just now, and Fons said:
>
>> Hi Sam,
>>
>> we are in the process of removing the single non OS limitation from our
>> license in the very near future (coming months/weeks). The xclass derived
>> work is solely contained in one single library libGui. The au
On Thu, Jan 20, 2005 at 10:05:10AM +0100, Tim Dijkstra wrote:
> I read the threads you linked to above, but I couldn't find a reference
> to anybody explaining the ROOT guys what the problem is. Did anybody
> try, what was their response?
I wrote to them just now, and Fons said:
> Hi Sam,
>
>
On Thu, 13 Jan 2005 14:09:41 -0500
Kevin McCarty <[EMAIL PROTECTED]> wrote:
> There are two problems: first, the license [1] forbids redistribution
> of modified binaries without permission of the authors, which some
> have argued makes it unsuitable even for non-free [2]; second, and
> worse, the
On Thu, Jan 13, 2005 at 02:09:41PM -0500, Kevin McCarty wrote:
> Could someone please add Root (http://root.cern.ch/) to the list of software
> that cannot be packaged, http://www.debian.org/devel/wnpp/unable-to-package
> the software contains what appears to be code derived from cernl
Package: www.debian.org
Severity: wishlist
Hello,
Could someone please add Root (http://root.cern.ch/) to the list of software
that cannot be packaged, http://www.debian.org/devel/wnpp/unable-to-package
? There have been several attempts at ITPs:
http://lists.debian.org/debian-mentors/1999/12
Hi,
>>"SirDibos" == <[EMAIL PROTECTED]> writes:
SirDibos> On Tue, 20 May 1997, Mike Orr wrote:
SirDibos> You are right. However, what solution do you suggest in my
SirDibos> case, where I have 6 different kernels cluttering up my / ?
SirDibos> I use all of em, 1 is a backup, some implement di
On Tue, 20 May 1997, Mike Orr wrote:
> It should be copied, and not symlinked. /boot must not have any symlinks
> into /usr, in case /usr is trashed and you're trying to recover.
>
> If the symlink went the other way, from /usr/src/linux/.config into
> /boot/.config, then "make config" would b
On Mon, 19 May 1997 [EMAIL PROTECTED] wrote:
> Just, let it be symlinked to
> /usr/src/linux/.config too, ok? =)
It should be copied, and not symlinked. /boot must not have any symlinks
into /usr, in case /usr is trashed and you're trying to recover.
If the symlink went the other way, from /us
Hi,
>>"Jean" == Jean Pierre LeJacq <[EMAIL PROTECTED]> writes:
Jean> I agree with the basic concept but shouldn't this be placed in
Jean> /etc instead of /boot. /etc defines the configuration for the
Jean> host after all.
The config file, which shall reside in the kernel-image
package,
On Mon, 19 May 1997 [EMAIL PROTECTED] wrote:
> On 19 May 1997, Manoj Srivastava wrote:
>
> > Less blather this time. Yes, ther reason is that /boot
> > contains other useful information about the kernels ensconced there,
> > (like System.map, and psdatabase) but is missing one piece: exac
On 19 May 1997, Manoj Srivastava wrote:
> Less blather this time. Yes, ther reason is that /boot
> contains other useful information about the kernels ensconced there,
> (like System.map, and psdatabase) but is missing one piece: exactly
> what is configured into the kernel (which can be
Hi,
>>"jwalther" == jwalther <[EMAIL PROTECTED]> writes:
>> Are there any objections to moving the file into /boot?
jwalther> Is there really any reason to take us farther away from the
jwalther> standard that everyone else uses? Its just one more gotcha
jwalther> that'll tick a newbie off whe
Hi,
>>"jwalther" == jwalther <[EMAIL PROTECTED]> writes:
>> Are there any objections to moving the file into /boot?
jwalther> Is there really any reason to take us farther away from the
jwalther> standard that everyone else uses? Its just one more gotcha
jwalther> that'll tick a newbie off when
> Are there any objections to moving the file into /boot?
Is there really any reason to take us farther away from the standard that
everyone else uses? Its just one more gotcha that'll tick a newbie off
when they follow their slackware friends advice, dl the kernel source, and
just have a
On May 19, Manoj Srivastava wrote
> My 2 cents: I think I agree with Vincent Renardias ; the
> kernel configuration file really belongs in /boot. However, I do not
> feel comfortable taking unilateral decisions about something as
> touchy as /boot (some people require thin root partitions)
Hi,
My 2 cents: I think I agree with Vincent Renardias ; the
kernel configuration file really belongs in /boot. However, I do not
feel comfortable taking unilateral decisions about something as
touchy as /boot (some people require thin root partitions).
Are there any objection
1 - 100 of 101 matches
Mail list logo
