Re: Trimming priority:standard

[Josh Triplett]

Tollef Fog Heen wrote:
> ]] Josh Triplett 
> 
> > - mlocate.  We don't need a "locate" in standard; anyone who actually
> >   uses locate (and wants the very significant overhead of running a
> >   locate daemon) can easily install this.
> 
> There is no «locate daemon» in mlocate.

s/daemon/cron job/g

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915074646.GA20730@thin

Re: Can a leaf package require SSE2 on i386?

[Helmut Grohne]

On Sun, Sep 14, 2014 at 07:47:27AM +0100, Sébastien Villemot wrote:
> The bottom line is that julia needs SSE2 (and porting it to the x87 FPU
> requires changes that are beyond what I am willing/able to do, see [1]
> for more details). And the presence of SSE2 is not guaranteed on the
> i386 architecture.

A related topic was discussed during the bootstrap sprint[0], see
section 2 (small part of that long mail). There, the topic of having
optimized builds of packages was discussed. This technique can also be
used to only provide optimized builds without providing non-optimized
builds. It is not available in sid today. Please get in touch with Aron
Xu (CCed).

Helmut

[0] https://lists.debian.org/20140829095214.gv19...@stoneboat.aleph1.co.uk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915075750.ga10...@alf.mars

Re: Can a leaf package require SSE2 on i386?

[Mathieu Malaterre]

On Sun, Sep 14, 2014 at 8:47 AM, Sébastien Villemot
 wrote:
> Hi,
>
> As the maintainer of julia (a technical computing language built on top
> of LLVM), I am wondering whether I should continue supporting the i386
> architecture.
>
> The bottom line is that julia needs SSE2 (and porting it to the x87 FPU
> requires changes that are beyond what I am willing/able to do, see [1]
> for more details). And the presence of SSE2 is not guaranteed on the
> i386 architecture.

As per ld.so man page:

HARDWARE CAPABILITIES
   Libraries might be compiled using hardware-specific
instructions which do not exist on all CPU. Such libraries should be
installed in directories whose name defines
   the hardware capabilities such as /usr/lib/sse2/. The dynamic
linker checks these directories against the hardware of the machine
and selects the best suitable ver‐
   sion of a given library. Hardware capabilities directories
could be cascaded to combine CPU features. Hardware capabilities
depends on the CPU. The following  names
   are currently recognized:
[...]
  x86 (32-bit only)
  acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386,
i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss,
sse, sse2, tm

HTH


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUszjeCz0hVVAQb9=evysce2q-axdqn3xvxlewdx84as...@mail.gmail.com

Bug#761630: ITP: gosa-plugin-netgroups -- NIS netgroups plugin for GOsa²

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: gosa-plugin-netgroups
  Version : 0.1~svn652
  Upstream Author : Alejandro Escanero Blanco 
* URL : 
https://oss.gonicus.de/repositories/gosa-contrib/netgroups/trunk
* License : GPL
  Programming Lang: PHP
  Description : NIS netgroups plugin for GOsa²

 Manage LDAP-based NIS netgroups with GOsa².
 .
 GOsa² is a combination of system-administrator and end-user web
 interface, designed to handle LDAP based setups.

--

 This package will replace a nasty but necessary Debian Edu hack (see [1])
 introduced in Debian squeeze.
 
 The NIS netgroups plugin of GOsa² is an essential component of the Debian
 Edu / Skolelinux main server setup.

 The package will be maintained by me under the umbrella of the Debian Edu
 packaging team.

[1] apt-cache show debian-edu-config-gosa-netgroups


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140915084045.23029.47171.report...@minobo.das-netzwerkteam.de

Re: Can a leaf package require SSE2 on i386?

[Thomas Goirand]

