Re: Bug#648896: ITP: kup -- kernel.org upload tool

[Reinhard Tartler]

On Mi, Nov 16, 2011 at 00:05:58 (CET), Ben Hutchings wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Ben Hutchings 
>
> * Package name: kup
>   Version : 0.2
>   Upstream Author : H. Peter Anvin 
> * URL : git://git.zytor.com/users/hpa/kup/kup.git

The URL is not a website. I haven't seen seen git:// urls in other
package descriptions yet, but
http://git.zytor.com/?p=users/hpa/kup/kup.git;a=summary would have made
it easier, I think.

> * License : GPLv2+
>   Programming Lang: Perl
>   Description : kernel.org upload tool
>
> This utility is used to upload files to kernel.org and other
> systems using the same upload system (kup-server).  Each upload
> is required to have a PGP signature, and the server will generate
> multiple compressed formats if the content uploaded is intended to be
> compressed.

Do you intend to package kup-server as well? It seems to be included in
the same sources after all, but you don't mention it in the package
description.

Cheers,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
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/87vcqkk3yy@faui43f.informatik.uni-erlangen.de

Re: Bug#648896: ITP: kup -- kernel.org upload tool

[Ben Hutchings]

On Wed, 2011-11-16 at 06:53 +0100, Reinhard Tartler wrote:
> On Mi, Nov 16, 2011 at 00:05:58 (CET), Ben Hutchings wrote:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ben Hutchings 
> >
> > * Package name: kup
> >   Version : 0.2
> >   Upstream Author : H. Peter Anvin 
> > * URL : git://git.zytor.com/users/hpa/kup/kup.git
> 
> The URL is not a website. I haven't seen seen git:// urls in other
> package descriptions yet, but
> http://git.zytor.com/?p=users/hpa/kup/kup.git;a=summary would have made
> it easier, I think.

Maybe I'll do something like that.  It turns out that the canonical
location is the repository on git.kernel.org, by the way.

> > * License : GPLv2+
> >   Programming Lang: Perl
> >   Description : kernel.org upload tool
> >
> > This utility is used to upload files to kernel.org and other
> > systems using the same upload system (kup-server).  Each upload
> > is required to have a PGP signature, and the server will generate
> > multiple compressed formats if the content uploaded is intended to be
> > compressed.
> 
> Do you intend to package kup-server as well? It seems to be included in
> the same sources after all, but you don't mention it in the package
> description.

Yes.  The packaging is already committed at
.  I'm waiting for
the Perl transition to clear before uploading.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


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

Re: libconfig9 for Wheezy?

[Reinhard Tartler]

CC'ing mentors, as this issue seems to be blocked by a missing sponsor.

On Mi, Nov 16, 2011 at 00:20:16 (CET), Jose Luis Tallón wrote:

> El 15/11/11 19:29, Ben Hutchings escribió:
>> On Tue, Nov 15, 2011 at 06:15:48PM +, Jonathan McCrohan wrote:
>>> Hi,
>>>
>>> libconfig [1] has not been updated since Squeeze, and is lagging
>>> upstream by a major version.
>>>
>>> Packaging the upstream release is not a problem, but an ABI change will
>>> require a transition from libconfig8 to libconfig9.
>>>
>>> The maintainer is aware of the problem, and this has been tracked as
>>> wishlist bug #583528 since May 2010 [2].
> Any sponsor / uploader welcome.
> It isn't updated because nobody agreed to upload it, and I gave up

I don't see the new version of the package on mentors. Please consider
uploading your new package there, it will then show up on
http://packages.qa.debian.org/libc/libconfig.html in the 'todo' box
AFAIUI.

Moreover, as this upload requires a transition, you'll need to
coordinate with the release team. These days, such transitions are
tracked in form of bugs against the 'release.debian.org' pseudo package:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org;dist=unstable#_0_6_4

HTH,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
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/878vngljid@faui43f.informatik.uni-erlangen.de

Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

[Jonathan Nieder]

Wolfgang Tichy wrote:

> Thanks for your answer. I think the intel compiler does support the -B
> and -I options. So I think your suggestion would work. However, I am
> not sure if I like this solution.

It's only a workaround.  A fix would involve contacting the Intel
developers to get icc to search the new paths by default.

> I always loved debian for the fact
> that libraries and include files were in standard places (unlike say
> in redhat based distributions). So it was always easy to compile with
> any compiler.

Yes, I understand.

> Moving them to other places seems to complicate things.
> I mean I am no expert on multiarch and guess there are good reasons
> for that. But why can't there be symlinks to the files you need for
> your own architecture in standard places? Would that break something?

There are two sides to that question: would adding such symlinks be
feasible?  And would the resulting behavior of the system be desirable?

Compatibility symlinks for multiarch: the use case
--

Let's take the second question first.  If /usr/lib and /usr/include
were filled with symlinks to the corresponding architecture-specific
files for the native architecture, there would be some nice benefits:

 - multiarch-unaware compilers would continue to work
 - programs hard-coding paths to libraries would continue to work

