Sorry for top-posting
Installing both is a waste of bandwidth (for netinst) and disk space. There are
lovers of both, but most desktop users will never see any of the two.
Having one easy text editor in command line is necessary. Both nano or joe will
make that target. None of emacs nor vi does
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: libsolv
Version : 0.6.5
Upstream Author : Michael Schröder (https://github.com/mlschroe)
* URL : https://github.com/openSUSE/libsolv/
* License : BSD-3-clause
Programming Lang: C
Descripti
Le mardi, 16 septembre 2014, 23.17:51 Joerg Jaspert a écrit :
> On 13698 March 1977, Didier Raboud wrote:
> >> > One thought... there will probably be trademark concerns with
> >> > "unix".[1] So we might have to choose a name for the tasksel task
> >> > to be someting like "unix-like".
> >>
> >>
On Mon, 2014-09-15 at 08:31 +0800, Paul Wise wrote:
> Tagged the bug moreinfo, over the next months I will look at existing
> hardcoding, consult with service maintainers and try to come up with a
> spec on the RepositoryFormat page about what data is needed.
ftp-masters seem to be open to the id
On Wed, 17 Sep 2014, Paul Wise wrote:
> ftp-masters seem to be open to the idea but want a spec for what data
> needs to be exported where.
>
> I would like to invite service maintainers and maintainers of derivative
> distros to document what info they hard-code from the Debian archive and
> thei
On Tue, Sep 16, 2014 at 04:37:00PM -0300, Henrique de Moraes Holschuh wrote:
> Well, depends on how strict you want that parsing to be:
>
> grep -q '^flags.*\' /proc/cpuinfo && echo "SSE2 possible"
>
> This is good enough on i686 and x86-64, as the architecture itself does not
> tolerate any diff
Brian May writes ("rc bugs"):
> Lets say there is a bug in a package X, however package X is still usable
> by itself.
>
> However package Y depends on package X, and as a result of this bug it was
> an RC bug.
>
> Is the bug against package X also RC?
The question you are really asking, surely,
Jackson Doak writes ("Re: Can a leaf package require SSE2 on i386?"):
> The package infernal has also dropped i386 support for this reason. Using
> it's example, this can cause issues for downstreams with i386 arch:all
> builders. Just something to consider
I think dropping the package from i386 i
Theodore Ts'o writes ("Re: Trimming priority:standard"):
> That being said, if there are Debian users who are not Unix-heads,
> they aren't going to miss any of these. What if we create a tasksel
> task called "Unix" that installs these traditional Unix commands from
> the BSD 4.x era? It would i
Le mercredi 17 septembre 2014 à 14:29 +0100, Ian Jackson a écrit :
> Jackson Doak writes ("Re: Can a leaf package require SSE2 on i386?"):
> > The package infernal has also dropped i386 support for this reason. Using
> > it's example, this can cause issues for downstreams with i386 arch:all
> > bui
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: libzypp
Version : 14.29.1
Upstream Author : Michael Andres (https://github.com/mlandres)
* URL : https://github.com/openSUSE/libzypp
* License : GPL-2(+), Expat, Zlib
Programming Lang: C++
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: zypper
Version : 1.11.13
Upstream Author : Michael Andres (https://github.com/mlandres)
* URL : https://github.com/openSUSE/zypper
* License : GPL-2+
Programming Lang: C++
Description
Hi,
during the last security team meeting we decided that starting
with jessie debian-security-support should be installed by default
on all systems (both freshly installed and upgraded) to have a
reliable notification channel in case security supports needs to
be ended prior to the lifetime of t
On 2014-09-17 15:47, Sébastien Villemot wrote:
Concerning the buildd, I now realize that the package really needs SSE2
support at build time. The reason is that, Julia being a JIT-compiler,
it is run at build time to create the binary image of its standard
library. I'll see if that creates proble
Bill Allombert dixit:
> 10.1
> Binaries must not be statically linked with the GNU C library,
> see policy for exceptions.
It says there that exceptions *may* be granted, but not by whom.
So, who can grant an exception for the (already existing)
/bin/mksh-static file (which
Package: wnpp
Severity: wishlist
Owner: Leo Iannacone
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-hicat
Version : 0.6.1
Upstream Author : Rico Sta. Cruz
* URL : https://github.com/rstacruz/hicat
* License : Expat
Programming Lang: JavaSc
Thorsten Glaser wrote:
> Bill Allombert dixit:
> > 10.1
> > Binaries must not be statically linked with the GNU C library,
> > see policy for exceptions.
>
> It says there that exceptions *may* be granted, but not by whom.
>
> So, who can grant an exception for the (already
On 09/18/2014 02:41 AM, Bill Allombert wrote:
.
4.4
It is clarified that signature appearing in debian/changelog
should be the details of the person who prepared this release of
the package.
what does it mean for a team maintained packages? should the u
On Thu, Sep 18, 2014 at 4:15 AM, Moritz Muehlenhoff wrote:
> Does anyone have a better suggestion?
What about just bumping the Priority?
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
"gustavo panizzo (gfa)" writes:
> On 09/18/2014 02:41 AM, Bill Allombert wrote:
>> 4.4
>>It is clarified that signature appearing in debian/changelog
>>should be the details of the person who prepared this release of
>>the package.
> what does it mean fo
20 matches
Mail list logo