On 09/15/2014 04:04 PM, Mathieu Malaterre wrote:
> On Sun, Sep 14, 2014 at 8:47 AM, Sébastien Villemot
>  wrote:
>> Hi,
>>
>> As the maintainer of julia (a technical computing language built on top
>> of LLVM), I am wondering whether I should continue supporting the i386
>> architecture.
>>
>> The bottom line is that julia needs SSE2 (and porting it to the x87 FPU
>> requires changes that are beyond what I am willing/able to do, see [1]
>> for more details). And the presence of SSE2 is not guaranteed on the
>> i386 architecture.
> 
> As per ld.so man page:
> 
> HARDWARE CAPABILITIES
>Libraries might be compiled using hardware-specific
> instructions which do not exist on all CPU. Such libraries should be
> installed in directories whose name defines
>the hardware capabilities such as /usr/lib/sse2/. The dynamic
> linker checks these directories against the hardware of the machine
> and selects the best suitable ver‐
>sion of a given library. Hardware capabilities directories
> could be cascaded to combine CPU features. Hardware capabilities
> depends on the CPU. The following  names
>are currently recognized:
> [...]
>   x86 (32-bit only)
>   acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386,
> i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss,
> sse, sse2, tm
> 
> HTH

Thanks. That's nice, however, what if a library needs SSE4.2? Two of my
packages, eg libjerasure2 and libgf-complete1, would benefit from major
speed-up if there was SSE4 available. I have currently disabled all SSE
stuff, and would really like to provide an SSE4.2 version as well. I
suppose (according to what's above) that using
/usr/lib/sse4.2/x86_64-linux-gnu isn't supported (yet), right? (note: I
already asked upstream if it was possible to do runtime detection, and
the answer is currently no, unfortunately)

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5416a905.3000...@debian.org

Bug#761631: ITP: aprsc -- APRS-IS server in C

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: aprsc
  Version : 2.0.14
  Upstream Author : Matti Aarnio, OH2MQK
* URL : http://he.fi/aprsc/
* License : BSD
  Programming Lang: C
  Description : APRS-IS server in C

aprsc (pronounced a-purrs-c) is a plain APRS-IS server intended to be used
on the core and Tier2 APRS-IS servers. It is written in the C language,
and it runs on Linux and Unix servers.

If you need igate or other radio-interfacing features, aprsc is not for you.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140915084242.10519.81119.report...@lepton.shiftout.net

Bug#761633: ITP: python-xstatic-jquery.bootstrap.wizard -- JQuery.Bootstrap.Wizard XStatic support

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-xstatic-jquery.bootstrap.wizard
  Version : 1.0.0.1
  Upstream Author : Radomir Dopieralski 
* URL : 
https://github.com/stackforge/xstatic-jquery.bootstrap.wizard
* License : MIT/Expat and GPL-3
  Programming Lang: Python
  Description : JQuery.Bootstrap.Wizard XStatic support

 XStatic is a Python web development tool for handling required static data
 files from external projects, such as CSS, images, and JavaScript. It provides
 a lightweight infrastructure to manage them via Python modules that your app  
 can depend on in a portable, virtualenv-friendly way instead of using embedded
 copies.
 .
 This package contains the Python module XStatic support for
 JQuery.Bootstrap.Wizard See the libjs-twitter-bootstrap-wizard package for
 more information.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140915091429.20264.21186.report...@buzig.gplhost.com

Re: Can a leaf package require SSE2 on i386?

[Samuel Thibault]

Thomas Goirand, le Mon 15 Sep 2014 16:53:25 +0800, a écrit :
> I suppose (according to what's above) that using
> /usr/lib/sse4.2/x86_64-linux-gnu isn't supported (yet), right?

I guess it shouldn't be hard to add the support, once the need is
expressed :)

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915091748.ge3...@type.bordeaux.inria.fr

Re: locale choices: , C, C.UTF-8, en_US.UTF-8 and availability

[Colin Watson]

On Mon, Sep 15, 2014 at 01:42:32AM +0900, Osamu Aoki wrote:
> LANG = C.UTF-8 (Not defined in anywhere easily found but available)
>  System can always be set this way under Jessie(??) and system acts
>  100% POSIX manner for ASCII characters while not corrupting UTF-8 
>  character processing.
>  No locale data generation seems to be required under Jessie.

It's available in wheezy too, although not squeeze.
/usr/lib/locale/C.UTF-8/ is shipped by libc-bin and thus guaranteed to
be available without locale generation.

> One of the package I maintain (ibus) has gettext data pairing
> en_US.UTF-8 data with localized text.  Currently, user choice in
> localized luggage is translated back to en_US.UTF-8 string and that
> English text containing non-ASCII is used for further processing.

I believe gettext warns about doing this, for exactly this kind of
reason.  As such most upstreams avoid non-ASCII msgstrs and so this is
fortunately a rare situation.