On the other hand, binaries and builds for foreign architectures
would be likely to misbehave when libraries for that arch are missing
(/usr/lib//foo.so is missing and /usr/lib/foo.so is not).  So
for someone using only multiarch-aware programs, the net effect is
negative.

Compatibility symlinks for multiarch: feasibility
-

Now the first question.  In wheezy, packages that are marked as such
can be installed on multiple architectures at once.  So, for example,
I can install the i386 and the amd64 versions of libavcodec at the
same time.

Which package would get to put a symlink to its library in /usr/lib?

It's tempting to say "the native one", but it is not always clear
which one that is.  In fact, one of the goals of multiarch is to be
able to (gradually) upgrade an i386 system to an amd64 one.  At what
point has the native architecture switched?

A proposal
--

The above suggests to me a possible way forward.  To be clear, I do
not want to work on this; this is just a sketch of one way that people
who do want to work on it could try.

The idea is that there would be a separate package that installs
compatibility symlinks pointing to /usr/lib//* and
/usr/include//* to help people still using multiarch-unaware
tools.

Its post-installation script would be a simple script that scans
/usr/lib/ and /usr/include/ for added or removed
libraries and updates the corresponding symlinks in /usr/lib and
/usr/include.  Using triggers (see [1]) it would ensure that this
script is run for each apt run in which a file is installed to or
removed from /usr/lib/ or /usr/include/.

This compatibility package could be removed at any time and
multiarch-aware packages would continue to work.

(Based on an idea from Matthias Klose[2].)

Of course, I would be even happier to see tools like icc learn about
the new paths.

Hope that helps,
Jonathan

[1] /usr/share/doc/dpkg-dev/triggers.txt.gz
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=634821

> Thanks,
> Wolfgang
>
> PS: I do not mean to complain. I think Debian is great and I am
> grateful for the job you maintainers do. I only write because I like
> Debian, and thought this might be helpful...



-- 
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/2016035012.ga5...@elie.hsd1.il.comcast.net

Bug#648909: ITP: phlipple -- reduce 3D shapes to a single square

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz 


* Package name: phlipple
  Version : 0.8.2
  Upstream Author : Remigiusz Dybka 
* URL : http://phuzzboxmedia.com/games/phlipple
* License : GPL 3.0 or above
  Programming Lang: C
  Description : reduce 3D shapes to a single square

 Phlipple is a unique puzzle game. The goal of every level is to reduce
 a 3D shape to a single square. Elimination of squares is done by flipping
 edges around just like in a cardboard box. It starts off relatively easy
 to teach the basics just to later on serve hours of brain tickling fun.
 It's a great way to train memory as well as orientation in 3D.



-- 
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/2016030322.3855.80392.reportbug@danu.local

Re: /tmp as tmpfs and consequence for imaging software

[John D. Hendrickson and Sara Darnell]

I still think that is disagreeing with thought using /tmp is a bad idea is a good idea and agree 
with the people who are against.


debian-devel@lists.debian.orgAneurin Price wrote:

On 15 November 2011 08:17, Neil Williams  wrote:




Do not cripple all platforms with the sins of the weakest.


Microsoft did and still does CREATE incompatibility to kill any competition.  Get with the program 
they are not a debian "friend" they run people over quite readily.  They insert many historic in 
Wikipedia.  Visit the tomb of the lost linux users ! ?



On Tue, Nov 15, 2011 at 07:41:54AM +0100, Andrew Shadura wrote:
1KB // Yo momma uses IPv4!

Anything IPv6 does 32bit IPv4 can do ALLOT BETTER.  where's the promised permanent IPs.  why do they 
now have so much more control?  they planned it.




If you want highly specialized caching write code.  If are not sure if the cache is invalidated 
maybe you should be doing things another way.  It's quite complicated bsd about bit off more than 
they can chew already, considering hardware has similar and complicated paging blocking caching etc 
etc etc issues hacking these simply isn't a good idea.


ta ta, have a good day all !


--
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/4ec2f578.9080...@cox.net

perl transition underway; breakage with libjson-pp-perl

[Dominic Hargreaves]

On Sun, Nov 13, 2011 at 01:59:19PM +, Dominic Hargreaves wrote:
> As per #637809, I plan to upload perl 5.14 to unstable soon (maybe today,
> depending on how some last bits of testing go). Like last time, this
> will mean that a large number (~ 470) of packages will need to be binNMUed
> by the release team. I'm sure they would appreciate uploads for these
> packages being avoided once the rebuilds start, so that the transition
> isn't interrupted, so I hope that this heads-up is useful. If this is
> likely to cause any serious problems for anyone, let me know ASAP.

As you've probably noticed, the transition is underway. There is an
unanticipated file conflict between the new perl package and
libjson-pp-perl. Fixed packages are being prepared; if you have
libjson-pp-perl installed, I suggest waiting until a fixed version of
libjson-pp-perl and perl has been uploaded before dist-upgrading your
sid systems. See #648893 and #648897 for more details.

Thanks,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


-- 
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/2015233038.gu4...@urchin.earth.li

Re: libconfig9 for Wheezy?

[Jose Luis Tallón]

El 15/11/11 19:29, Ben Hutchings escribió:

On Tue, Nov 15, 2011 at 06:15:48PM +, Jonathan McCrohan wrote:

Hi,

libconfig [1] has not been updated since Squeeze, and is lagging
upstream by a major version.

Packaging the upstream release is not a problem, but an ABI change will
require a transition from libconfig8 to libconfig9.

The maintainer is aware of the problem, and this has been tracked as
wishlist bug #583528 since May 2010 [2].

Any sponsor / uploader welcome.
It isn't updated because nobody agreed to upload it, and I gave up 
eventually.




Is there enough time left to have this updated before the Wheezy freeze
window?


Very likely, but release questions should be sent to debian-release.

Yup.

/ J.L.


--
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/4ec2f3b0.8020...@adv-solutions.net

Bug#648896: ITP: kup -- kernel.org upload tool

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings 

* Package name: kup
  Version : 0.2
  Upstream Author : H. Peter Anvin 
* URL : git://git.zytor.com/users/hpa/kup/kup.git
* License : GPLv2+
  Programming Lang: Perl
  Description : kernel.org upload tool

This utility is used to upload files to kernel.org and other
systems using the same upload system (kup-server).  Each upload
is required to have a PGP signature, and the server will generate
multiple compressed formats if the content uploaded is intended to be
compressed.



-- 
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/2015230558.20771.33239.report...@shadbolt.decadent.org.uk