> Jessie seems to have C.UTF-8 available as default, am I safe to use
> C.UTF-8 as always available UTF-8 compatible English system?

Yes.  You can't guarantee it's available on non-Debian-based systems
though.

> I see several ways to fix packaging of ibus:
> 
>  * Patch the upstream source with s/en_US.UTF-8/C.UTF-8/g .
>  * Add locales-all to package dependency is another solution.
>  * (If locales package always set up en_US.UTF-8, I am off the hook.)

The first sounds correct here based on your description of the problem.
The second is an unnecessarily heavyweight dependency, and the third
would privilege a particular national locale for a not very good reason.

> I guess some apps may be in the same situation.  How other DDs are
> coping with apps which set its internal locale value temporarily to the
> default en_US.UTF-8?

If all your package needs is to extend character handling to cover UTF-8
rather than merely ASCII, then using the C.UTF-8 locale is the correct
fix on Debian.

There are some packages which care about more details of the locale, for
a variety of good and bad reasons (I've seen ones that naïvely decompose
it and try to use the language part as a directory name, for instance),
and those are more difficult to handle.  If this is done at build-time
then I would normally suggest build-depending on locales (not
locales-all) and using localedef to generate a temporary locale for the
course of the build.  If this is done at run-time then I might
reluctantly accept the need for a dependency on locales-all, but it's
usually a sign that some refactoring is needed.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915102300.ga2...@riva.ucam.org

Re: Trimming priority:standard

[Fabian Greffrath]

Am Freitag, den 12.09.2014, 08:59 +0200 schrieb Fabian Greffrath: 
> > apt-listchanges aptitude aptitude-common at bash-completion bc dc bind9-host
> Why is aptitude still in this list?


This has not been answered yet?!

- Fabian



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1410775651.31175.11.ca...@greffrath.com

Re: locale choices: , C, C.UTF-8, en_US.UTF-8 and availability

[Jakub Wilk]

* Colin Watson , 2014-09-15, 11:23:
There are some packages which care about more details of the locale, 
for a variety of good and bad reasons (I've seen ones that naïvely 
decompose it and try to use the language part as a directory name, for 
instance), and those are more difficult to handle.  If this is done at 
build-time then I would normally suggest build-depending on locales 
(not locales-all) and using localedef to generate a temporary locale 
for the course of the build.


One gotcha with generating locales is that locales-all has "Provides: 
locales", but it does not include all the data localedef(1) needs. You 
either need to make the build-dependency versioned, or use 
localehelper[0] instead of localedef.



[0] http://jwilk.net/software/localehelper

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915105241.ga5...@jwilk.net

Re: Can a leaf package require SSE2 on i386?

[Thomas Goirand]

On 09/15/2014 05:17 PM, Samuel Thibault wrote:
> Thomas Goirand, le Mon 15 Sep 2014 16:53:25 +0800, a écrit :
>> I suppose (according to what's above) that using
>> /usr/lib/sse4.2/x86_64-linux-gnu isn't supported (yet), right?
> 
> I guess it shouldn't be hard to add the support, once the need is
> expressed :)
> 
> Samuel

Really? Ok... then *I NEED IT* ! :)

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5416df67.9000...@debian.org

Re: Trimming priority:standard

[Jonathan Dowland]

On Fri, Sep 12, 2014 at 03:44:46AM +0200, Adam Borowski wrote:
> You want 'nc myserver 25', as 'telnet myserver 25' will misbehave on 0xff
> bytes.  A malicious server can do pretty surprising things to you, too.

You're both wrong; you want swaks(1).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915133648.ga22...@bryant.redmars.org

Re: Trimming priority:standard

[Jonathan Dowland]

On Fri, Sep 12, 2014 at 06:27:38PM +0100, Simon McVittie wrote:
> On 12/09/14 18:19, Theodore Ts'o 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".
> 
> Perhaps
> 
> task-traditional -- Traditional Unix utilities

I quite like that. My main objection with task 'unix' is it'll be confusing for
users who are not really sure what it is, but think that it must be important.

My less important objection is I have a hobby source package 'unix' which is
the v7 UNIX sources (so far only ed/sed have been made to work on modern
systems; the work was all done by David Jones and not me). I will almost
certainly never upload this package, but I do occasionally daydream about
/usr/lib/unix/{sed,ed,cat} etc.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915134207.gb22...@bryant.redmars.org

Re: Trimming priority:standard

[Jonathan Dowland]

On Fri, Sep 12, 2014 at 03:49:11PM +0200, Thorsten Glaser wrote:
> bc is the standard Unix calculator, normally a dc frontend,
> and used in *a lot* of scripts.

Is there any way of verifying or even reasonably estimating how common it is
used?  *Within* debian, sadly it's hard to ascertain via codesearch as 'bc' is
too short, but /bc => http://codesearch.debian.net/search?q=%2Fbc

I must admit I've never seen it used in 3rd party scripts in my entire career
as a sysadmin.

> And yes, bc is also the primary interactive calculator,
> for things beyond what $((…)) can do.

We've got python in priority:standard.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915135328.gc22...@bryant.redmars.org

Re: Trimming priority:standard

[Holger Levsen]

Hi,

On Montag, 15. September 2014, Jonathan Dowland wrote:
> > Perhaps
> > task-traditional -- Traditional Unix utilities
> I quite like that.

FWIW, me too. (I also liked "task-unix" or "task-unix-like", but less.)

Thanks for cleaning up priority:standard!


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#761665: ITP: r-cran-vioplot -- GNU R toolbox for violin plots

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-vioplot
  Version : 0.2
  Upstream Author : Daniel Adler  
* URL : http://cran.r-project.org/web/packages/vioplot/index.html
* License : BSD
  Programming Lang: R
  Description : GNU R toolbox for violin plots
 Violin plots are a method of plotting numeric data. A violin plot is a
 combination of a box plot and a kernel density plot. Specifically, it
 starts with a box plot. It then adds a rotated kernel density plot to
 each side of the box plot.

This package will be maintained by the Debian Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-vioplot/trunk/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140915150941.14635.18093.report...@mail.an3as.eu

Re: Trimming priority:standard

[Ben Hutchings]

On Mon, 2014-09-15 at 14:53 +0100, Jonathan Dowland wrote:
> On Fri, Sep 12, 2014 at 03:49:11PM +0200, Thorsten Glaser wrote:
> > bc is the standard Unix calculator, normally a dc frontend,
> > and used in *a lot* of scripts.
> 
> Is there any way of verifying or even reasonably estimating how common it is
> used?  *Within* debian, sadly it's hard to ascertain via codesearch as 'bc' is
> too short, but /bc => http://codesearch.debian.net/search?q=%2Fbc
> 
> I must admit I've never seen it used in 3rd party scripts in my entire career
> as a sysadmin.

It is used in one place in a Linux kernel build
(kernel/time/timeconst.bc).

Ben.

> > And yes, bc is also the primary interactive calculator,
> > for things beyond what $((…)) can do.
> 
> We've got python in priority:standard.
> 
> 

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.


signature.asc
Description: This is a digitally signed message part

Maintainer/home wanted for DDE (Debian Data Export / dde.debian.net)

[Thijs Kinkhorst]

All,

The 'rapt-file' tool shipped in apt-file uses dde.debian.net to query for
filenames, obviating the need to download Contents files before you can
search. Unfortunately, dde.debian.net is down and we, the apt-file
maintainers, got reports that therefore, rapt-file has become useless.

I've talked briefly with Enrico, DDE's developer, and he indicated he
doesn't have time to bring it back to life. Therefore my question: is
there someone interested to bring this service back to Debian? There's
lots of information linked from https://wiki.debian.org/DDE.

If you are, please keep us, the apt-file maintainers, posted. Our only
alternative is probably to remove rapt-file from the package.


Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca7921fafba5f05d5197158698727dc9.squir...@aphrodite.kinkhorst.nl

Re: Trimming priority:standard

[Matthias Urlichs]

Hi,

Jonathan Dowland:
> On Fri, Sep 12, 2014 at 03:49:11PM +0200, Thorsten Glaser wrote:
> > bc is the standard Unix calculator, normally a dc frontend,
> > and used in *a lot* of scripts.
> 
> Is there any way of verifying or even reasonably estimating how common it is
> used?  *Within* debian, sadly it's hard to ascertain via codesearch as 'bc' is
> too short, but /bc => http://codesearch.debian.net/search?q=%2Fbc
> 
> I must admit I've never seen it used in 3rd party scripts in my entire career
> as a sysadmin.
> 
I've seen lots of it, in old scripts which need(ed) to work[*] without the
benefit of POSIX-shell-isms, let alone bash-.