Processed: Re: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # affects most development libraries, not just libc
> reassign 648889 general
Bug #648889 [libc6-dev] /usr/include/features.h(323): catastrophic error: could 
not open source file "bits/predefs.h"
Bug reassigned from package 'libc6-dev' to 'general'.
Bug No longer marked as found in versions eglibc/2.13-21.
> forcemerge 637232 648889
Bug#637232: general: Multiarch breaks support for non-multiarch toolchain
Bug#648889: /usr/include/features.h(323): catastrophic error: could not open 
source file "bits/predefs.h"
Bug#639214: eglibc: changes to paths concerning crt1.o, crti.o and crtn.o 
breaks building LLVM Trunk
Bug#644986: i386: Compiling gcc-snapshots from upstream with 
multiarch-toolchain?
Forcibly Merged 637232 639214 644986 648889.

> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
644986: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644986
648889: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889
637232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232
639214: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639214
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132139440612194.transcr...@bugs.debian.org

Re: /tmp as tmpfs and consequence for imaging software

[bastien ROUCARIES]

Le Monday 14 November 2011 00:14:18, Josselin Mouette a écrit :
> Le dimanche 13 novembre 2011 à 23:20 +0100, Bastien ROUCARIES a écrit :
> > No it does not work like you said. We know the matrix structure, not
> > the kernel. We map and unmap manually. Doing as you said is
> > inneficient and trash a lot cache and so on.
> 
> This is getting insane. Please learn how to use madvise and
> posix_fadvise and let the kernel deal with paging. The kernel knows
> everything about the underlying hardware; the application does not.

Yes I do it with  MADV_DONTNEED when needed. And the kernel do not know when to 
use MADV_DONTNEED on 16MB block and as you said I 
have performance enhancement (but we should take in account system call cost). 

> 
> > Memory is used as a cache. This is not broken. This a valid use.
> 
> By paging the data manually to the disk, the only thing you are
> achieving is duplicating it at the time of reading/writing. Please learn
> how to use memory pages and stop telling people you know better when it
> is obvious you don’t know what you are talking about.

Thanks


--
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/20151123.12073.roucaries.bast...@gmail.com

Re: Using Qt debug libraries without configure and qmake

[Simon McVittie]

On Tue, 15 Nov 2011 at 19:02:48 +, Neil Williams wrote:
> Fix the rest of the flags. In most cases, what you're thinking of as
> the "release" build may actually contain debug symbols which dh_strip
> would then put into a dbg package. What matters (the only thing
> which matters) is exactly what is passed to g++.

Some packages/build systems do distinguish between a "debug" and "release"
build, and actually compile different code for the two (e.g. python2.7-dbg
has a lot of reference-count-debugging goo which just doesn't exist in
python2.7), or do things like changing the level of optimization.
I believe this is particularly popular in things originating on Windows
(iirc MSVC++ has release- and debug-mode runtime libraries, which are not
the same).

For instance, the "release" version might build with -NDEBUG
(disable assert(3)), -DG_DISABLE_ASSERTS (the equivalent for GLib), or even
-DG_DISABLE_CHECKS (the "break my app" flag). In some packages (like Python),
the debug version even has a different ABI (again, for the intrusive
reference-count-debugging stuff, which makes all your objects a bit larger).

I personally think this sort of thing should be avoided wherever possible -
not least because you run the risk of having bugs that can be reproduced
with the release version but not the debug version - but it's something that
happens, unfortunately including packages I maintain.

In Debian, we build everything with debug symbols (-g), but usually using the
code paths that would normally be considered a "release" version.

CMake formalizes this by having "Debug", "Release" and "RelWithDebInfo"
values for CMAKE_BUILD_TYPE: the one normally used in Debian is
RelWithDebInfo.

S


-- 
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/2015192610.gb29...@reptile.pseudorandom.co.uk

Re: Using Qt debug libraries without configure and qmake

[Neil Williams]

On Tue, 15 Nov 2011 19:12:10 +0100
Malte Forkel  wrote:

> I need your advise on how to deal with the way Debian packages the debug
> version of Qt libraries.

Debugging symbols exist in the libqt4-dbg package.

When building your own code, it is just a case of ensuring that the
flags are passed to the compiler, as normal. It has nothing to do with
pkg-config. The Makefile is broken. Check the actual output using
objdump and file.

When building packages for Debian, it's down to debian/rules and
arguments to dh_strip. Check the source of any number of dbg packages
already in Debian.

> I'm trying to package an existing software that includes a small Qt
> application. The software is not using autotools or qmake but fixed
> Makefiles. Building the release version is accomplished by lines like
>CXXFLAGS += $(shell pkg-config --cflags QtCore)
>LIBS +=  $(shell pkg-config --libs QtCore)
> Building the release version of the sofware works fine.

Those lines have no effect on whether the debug or release version is
built. That comes down to the use of strip - and you always want the
debug symbols in every build, let the Debian packaging sort out the
rest.

> Alternatively, when building a debug version, the above lines are
> replaced by
>CXXFLAGS += $(shell pkg-config --cflags QtCore_debug)
>LIBS +=  $(shell pkg-config --libs QtCore_debug)

Broken. There is no such .pc file for pkg-config, hence the errors.
Don't build a "release" and "debug" version, it makes no sense. There
is one version which gets stripped to retain the debug symbols in a
useful manner.

Fix the rest of the flags. In most cases, what you're thinking of as
the "release" build may actually contain debug symbols which dh_strip
would then put into a dbg package. What matters (the only thing
which matters) is exactly what is passed to g++.

When building for local development, always retain the debug symbols to
make life easier. Then when building a package, let the normal Debian
packaging rules retain the debug symbols until dh_strip is called to
put the detached symbols into the -dbg package.

Don't strip in the upstream build. Just don't. Ever.

What you think of as a "release" build is just broken.

> I have installed libqtcore4, libqt4-dev and libqt4-dbg in the build
> environment. Looking at the files in these packages, I noticed that they
> provide /usr/lib/libQtCore.so.4.4.3 and
> /usr/lib/libQtCore.so.4.4.3.debug, but not
> /usr/lib/libQtCore_debug.so.4.4.3. Also, there is

Check the contents of libqt4-dbg with 'dpkg -L libqt4-dbg' - that's
where the symbols live, exactly where gdb expects to find them. That's
the only useful thing to do with debug symbols anyway - let gdb find
them.

/usr/lib/debug/usr/lib/libQtGui.so.4.7.3
/usr/lib/debug/usr/lib/libQtCore.so.4.7.3
etc.

> What should I do to specify that the debug versions of the libraries are
> used?

You don't. You build your software with debugging symbols and then gdb
finds the debug symbols from the dbg packages directly. Packaging takes
care of the rest.

g++ -c -pipe -I../lib -g -I/usr/include/
Building with debugging symbols intact for later extraction via
dh_strip or use directly in gdb

$ file lib/libtextwidget.so.2.1.0 
lib/libtextwidget.so.2.1.0: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, BuildID
[sha1]=0xaca25b93845a468cc3f696cd7b796ada47d89226, not stripped

Clearly indicates that the debug symbols are available.

$ gdb ./bin/textwidget
Reading symbols
from /.../textwidget/bin/textwidget...done.
(gdb) 



-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp9ovBRygp5u.pgp
Description: PGP signature

Re: Sharing data between maintainer scripts and debian/rules

[Goswin von Brederlow]

Neil Williams  writes:

> We've a few native packages which handle data in package-specific
> directories under /var/lib/. It would be convenient to specify the name
> of this directory in debian/rules as a -D define to the compiler
> (because it's native) and then pass that into the relevant maintainer
> scripts, postinst and postrm. (We could use a prerm if appropriate.)
>
> So rather than copying the directory name in various places in the
> debian/ directory, I was wondering if there's a simple way to feed a
> variable into the maintainer scripts from debian/rules (which in turn
> could set the variable according to DEB_BUILD_OPTIONS and
> dpkg-architecture query results). We could use a file in /etc/ but that
> seems to just move the problem elsewhere and we could use a hidden
> debconf value but that just adds complexity to the postinst itself.

The maintainer scripts aren't (usualy) build so you can't pass anything
from the build environment into them. If you do need/want to do this you
need to "build" those script in some form or another. For example I have
the following in a few cases (from memory):

debian/%: debian/%.in
sed 's/@VERSION@/$(VERSION)/g' < $+ > $@

binary-arch: debian/foo.postinst debian/foo.prerm

clean:
rm -f debian/foo.postinst debian/foo.prerm


Don't use a conffile for this. The file would only confuse users, tempt
them to edit the file and then what would your programm and maintainer
scripts do? That only invites chaos.

> The implementation is embedded, so unnecessary clock cycles (retrieval
> from debconf) need to be avoided and the chances of a config file being
> edited are slim (i.e. only during development) - there is no user login
> and no user access. There is no python interpreter on-device and the
> perl-modules package is not installed, so only the base perl interpreter
> is present. Retrieving this variable on-device is therefore less than
> appealing, the value needs to be in the postinst script that actually
> ends up in the binary package.

Alternatively to the above, where every maintainer script has to be
build, you could add a single common file and source that in all
maintainer scripts. This would involve querying dpkg for the location of
maintainer scripts so it would add some overhead at install time.

> Other than using sed and awk during the build on a package-specific
> basis with all the potential for typos, is there a wider use case for
> dissemination of variables from debian/rules into maintainer scripts? I
> guess it's an extension of the #DEBHELPER# mechanism, which being on
> the build system means that a lot more tools would be available.

Maybe debhelper could add support for this, doing the sed for you when
it installs the maintainer scripts and replaces its own #DEBHELPER#. But
afaik there is nothing existing of that sort.

As for typos the sed commands are quite trivial and never change. So you
just write them and carefully check the result once. So I don't buy that
fear.

> Any mechanism would have to allow the old value to be identified upon a
> change to the directory, so that the old data gets cleaned out
> properly. i.e. when changed, the maintainer scripts end up handling two
> locations, cleaning the old, populating the new.
>
> There's also the possibility that the process needs to be
> architecture-sensitive, i.e. the armel postinst might need to behave
> differently from i386 because the armel device can do things which you
> don't want a desktop to do (like suspend automatically). This is
> relatively simple to do with some conditionals in debian/rules.

For that there are provisions:

man 1 dpkg

   DPKG_MAINTSCRIPT_PACKAGE
  Defined by dpkg on the maintainer script  environment  to
  the package name being handled.

   DPKG_MAINTSCRIPT_ARCH
  Defined  by  dpkg on the maintainer script environment to
  the architecture the package got built for.

   DPKG_MAINTSCRIPT_NAME
  Defined by dpkg on the maintainer script  environment  to
  the name of the script running (preinst, postinst, prerm,
  postrm).

> There remains the option of doing this all in the compiled code but I'm
> interested in seeing if this is something other people need to do as
> well.

MfG
Goswin


-- 
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/87fwhpqkwm.fsf@frosties.localnet

Re: Two groups of users, one distro in the middle

[John H. Robinson, IV]

Tollef Fog Heen wrote:
> ]] sean finney 
> 
> | export PATH=/usr/lib/nodejs:$PATH
> | 
> | and problem solved, right?
> 
> PATH isn't considered for #! lines, so not really.

It is if you use #!/usr/bin/env node

-- 
John H. Robinson, IV  jaq...@debian.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


-- 
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/2015182353.ga7...@a.mx.sbih.org

Re: libconfig9 for Wheezy?

[Ben Hutchings]