[*] For some value of "work". They tend to plod along without regard for
error conditions.
bash's "set -o pipefail" should have been the default from the
beginning. But I digress.

> > And yes, bc is also the primary interactive calculator,
> > for things beyond what $((…)) can do.
> 
> We've got python in priority:standard.
> 
And perl, which has the advantage of an '-e' switch.

Or [m]awk, which is even Required (is there still a reason for that?).

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915161647.ga2...@smurf.noris.de

Re: Can a leaf package require SSE2 on i386?

[Colin Watson]

On Sun, Sep 14, 2014 at 04:40:14PM +0200, Adrien Clerc wrote:
> I'm in the category of people who installed their Debian 8 years ago, on
> an old AMD processor, only i686. My hardware was upgraded since, but the
> system remains. I've searched for cross-grade, but nothing serious comes
> out, except "reinstall everything". If you have some clear documentation
> (at least some steps, I'm curious enough to read some apt manuals), I
> think you can go on dropping i386 architecture.

It can be done if you are competent and confident.  I successfully
crossgraded a production system from i386 to amd64 a while back, roughly
following the steps from this blog post:

  
http://blog.zugschlus.de/archives/972-How-to-amd64-an-i386-Debian-installation-with-multiarch.html

The system in question was originally installed in 1999 (with potato, I
think) and has been contiuously upgraded since then.

Caveats from my experience, though:

 * I was doing this on a server, not a desktop.

 * I put some effort into removing obsolete or unnecessary packages
   first and making sure that amd64 versions of all my non-Debian
   packages were available, in order to simplify things.  This procedure
   is much easier to execute on a system whose package database is nice
   and clean.

 * I started out by cloning the relevant parts of the system into a
   chroot, disabling daemon startup, and upgrading that, until I'd got
   far enough that I was comfortable I could finish the job.

 * I did this on a stable release.  Doing this in testing or unstable
   where it's more likely that the archive might introduce new versions
   of Multi-Arch: same packages part-way through the job would have been
   rather more exciting.

 * I know dpkg and apt very well, was a contributor to the multiarch
   design, and am comfortable recovering things by hand if necessary.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915165025.ga12...@riva.ucam.org

Re: Trimming priority:standard

[Bob Proulx]

James McCoy wrote:
> I keep contemplating packaging ex-vi and advocating to replace vim-tiny
> with that.  After all, the intent is to have something providing
> /usr/bin/vi, as one expects to have on a *nix system, so why not have it
> actually be vi?

The package is already done.

  apt-cache show nvi

Bob


signature.asc
Description: Digital signature

Re: Can a leaf package require SSE2 on i386?

[Håkon Alstadheim]

On 15. sep. 2014 18:50, Colin Watson wrote:

On Sun, Sep 14, 2014 at 04:40:14PM +0200, Adrien Clerc wrote:

I'm in the category of people who installed their Debian 8 years ago, on
an old AMD processor, only i686. My hardware was upgraded since, but the
system remains. I've searched for cross-grade, but nothing serious comes
out, except "reinstall everything". If you have some clear documentation
(at least some steps, I'm curious enough to read some apt manuals), I
think you can go on dropping i386 architecture.

It can be done if you are competent and confident.  I successfully
crossgraded a production system from i386 to amd64 a while back, roughly
following the steps from this blog post:

  


Lacking competence, dumb luck and stable power for ~48 hrs will also 
work :~ .


For production systems, cross-grade is still a bad idea, if only because 
you MUST plan for extended down-time, Cross-grade can be made to work on 
non-mission-critical boxes.


This message is proof of that. :->.  dpkg has cross-grade working. apt 
can be pressed into use by "apt-get install --reinstall" .


Of course, if you do not use the appropriate tools for the job, you MUST 
have sufficient sed, awk and perl -fu.


I had grep failing for a while,  which made some .debs uninstallable. A 
large cache of downloaded .debs helps.  I was also happy that I 
remembered seeing some android phones using 8.8.8.8 for recursive DNS, I 
never paid attention to what my ISP gives out. Then network at home 
(apart from the phones) was out for a couple of hours until I got bind 
working again.


My system got a good rinse from it. Now there are hardly any packages 
from squeeze left, and the last SuSE 6.4 binaries got the boot :) (Now 
THAT was a truly painful transition, back in the day).


This guide http://www.ewan.cc/?q=node/90 looks quite safe. If I had 
followed it I guess the pain would have been less  than my route. 
Minimum requirement for reducing hassle is to make sure your existing 
i386 packages are the same version as the amd64 you will be replacing 
them with. Barring that you need to forcibly purge the old and insert 
then new, while keeping a running system.


I also remembered about postgresql being fussy about bit-width too late, 
so I had to install a 32-bit chroot to get a fresh export from the 
entire install. Having a dump of the databases is well and good, but you 
ned the "roles" aswell. postgres-32-bit will NOT run on 64-bit 
libraries. RRD-databases are the same, so having a chroot ready for 
stuff like that is probably wise no matter how well you plan things.






--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54172fa0.50...@alstadheim.priv.no

Re: Trimming priority:standard

[James McCoy]

On Mon, Sep 15, 2014 at 10:56:16AM -0600, Bob Proulx wrote:
> James McCoy wrote:
> > I keep contemplating packaging ex-vi and advocating to replace vim-tiny
> > with that.  After all, the intent is to have something providing
> > /usr/bin/vi, as one expects to have on a *nix system, so why not have it
> > actually be vi?
> 
> The package is already done.
> 
>   apt-cache show nvi

That's an odd answer to "why not have it actually be vi?".  Sure, nvi is
a vi-clone, but it's not the actual vi.  Whether that really matters
much to anyone is a different question.

It's worth noting that nvi was the package that previously filled the
role for providing /usr/bin/vi, before vim-tiny replaced it.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915194645.go26...@freya.jamessan.com

Re: Trimming priority:standard

[Bob Proulx]

James McCoy wrote:
> Bob Proulx wrote:
> > James McCoy wrote:
> > > I keep contemplating packaging ex-vi and advocating to replace vim-tiny
> > > with that.  After all, the intent is to have something providing
> > > /usr/bin/vi, as one expects to have on a *nix system, so why not have it
> > > actually be vi?
> > 
> > The package is already done.
> > 
> >   apt-cache show nvi
> 
> That's an odd answer to "why not have it actually be vi?".  Sure, nvi is
> a vi-clone, but it's not the actual vi.  Whether that really matters
> much to anyone is a different question.

I guess as to whether it is the actual vi or not depends upon your
perspective.  vi was developed by Bill Joy released with BSD.  But due
to the licensing of Unix system BSD rewrote all of the license
encumbered code for BSD.  nvi replaced vi on BSD systems.  From my
memory I also remember one of the problems was the vi crypto included
in the original vi code which back-in-the-day prevented vi from being
exported.  The crypto code was not included in nvi.

Soo...  If you are a BSD person then nvi is the "real" vi.

> It's worth noting that nvi was the package that previously filled the
> role for providing /usr/bin/vi, before vim-tiny replaced it.

Feature creep?

Bob


signature.asc
Description: Digital signature

Bug#761704: ITP: aprx -- APRS iGate + digipeater

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: aprx
  Version : 2.08.593
  Upstream Author : Matti Aarnio, OH2MQK
* URL : http://ham.zmailer.org/oh2mqk/aprx/
* License : BSD-3-clause
  Programming Lang: C
  Description : APRS iGate + digipeater

An APRS digipeater and gateway to APRS-IS with minimal footprint and
support for KISS and TNC2 TNCs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140915195842.12325.85077.report...@lepton.shiftout.net

Re: Trimming priority:standard

[Jonas Meurer]

Am 13.09.2014 um 12:58 schrieb Didier 'OdyX' Raboud:
> Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit :
>> Theodore Ts'o 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".
>>
>> Or we could just call it "standard system".
> 
> Could we make sure the full "vim" is in that then? I miss it on every 
> new installation and I'm quite sure that's not uncommon.

At least vim-tiny should provide /usr/bin/vim, so a 'vim' executable is
actually available on the "standard system". I would be fine with the
stripped-down vim from vim-tiny if at least 'vim ' would work.
At the moment I pretty often end up either installing full vim or
replacing 'vim' with 'vim.basic' on the commandline.

 jonas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/541746ec.2020...@freesources.org

Subject=Re: Can a leaf package require SSE2 on i386?

[Barak A. Pearlmutter]

The package "ikarus", another programming language implementation,
also requires SSE2 support.
There is a check in the preinst script which aborts installation if
sse2 is unavailable.

case "$1" in
install|upgrade)
if egrep -q '^flags[[:space:]]*:.*\bsse2\b' /proc/cpuinfo; then
# echo CPU instruction set extension sse2 confirmed
true
else
echo "error: CPU flag sse2 not found, aborting installation"
exit 1
fi
;;