On Tue, Nov 15, 2011 at 06:15:48PM +, Jonathan McCrohan wrote:
> Hi,
> 
> libconfig [1] has not been updated since Squeeze, and is lagging
> upstream by a major version.
> 
> Packaging the upstream release is not a problem, but an ABI change will
> require a transition from libconfig8 to libconfig9.
> 
> The maintainer is aware of the problem, and this has been tracked as
> wishlist bug #583528 since May 2010 [2].
> 
> Is there enough time left to have this updated before the Wheezy freeze
> window?
 
Very likely, but release questions should be sent to debian-release.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/2015182919.gb3...@decadent.org.uk

Re: Description-less packages file

[Goswin von Brederlow]

Joerg Jaspert  writes:

> I just merged a patch from Ansgar to generate the Packages files without
> the English description embedded inside them. Instead they are now
> written into a new file, the "English Translation" file in
> "main/i18n/Translation-en.bz2". They thus appear alongside all other
> translated descriptions as "just another language". apt & co will (or
> should) just download those Translation files to show the description,
> as they do already for all other languages.
> This lets us save quite a bit of space on our mirrors by not repeating
> them as many times as we have architectures - and also enables
> non-English-speaking users (and eventually multi-arch enabled APT) to
> save on download size, as they no longer need to download a language
> that is of no use to them or is already there.

Thanks. This is verry much appreciated and saves doubly (triplly,
quadruply, ...) on downloads, disk space (and I assume memory too) with
multiarch.

MfG
Goswin


-- 
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/87k471qm5g.fsf@frosties.localnet

libconfig9 for Wheezy?

[Jonathan McCrohan]

Hi,

libconfig [1] has not been updated since Squeeze, and is lagging
upstream by a major version.

Packaging the upstream release is not a problem, but an ABI change will
require a transition from libconfig8 to libconfig9.

The maintainer is aware of the problem, and this has been tracked as
wishlist bug #583528 since May 2010 [2].

Is there enough time left to have this updated before the Wheezy freeze
window?

Thanks,
Jon

[1] http://packages.qa.debian.org/libc/libconfig.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583528


-- 
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/4ec2ac54.2070...@gmail.com

Re: directory under /usr/bin -- Ok or not?

[Goswin von Brederlow]

Yaroslav Halchenko  writes:

> Thank you John for extending my argument with adequate references which
> I have swallowed while  composing my question email.
>
> And if we are after reading FHS /usr/lib section:
>
> /usr/lib includes object files, libraries, and internal binaries that
> are not intended to be executed directly by users or shell scripts.
>
> and in my case it becomes more interesting -- those tools *are intended*
> to be executed by (interested) users directly.  It is just due to 
> proliferation
> in number of the tools and conflicts with other packages they cannot go under
> /usr/bin directly.

But if you have /usr/bin/foo/bar then how is the user supposed to
execute it? "foo/bar" won't work.

And if you have to type in the full path every time that would be pretty
anoying and no improvement over /usr/lib/foo/bar.


I would rather use /usr/bin/foo-bar in that case, e.g. git-import-dsc.

> That is why for this package (as for few others we maintain already) we
> are shipping also /etc/PKG/pkg.sh script so (interested) users could
> source to have their PATH adjusted to get preference to execute tools
> from the PKG instead of possibly available conflicting one under
> /usr/bin.   Wrapper script shipped directly under /usr/bin/ is only for
> possible future adoption  since at the moment all users (and their
> scripts) rely on direct names of the cmdline tools.

Adding /usr/lib/PKG to the PATH seems just a viable.

As for wrapper scripts. If you can put a wrapper script in /usr/bin then
you can just as easily just put the binary there in the first place.

> Altogether, according to FHS /usr/lib/PKG is actually not preferable
> location for them since indeed it is for solely internal use (and it is
> now used to keep shared libraries)

There you might have a point.

MfG
Goswin


-- 
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/87obwdqmdh.fsf@frosties.localnet

Using Qt debug libraries without configure and qmake

[Malte Forkel]

Hi,

I need your advise on how to deal with the way Debian packages the debug
version of Qt libraries.

I'm trying to package an existing software that includes a small Qt
application. The software is not using autotools or qmake but fixed
Makefiles. Building the release version is accomplished by lines like
   CXXFLAGS += $(shell pkg-config --cflags QtCore)
   LIBS +=  $(shell pkg-config --libs QtCore)
Building the release version of the sofware works fine.

Alternatively, when building a debug version, the above lines are
replaced by
   CXXFLAGS += $(shell pkg-config --cflags QtCore_debug)
   LIBS +=  $(shell pkg-config --libs QtCore_debug)