Cheers,

--Barak.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANa01B+3oeZjFtTm=-t+herqb29ag-4uvfu3j8henfxto1h...@mail.gmail.com

Re: Trimming priority:standard

[Russ Allbery]

Bob Proulx  writes:
> James McCoy wrote:

>> I keep contemplating packaging ex-vi and advocating to replace vim-tiny
>> with that.  After all, the intent is to have something providing
>> /usr/bin/vi, as one expects to have on a *nix system, so why not have
>> it actually be vi?

> The package is already done.

>   apt-cache show nvi

Note that nvi is orphaned in Debian and appears to be somewhat moribund
upstream, and we're carrying a large number of patches for it.  The
package could definitely use some love, if anyone feels like diving in,
probably both upstream and Debian (but definitely Debian) could use help.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq94obit@hope.eyrie.org

New package tracker - old one going?

[Iain R. Learmonth]

Hi,

I notice that packages.qa.debian.org is advertising the new package tracker.
Does this mean the old package tracker there is going to disappear?

I was going to build something for tracking team packages using the RDF
generated by the tracker at packages.qa.debian.org but if it's going to
disappear I'll have to find another way.

Thanks,
Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpIcI1OaHXvv.pgp
Description: PGP signature

Re: Can a leaf package require SSE2 on i386?

[Samuel Thibault]

Thomas Goirand, le Mon 15 Sep 2014 20:45:27 +0800, a écrit :
> On 09/15/2014 05:17 PM, Samuel Thibault wrote:
> > Thomas Goirand, le Mon 15 Sep 2014 16:53:25 +0800, a écrit :
> >> I suppose (according to what's above) that using
> >> /usr/lib/sse4.2/x86_64-linux-gnu isn't supported (yet), right?
> > 
> > I guess it shouldn't be hard to add the support, once the need is
> > expressed :)
> > 
> > Samuel
> 
> Really? Ok... then *I NEED IT* ! :)

As a bug report against libc6, I meant.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140915230525.ga2...@type.youpi.perso.aquilenet.fr

Re: Trimming priority:standard

[Santiago Vila]

On Mon, Sep 15, 2014 at 06:16:47PM +0200, Matthias Urlichs wrote:
> And perl, which has the advantage of an '-e' switch.
> 
> Or [m]awk, which is even Required (is there still a reason for that?).

AWK is mentioned in the Single UNIX Specification as one of the
mandatory utilities of a Unix operating system.

Moreover, we made perl to be essential. As James Troup once said,
"to not to do it also for good old awk would be criminal".

https://lists.debian.org/debian-policy/1998/02/msg00180.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916003146.ga9...@cantor.unex.es

Re: Trimming priority:standard

[Martin Eberhard Schauer]

I wonder whether the POV in this discussion is right. I have the impression
that the discussion is about the removal of "old" packages.

Squeeze had 91 standard packages, now there are 108. The latest one:
doc-debian. When libsqlcipher0 (1) hit standard I also had doubts that its
functionality justifies the standard criteria (2).

1: https://packages.debian.org/sid/libsqlcipher0
2: https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54178f03.90...@gmx.de

Re: Trimming priority:standard

[James McCoy]

On Mon, Sep 15, 2014 at 10:07:08PM +0200, Jonas Meurer wrote:
> Am 13.09.2014 um 12:58 schrieb Didier 'OdyX' Raboud:
> > Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit :
> >> Theodore Ts'o 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".
> >>
> >> Or we could just call it "standard system".
> > 
> > Could we make sure the full "vim" is in that then? I miss it on every 
> > new installation and I'm quite sure that's not uncommon.
> 
> At least vim-tiny should provide /usr/bin/vim, so a 'vim' executable is
> actually available on the "standard system". I would be fine with the
> stripped-down vim from vim-tiny if at least 'vim ' would work.

Many people were not fine with that and complained about unexpected
behavior (i.e., their normal vim config blowing up in their face) when
running "vim" from vim-tiny.  That's why I made the choice to have
vim-tiny stop providing the /usr/bin/vim alternative.  You can see more
discussion about my stance in #681012 and related bug reports referenced
therein.