Building the debug version fails with errors like
   Package QtCore_debug was not found in the pkg-config search path.
   Perhaps you should add the directory containing `QtCore_debug.pc'
   to the PKG_CONFIG_PATH environment variable
   No package 'QtCore_debug' found

I have installed libqtcore4, libqt4-dev and libqt4-dbg in the build
environment. Looking at the files in these packages, I noticed that they
provide /usr/lib/libQtCore.so.4.4.3 and
/usr/lib/libQtCore.so.4.4.3.debug, but not
/usr/lib/libQtCore_debug.so.4.4.3. Also, there is
/usr/lib/pkgconfig/QtCore.pc, but no /usr/lib/pkgconfig/QtCore_debug.pc
(or /usr/lib/pkgconfig/QtCore.debug.pc). Debian seems to use its own way
of packaging the debug versions.

As far as I can tell after some looking around, this might be no problem
when using a configure and qmake. Unfortenatey, upstream does not.

What should I do to specify that the debug versions of the libraries are
used?

Thanks in advance,
Malte



-- 
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/j9ua1r$m34$1...@dough.gmane.org

Re: /tmp as tmpfs and consequence for imaging software

[Henrique de Moraes Holschuh]

On Tue, 15 Nov 2011, Aneurin Price wrote:
> I think this discussion needs a sanity check.
> 
> Please remember, the topic of conversation is whether an application
> can reasonably make the assumption that the system defined tmp
> directory is a suitable place to store temporary data.

/tmp in RAM has been extremely common on Solaris for more than 10 years
(/tmp in RAM is the default there).  I recall every SuperSPARC and
UltraSPARC box at Uni had this configuration.

IMO, it is a very clearly cut case: applications cannot reasonably make any
assumption about /tmp for any non-trivial usage, and they are to use $TMPDIR
to locate the system tmp directory in the first place if they want to use
it.

This is NOT a Debian thing.  It is not even a new requirement, it is so old
that TMPDIR has already made it into POSIX/SuS...

http://en.wikipedia.org/wiki/TMPDIR
http://en.wikipedia.org/wiki/Tmpfs

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/2015175144.ga29...@khazad-dum.debian.net

Re: Two groups of users, one distro in the middle

[Tollef Fog Heen]

]] sean finney 

|   export PATH=/usr/lib/nodejs:$PATH
| 
| and problem solved, right?

PATH isn't considered for #! lines, so not really.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87bosdnvjh@qurzaw.varnish-software.com

info please

[Richard]

Hi,
Whats the difference between dependency level 1 and dependency level 2.
I'm new to the list
Thanks

-- 
Best wishes / 73
Richard Bown

e-mail: rich...@g8jvm.com   or   richard.b...@blueyonder.co.uk

nil carborundum a illegitemis
##
Ham Call G8JVM . OS Debian Wheezy amd64 on a Dual core AMD Athlon 5200, 4 GB RAM
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W ( degs mins )
QRV HF + VHF Microwave 23 cms:140W,13 cms:100W,6 cms:10W & 3 cms:5W
##
 


-- 
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/2015162919.7b23f29e@debian

Re: Is anyone maintaining (the ham radio tool) node?

[Jonas Smedegaard]

On 11-11-09 at 08:33am, Philipp Kern wrote:
> On 2011-11-08, Patrick Ouellette  wrote:
> > I hope to avoid any issues with breaking old boxes with the eventual 
> > resolution of the issue.
> 
> I don't know what's wrong with Jonathan Nieder's advise in [0] about 
> helping users with the conversion automatically.  That's how it's 
> usually done.
> He even provided that patch.
> 
> Who would refer to the node binary as provided by the ham package node 
> except for the inetd and the ax25d superservers?  (Serious question.)

Did anyone address above question already?


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: /tmp as tmpfs and consequence for imaging software

[Philip Hands]

On Tue, 15 Nov 2011 12:34:03 +, Aneurin Price  
wrote:
...
> I think this discussion needs a sanity check.
> 
> Please remember, the topic of conversation is whether an application
> can reasonably make the assumption that the system defined tmp
> directory is a suitable place to store temporary data.

Absolutely, although at the other extreme we seem to have people
demanding that they should be able to make very specific assumptions
about what form that storage will take for all future time and how much
of their data they should be able to put on it, without needing to do
tiresome things like check first, or even checking whether it worked
afterwards.

Of course we cannot please _all_ our users with our defaults, but if
this niche software is really rendered useless by having /tmp on tmpfs
then surely it should check for that case, and then if necessary,
suggest one of the several possible solutions to the user.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpFE0ZTmZBFf.pgp
Description: PGP signature

Re: Two groups of users, one distro in the middle

[Joey Hess]

Alex Pennace wrote:
> Clearly, the nodejs community would not be pleased. On the other hand,
> the AX25 community would not be pleased about being forced to rename
> if it fell on them. So the real question is which community should
> bear the costs of resolving this conflict?
> 
> At this stage, it looks like neither side is willing to budge, so
> logic and Debian policy say both must bear the costs.

That seemed to make sense the first time I read it, but the more I think
about it the less convinced I am. The actual costs of Debian renaming
both `node`s will mostly be borne by Debian, and our users, not by the
upstream projects. There's really no point in trying to punish the
upstreams at all, because the next naming conflict is sure to involve
two different upstreams; such punishment has no deterrent value, and
only sours things. And not letting the most-popular name win flies in
the face of recent history: chromium the browser conflicted with
chromium the game and won; git the VCS conflicted with git the
little-used gnu tools, and won.

-- 
see shy jo, who is currently involved in a naming conflict over "parallel"


signature.asc
Description: Digital signature

Re: Two groups of users, one distro in the middle

[Milan P. Stanic]

On Tue, 2011-11-15 at 13:34, Ian Jackson wrote:
> Charles Plessy writes ("Re: Two groups of users, one distro in the middle"):
> > I agree.  One possiblity when packages A and B conflict for a program name
> > would be to rename, but in addition to provide a wrapper that executes the
> > program from A when only A is installed, from B when only B is installed, 
> > and
> > that gives an error reporting alternative path names when both A and B are
> > installed.  The wrappers for all names could be provided by a third package.
> 
> I don't think this ia a good idea.  The result would be that
> installing an additional package could break the operation of
> an unrelated package.
> 
> If users desperately want to do this themselves there is no reason why
> they shouldn't symlink /usr/bin/node -> nodejs themselves - apart
> from, of course, the reasons why they shouldn't.
> 
> But we should absolutely not support it.  I have no sympathy at all
> for nodejs upstream on this matter.

As a user/admin I fully agree with you. Debian policy should be changed
to state something like "First come, first served". Principle of least
surprise.

ax25 packages are in Debian for more than ten years, IIRC.

What to do if someone create {some}script language and call it 'cat' and
refuse to rename it because s/he like cats. ;-)

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code or documents in
proprietary format (word, excel, pps and so on)


-- 
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/201518.ga24...@arvanta.net

Re: Two groups of users, one distro in the middle

[sean finney]

On Tue, Nov 15, 2011 at 03:33:02PM +0100, Gergely Nagy wrote:
> Furthermore, packages in Debian are - to the best of my knowledge -
> adapted already to use /usr/bin/nodejs, packages outside can still work
> unmodified, if the user makes a simple symlink. Document this, and all's
> well.

I don't think the symlink is even necessary, and is probably a bad idea
in case the other package providing node was installed.  instead, ship
the binary in /usr/lib/nodejs/node (or similar), and instruct users that
if they need "upstream compatibility", to simply 

export PATH=/usr/lib/nodejs:$PATH

and problem solved, right?



sean


-- 
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/2015152833.ga21...@cobija.connexer.com

Re: Two groups of users, one distro in the middle

[Gergely Nagy]

Paul Wise  writes:

> On Tue, Nov 15, 2011 at 8:14 AM, Alex Pennace wrote:
>
>> Even without that point, the conclusion remains the same: Both
>> projects should endure the rename (unless one concedes), and that
>> shouldn't be viewed in terms of "look at what those meanies in Debian
>> are making us do" but instead regarded as a natural outcome of the
>> choices each project made at various times.
>
> I personally wonder if we should change our policy instead of forcing
> these two upstream communities into conflict.

In that case, I'll consider un-deprecating dpatch, and since it can very
well be used outside of Debian, rename it to patch.

Looking at our reverse deps and build-deps, as far as build-deps are
concerned, the patch and dpatch camp is farily equal (937 vs 764), which
is a much much smaller difference than in the node-vs-nodejs case, so
I'll be looking forward to having patch renamed to patch.gnu or similar.

(FYI, I'm a reasonablye person, so as long as patch gets renamed, I'll
be content with my patch being patch.dpatch, and I'm willing to bear the
consequences of having to adapt all scripts that use the old name, to
use the new one.)


Just because two upstreams can't agree, and both choose a name far too
generic, we shouldn't make our policies more forgiving to such
sillyness.

Furthermore, packages in Debian are - to the best of my knowledge -
adapted already to use /usr/bin/nodejs, packages outside can still work
unmodified, if the user makes a simple symlink. Document this, and all's
well.

Perhaps this will stop another upstream from choosing a similarly
generic name.

In all honesty, I fail to see the harm done, apart from some very minor
inconvenience, which can be trivially worked around.

-- 
|8]


-- 
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/87zkfxihgh.fsf@algernon.balabit

Re: Two groups of users, one distro in the middle

[Ian Jackson]

Charles Plessy writes ("Re: Two groups of users, one distro in the middle"):
> I agree.  One possiblity when packages A and B conflict for a program name
> would be to rename, but in addition to provide a wrapper that executes the
> program from A when only A is installed, from B when only B is installed, and
> that gives an error reporting alternative path names when both A and B are
> installed.  The wrappers for all names could be provided by a third package.

I don't think this ia a good idea.  The result would be that
installing an additional package could break the operation of
an unrelated package.

If users desperately want to do this themselves there is no reason why
they shouldn't symlink /usr/bin/node -> nodejs themselves - apart
from, of course, the reasons why they shouldn't.

But we should absolutely not support it.  I have no sympathy at all
for nodejs upstream on this matter.

Ian.


-- 
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/20162.27255.473822.488...@chiark.greenend.org.uk

Re: Description-less packages file

[Steve McIntyre]

Ansgar wrote:
>Joey Hess  writes:
>> AFAICS, there are no diff files, so this increases the average apt-get update
>> download size by 3.6 MB.
>>
>> Also, it seems unlikely this will ever allow apt to skip downloading the
>> English files, unless translations somehow get to, and stay at 100%
>
>Switching to xz compression would reduce the English translation from
>3.7 MB to 3.3 MB.  Maybe we could add support for this to APT and switch
>later (so we don't need both bz2 and xz on the mirrors).

I did wonder about that when I added the debian-cd code to deal with
translations. xz would probably make more sense, yes, but at the
moment I've just hard-coded for bz2.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt


-- 
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/e1rqima-0003ch...@mail.einval.com

Re: /tmp as tmpfs and consequence for imaging software

[Aneurin Price]

On 15 November 2011 08:17, Neil Williams  wrote:
> On Tue, 15 Nov 2011 07:41:54 +0100
> Andrew Shadura  wrote:
>
>> Hello,
>>
>> On Mon, 14 Nov 2011 00:14:18 +0100
>> Josselin Mouette  wrote:
>>
>> > > No it does not work like you said. We know the matrix structure, not
>> > > the kernel. We map and unmap manually. Doing as you said is
>> > > inneficient and trash a lot cache and so on.
>>
>> > This is getting insane. Please learn how to use madvise and
>> > posix_fadvise and let the kernel deal with paging. The kernel knows
>> > everything about the underlying hardware; the application does not.
>>
>> And what about the software being cross-platform? What about other
>> systems which don't have such system calls?
>
> Ever heard of #ifdef #else #endif ?
>
> If similar calls exist, use them conditionally. Where they do not
> exist, you need to decide if that system can be supported and accept
> the limitations of doing so. Where the calls DO exist it is inexcusable
> NOT to use the support available.
>
> Do not cripple all platforms with the sins of the weakest.

I think this discussion needs a sanity check.

Please remember, the topic of conversation is whether an application
can reasonably make the assumption that the system defined tmp
directory is a suitable place to store temporary data.

You appear to be saying "Of course not; every application should
include a small compatibility layer to call the appropriate syscalls
or other relevant interface for every possible platform to indicate to
the kernel exactly what it wants to do with its data. Yes, that
doesn't answer the question of where temporary data should be stored
in the first place, but I don't care about that as long as nobody has
the audacity to suggest that maybe /tmp might be a reasonable place
for transient temporary data."

Can you see why this might be treated with incredulity? Maybe it's
worth going back to the topic at hand rather ranting about something
irrelevant.


-- 
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/cahb+spbpom8oz5hvespjqtkaglr-+hbh-uk46-ovu79bwd3...@mail.gmail.com

Re: Description-less packages file

[Ansgar Burchardt]

Joey Hess  writes:
> AFAICS, there are no diff files, so this increases the average apt-get update
> download size by 3.6 MB.
>
> Also, it seems unlikely this will ever allow apt to skip downloading the
> English files, unless translations somehow get to, and stay at 100%

Switching to xz compression would reduce the English translation from
3.7 MB to 3.3 MB.  Maybe we could add support for this to APT and switch
later (so we don't need both bz2 and xz on the mirrors).

Regards,
Ansgar


-- 
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/s2shb25k6fs@bistromathics.mathi.uni-heidelberg.de

Re: Two groups of users, one distro in the middle

[Charles Plessy]

Le Tue, Nov 15, 2011 at 08:48:57AM +0800, Paul Wise a écrit :
> On Tue, Nov 15, 2011 at 8:14 AM, Alex Pennace wrote:
> 
> > Even without that point, the conclusion remains the same: Both
> > projects should endure the rename (unless one concedes), and that
> > shouldn't be viewed in terms of "look at what those meanies in Debian
> > are making us do" but instead regarded as a natural outcome of the
> > choices each project made at various times.
> 
> I personally wonder if we should change our policy instead of forcing
> these two upstream communities into conflict.

I agree.  One possiblity when packages A and B conflict for a program name
would be to rename, but in addition to provide a wrapper that executes the
program from A when only A is installed, from B when only B is installed, and
that gives an error reporting alternative path names when both A and B are
installed.  The wrappers for all names could be provided by a third package.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/2015094358.ge27...@merveille.plessy.net

Re: Want to become a DM and co-maintainer

[olivier sallou]

2011/11/12 Svante Signell 

> Hi,
>
> Where/how to apply to become a co-maintainer and a maintainer? The
> packages I'm interested into start with are: gnuradio and octave.
> Additionally, I have not found any package for USRP yet.
>

At first, you will have to maintain package via a sponsor or a team. After
some time, according to your sponsor, you will be able to ask to be a DM so
that you are able to maintain by yourself the package.
Once ready for being a DM, you can go here:

http://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer

>
> Thanks!
>
>
> --
> 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/1321127664.6311.24.camel@x60
>
>


-- 

gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: /tmp as tmpfs and consequence for imaging software

[Adam Borowski]

On Tue, Nov 15, 2011 at 07:41:54AM +0100, Andrew Shadura wrote:
> On Mon, 14 Nov 2011 00:14:18 +0100
> Josselin Mouette  wrote:
> > This is getting insane. Please learn how to use madvise and
> > posix_fadvise and let the kernel deal with paging. The kernel knows
> > everything about the underlying hardware; the application does not.
> 
> And what about the software being cross-platform? What about other
> systems which don't have such system calls? Also, the application
> doesn't need to know anything about the hardware except that disk
> memory is usually larger and slower than RAM is.

madvise():
# _BSD_SOURCE
# CONFORMING TO
#POSIX.1b.

posix_fadvise():
# CONFORMING TO
#POSIX.1-2001.

I'd call functions that are required by a not-so-recent version of POSIX
pretty portable.  What do you want to be cross-platform to then?  win32?
If so, you need a portability layer for anything fancier than "Hello world"
anyway.

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: /tmp as tmpfs and consequence for imaging software

[Neil Williams]

On Tue, 15 Nov 2011 07:41:54 +0100
Andrew Shadura  wrote:

> Hello,
> 
> On Mon, 14 Nov 2011 00:14:18 +0100
> Josselin Mouette  wrote:
> 
> > > No it does not work like you said. We know the matrix structure, not
> > > the kernel. We map and unmap manually. Doing as you said is
> > > inneficient and trash a lot cache and so on.
> 
> > This is getting insane. Please learn how to use madvise and
> > posix_fadvise and let the kernel deal with paging. The kernel knows
> > everything about the underlying hardware; the application does not.
> 
> And what about the software being cross-platform? What about other
> systems which don't have such system calls?

Ever heard of #ifdef #else #endif ?

If similar calls exist, use them conditionally. Where they do not
exist, you need to decide if that system can be supported and accept
the limitations of doing so. Where the calls DO exist it is inexcusable
NOT to use the support available.

Do not cripple all platforms with the sins of the weakest.

> Also, the application
> doesn't need to know anything about the hardware except that disk
> memory is usually larger and slower than RAM is.

For a trivial application, that is true. For any application which
makes specific or unusual demands on the hardware / system resources, it
is not. Applications making specific or unusual demands MUST allow for
system differences and that includes adjusting to those which can
handle the requests *better* than your own code as well as providing
code for (or preventing a build / deployment on) those which cannot.

Some kinds of applications just cannot avoid a direct interface with
the kernel (anything using iptables, for example) and any process which
makes unusual demands on the available temporary storage is certainly
sufficiently specialised to require conditionals in the code which make
use of kernel features where those are available.

Cross-platform is not an excuse for one-class-for-all. Cross-platform
means making the most of each platform, not dumbing down to the lowest,
meanest or most inept.

If you want compile-once run anywhere, you could try java and move all
these problems to the VM. (Which has to do this system-specific stuff
anyway.)

If the application needs to be recompiled to be cross-platform then
there is absolutely NO EXCUSE for not including conditional compilation
for specific kernels or environments.

Your build system is unquestionably doing some adjustments from one
platform to another anyway - you simply have to bring those
conditionals into the codebase. There is no excuse - your software is
broken and it must be fixed or removed.

(and, yes, I've explicitly included iptables as an example because I've
got an RC bug outstanding for a tiny app which cannot therefore be used
on BSD and I keep meaning to find the time to fix the build
requirements, so this is directed at me as much as anyone else.)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpqqs3OEU9lt.pgp
Description: PGP signature