As I said in my other reply, the intent of vim-tiny is to provide a vi
command.  The fact that it is using Vim to do so is the means, not the
end.

> At the moment I pretty often end up either installing full vim or
> replacing 'vim' with 'vim.basic' on the commandline.

Which is fine, because you actually want something that behaves like
most people would expect Vim to, not something that behaves more like
vi.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Re: Trimming priority:standard

[Marco d'Itri]

On Sep 16, James McCoy  wrote:

> As I said in my other reply, the intent of vim-tiny is to provide a vi
> command.  The fact that it is using Vim to do so is the means, not the
> end.
I think it's more complex than this: I like vim-tiny because I can use 
it on small images without wasting space for the dependencies, and after 
setting nocompatible it's as much as good as regular vim for system 
administration tasks.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Trimming priority:standard

[James McCoy]

On Tue, Sep 16, 2014 at 03:54:21AM +0200, Marco d'Itri wrote:
> On Sep 16, James McCoy  wrote:
> 
> > As I said in my other reply, the intent of vim-tiny is to provide a vi
> > command.  The fact that it is using Vim to do so is the means, not the
> > end.
> I think it's more complex than this: I like vim-tiny because I can use 
> it on small images without wasting space for the dependencies, and after 
> setting nocompatible it's as much as good as regular vim for system 
> administration tasks.

The very informed/knowledgeable user isn't the one that soured my
perception of the choice to have vim-tiny provide /usr/bin/vim.  It's
rather the people that know enough to get by on Vim and be comfortable
installing various plugins, but don't really delve much deeper into Vim.
They setup a new computer, deploy their dotfiles somehow, run vim and
then see things not working because only vim-tiny is installed, so a bug
gets filed.

So while I agree that being able to "flip the switch" to have
/usr/bin/vi act more like a typical Vim install for that editing session
is useful, I don't agree the same to be true about vim-tiny also
providing /usr/bin/vim.  A standard install provides /usr/bin/vi and if
you happen to know it's provided via a stripped down build of Vim, then
feel free to take advantage of that.  Otherwise, actively install Vim to
get what is going to behave as expected.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Re: Subject=Re: Can a leaf package require SSE2 on i386?

[Vincent Danjean]

On 15/09/2014 22:28, Barak A. Pearlmutter wrote:
> The package "ikarus", another programming language implementation,
> also requires SSE2 support.
> There is a check in the preinst script which aborts installation if
> sse2 is unavailable.
> 
> case "$1" in
> install|upgrade)
> if egrep -q '^flags[[:space:]]*:.*\bsse2\b' /proc/cpuinfo; then
> # echo CPU instruction set extension sse2 confirmed
> true
> else
> echo "error: CPU flag sse2 not found, aborting installation"
> exit 1
> fi
> ;;

If this hack is really here, a bug should be filled. It is really a
pain when something breaks when installing (or upgrading) a bunch of
packages. This check should be moved at runtime. At install time,
display a debconf notice if you really want to, but do not
abruptly stop the installation without a really good reason (even
when you try to remove the running kernel, perhaps leading to un
unbootable system, you have the choice to abort or not)

  Regards,
Vincent

> 
> Cheers,
> 
> --Barak.
> 
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5417ddb1.1060...@free.fr

Re: New package tracker - old one going?

[Paul Wise]

On Tue, Sep 16, 2014 at 5:15 AM, Iain R. Learmonth wrote:

> I notice that packages.qa.debian.org is advertising the new package tracker.
> Does this mean the old package tracker there is going to disappear?

It will go away eventually once the new tracker has equivalent functionality.

> I was going to build something for tracking team packages using the RDF
> generated by the tracker at packages.qa.debian.org but if it's going to
> disappear I'll have to find another way.

If you could help port the RDF work to the new tracker that would help
the transition move faster and also give you a reliable source of data
for both Debian and derivatives who also use the same software.
Another option is to base your team thing on UDD.

https://udd.debian.org/

BTW we already have several team things, could you just use those?

http://pet.debian.net/
https://udd.debian.org/dmd.cgi
https://tracker.debian.org/teams/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6f3fvrv_+8phghra_hn8p-pgdxmkh_aylczbf7k-fl...@mail.gmail.com