Aw: Request for instructions how to contribute with technical documentation

[Steffen Möller]

Dear Zebb,

 

Thank you for your kind offer to help. Debian technical documentation somewhere may already have an answer to your question. I admit not to have checked. But if you would please check that and find that info missing, then please then send a diff to the authors of that document or a pull request of where the document resides.


 

You likely know that the documentation of Debian includes the documentation provided by the developers of the software that Debian builds and redistributes. So, if you are proficient with some software of Debian, maybe you truly want to contribute to the documentation of that software project, not of the documentation of Debian itself. With the typical software documentation it may be fair to say that the graphical support is lacking. So, if you know how to draw or how to make icons then you can be of immediate strong help for many projects, not only for the Debian infrastructure.

 

Debian and larger software projects, like KDE or Blender, have regular user meetings. Once you have started contributing, it seems fair to expect that you are invited to personal meetings, which should then help to find the right match of your personal skills with whatever bit is about to be developed (and not yet documented).

 

Best,
Steffen

 

Gesendet: Donnerstag, 23. November 2023 um 21:59 Uhr
Von: "Zebediah Beck" 
An: debian-devel@lists.debian.org
Betreff: Kein Betreff


Good day sir/madam
 

I'm a long time debian user but would like that contribute technical documentation to the community in thanks for your tireless work on this magnificent ecosystem.

 

Thanks

Zebb

Aw: Hi there.

[Steffen Möller]

I agree that our network of trusted developers can help beyond development, and 
maybe it should in this early onset of a deglobalisation, but this one may 
affect our security. The company's URL is https://www.hataphar.com.vn/, nothing 
like hpharm in Mali.

$ host hpharm.ml
hpharm.ml mail is handled by 10 emx.mail.ru.

I know, the likelihood of anyone of us to have fallen for this is rather slim, 
but, hey, things happen.

S.

> Gesendet: Montag, 24. April 2023 um 12:13 Uhr
> Von: "Lan  N." 
> An: debian-devel@lists.debian.org
> Betreff: Hi there.
>
> Hello,
>
> A reputable pharmaceutical company from Vietnam is in need of a
> reliable individual or corporate entity in your state to act as
> their Liaison officer; this will not
> affect your current job or business operations in any way.  If
> interested, reply for more information.
>
> Regards,
>
> Ms. Lan Nguyen
> Hatay Pharmaceutical
>
>

Re: Is there room for improvement in our collaboration model?

[Steffen Möller]

On 15.04.22 15:53, M. Zhou wrote:

On Fri, 2022-04-15 at 14:24 +0200, Luca Boccassi wrote:

I think this will also improve newcomer's contributing experience.
This proposal is also filed at
https://salsa.debian.org/debian/grow-your-ideas/-/issues/34

What about doing something even simpler - rather than having additional
generic/core tags/teams/groups, for packages where one wants to say
"please help yourself/ourselves", simply set the Maintainer field to
debian-devel@lists.debian.org, have the Salsa repository in the debian/
namespace, and that's it? From thereon, anyone can do team-uploads by
pushing to salsa and uploading directly, no need for
acks/delays/permissions/requests.


A simpler solution sounds good to me, except that change would be
somewhat "permanent" in stating the original maintainer's preference.
I forgot to mention in my original post that the tags can optionally
expire.

So, things like, `tag all my packages as "feel free to nmu" within
the next two weeks` would be trackable.

The only extra request from my side would be for salsa-maintained
packages to havet the NMU not bypassing the version management.

Steffen

Use files created during CI to seed trust and attract new users?

[Steffen Möller]

Hello,

When CI fails, I get an email and can chase things up with a look at the
output files. This is something I like a lot. As a user, though,
especially for scientific packages I would want to see the files that
have been created. This way I could confirm that, e.g., the generated
PDFs have usable fonts and if a test follows an established workflow for
a well-known dataset, I can also compare the results generated during
testing with the ones expected. "Expected" could be the files a Mac user
generated when installing the package locally, a less technical user may
know a tutorial (a nice one that I want to address is on
https://docs.qiime2.org/2021.4/tutorials/moving-pictures/) and would
then compare the CI-generated image with the one presented online by
upstream.

There are many problems with this suggestion, to mind come
 * amount of data to be handled as input
 * amount of data to be stored
 * unclear acceptance by users
 * too much extra compute
 * ... please add what comes to your mind ...

My sketch of an idea was that we could possibly have in analogy to the
debian/install files an extension to the test instructions that define a
set of files, preferably together with a description, that may be
worthwhile to be inspected by end users as a proof that the package
works. A test report would then be generated with links to these files.

Is this anything we would want to have? Do we have this already and I
just failed to find this?

Many thanks!
Steffen

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Steffen Möller]

On 11.08.21 08:46, Marc Haber wrote:

On Wed, 11 Aug 2021 01:09:29 -0400, Calum McConnell
 wrote:

On Wed, 2021-08-11 at 00:51 +, Paul Wise wrote:

On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote:


"So, Arch Linux, one of the main reasons, there's a couple, but the
main
reason is the rolling updates of Arch allows us to have more rapid
development for SteamOS 3.0," says Yang. "We were making a bunch of
updates and changes to specifically make sure that things work well
for
Steam deck, and Arch just ended up being a better choice for them."

Sounds like Debian testing would have worked for them too.

Except testing lacks direct security support, and spends about a quarter
of the time in a feature freeze.  It isn't a true rolling release: the
wheels are squares instead of circles.

I think that the experience that Debian has made with Stream is our
classic problem: We try to cater for all, and annoy the people who
want quicker releases. After we have driven away the users who want
quicker releases in the early 2000s (they have moved to Ubuntu or to
the rolling release distributions), we have taken a quicker pace,
driving away the users that want more stability (they have probably
moved to the Red Hat / CentOS world despite them having actually less
stability by defining stability and support time differently than we
do), and still we're too slow for downstream users like Steam.

This is either going to continue, or we finally commit to having more
than one release train, which of course comes with its own set of
issues, the biggest of them being volunteers and personpower.

There is no glory in supporting long support cycles.


For steam, our competitor may be arch. For science projects, it is conda
(ok, hello, yes, you brew and guix people, you are also competitors) -
which rolling and (bonus feature) cross-platform - with CI and often it
is upstream preparing and using these packages themselves.

I have no exact idea what to change, though. A rolling Debian would be
cool, yes, but also a bit late when compared with environments that
Conda offers or the ease that comes with multiple installations of conda
to e.g. avoid name conflicts. If we had a chroot for which you do not
need to be root, then together with snapshot.d.o we would be darn close
to what Conda is offering. I have no idea how to get there, though. With
singularity maybe?

Best,
Steffen

Re: Making Debian available - Testing iso download

[Steffen Möller]

Am 05.02.21 um 18:50 schrieb Geert Stappers:
> On Fri, Feb 05, 2021 at 04:21:42PM +, Paul Sutton wrote:
>> Would it be possible to make it easier to find the ISO for the next release
> It is work in progress and the process is called "Doing a release".

The reply was kind of funny but please allow me to support Paul's
request. And close to our next release, I see an extra value since
attracting more people to our testing release will attract valuable
eyeballs to spot issues that the typical developer my be more likely to
miss.

Best,

Steffen

Re: Bug#981113: ITP: root -- open-source data analysis framework

[Steffen Möller]

Am 26.01.21 um 16:59 schrieb Christoph Biedl:
> Julien Cristau wrote...
>
>> On Tue, Jan 26, 2021 at 04:34:14PM +0100, Stephan Lachnit wrote:
>>> * Package name: root
>> [...]
>>> I want to maintain ROOT in the science team. ROOT was already in Debian as
>>> `root-system` [1], but hasn't been updated since 2015.
>>> I will probably go with a more easy maintainable route like I did with 
>>> Geant4
>>> for the start and do package splitting later.
>>>
>>> [1] https://tracker.debian.org/pkg/root-system
>>>
>> Please re-use the old name.  "root" is a terrible choice of package name.
> At least. Even "root-system" is not very distict, I'd rather choose
> something like "root-analysis-framework", assuming that name is a good
> description for what the package does.

cern-root ?

Thank you for this effort, anyway!

Steffen

https://trends.debian.net/ - is this 20000 source packages since 2006?

[Steffen Möller]

Hello,

I just skimmed through https://trends.debian.net/ and am impressed. Many
thanks for these figures. Do you accept wishes for additional graphs? 
Mine would be on the number of build dependencies as a scale for
software complexity and how this evolved over time. My hunch is that
later software has more dependencies than earlier ones. Would of course
be cool to also have other software metrics over time. Anyway -
fanstastic plots already!

What is right in the open but I do not see discussed in this context is
the sheer amount of packages that are added to the distribution. It is a
raise from close to 1 to similarly close to 3 in a bit over 14
years, so this makes close to 1500 packages/anno or close to 4 per day,
equally throughout all these years. Knowing about all the time I spend
on checking copyrights already, not always successfully, I know about
the enormous work our FTPmasters invest into keeping this up. So, many
thanks!

Best,

Steffen

using salsa as a package triage system? "channels"?

[Steffen Möller]

Hello,

I am mostly a the periphery of Debian for Debian Med, but at times this
makes me add build dependencies that are of interest for everyone. Like,
basic packages for nim. :o) Whenever we go out to the world we keep
stressing that Debian Med is not separate from Debian at all. It is just
the name of a community. With today's  unbearable load for the FTP
masters maybe we have to reconsider - after all, the FTP masters only
see a fraction of what we really need in the distribution to solve
today's biological challenges.

If we had another kind of repository for Debian Med, then quite a bunch
of packages would not require the immediate scrutiny of our FTP masters.
Frankly, most of our users will just accept that some upstream developer
in github decided their software to be free and redistributable and
don't look much deeper - they have a biological problem to solve and
that package is part of a workflow that is today's best practice they
want to follow. This pragmatic stance has been taken by conda and while
our scrutiny is much accepted and praised in the scientific community,
our packaging falls behind in both scientific coverage and adoption rate.

The packaging of conda is not completely different from what Debian is
doing, but conda is much more community-driven. Since conda started wit
github, they basically had a salsa.d.o from day one. And they use it
much to its full potential: automated updates, community peer reviews,
very fast integration of new software. Two years ago we had first
developers halting their contribution to Debian since from a
biology-driven perspective, they cannot afford that extra effort since
the advent of conda. Conda folks suggest that Debian should concentrate
on the basic OS. And they have a point, especially since Conda gets
increasingly close to what Debian is offering, e.g. with respect to CI.

We cannot immediately adopt how conda is doing it since we would lose
what makes us special. But we can learn and could imho fairly easily
rewire Debian's package flow to make being an FTP master fun again. And
at the same time speed up the periphery. Suggestions:

 * the periphery gets their own repositories - happily also called
"channel" in analogy to conda
 * maintainer decides on what packages are auto-update-able within the
channel by routine-updates (referencing a script by )
 * channel-community upvotes the integration of packages with Debian
proper as a suggestion for FTPmasters
 * popcon gives feedback on the adoption of packages
 * FTPmasters pick new packages from the periphery channels as they see fit

I am not sure about the granularity of these channels. Maybe every blend
should have one or two channels. Obvious (to me) candidates:

 * med
 * astro
 * science
 * r
 * machine learning
 * 

To increase security especially when embracing new contributors without
sponsors, I am tempted to say that we should not keep the sources in the
git repository but analogously also to OpenWrt only maintain the debian
folder. I find this to work amazingly well.

We had discussed PPAs in the past - this suggestion is admittedly
similar. The interaction with salsa and ftpmasters is what renders it
most different, I tend to think. It is not an issue only of Debian Med -
the packages are too much interconnected, I think. The packages that
have most reverse dependencies to packages of many channels are the ones
that the FTPmasters may want to prioritize.

Steffen

Re: Salsa CI news

[Steffen Möller]

Hello,

I think your dispute goes down to the question if Debian's community
infrastructure should preferably using software packaged for Debian
(which salsa is doing) with the binaries Debian offers (which salsa is
not doing). I find this interesting. The two positions are

A) No idea why this should be of concern.

B) Using our own packages ensures that there is no diversion between
what Debian ships and what Debian uses, so it can be bootstrapped on an
island (which is the link to the DFSG) as a whole, not only the software
it distributes.

There is certainly more, like if B) was the case then the salsa
maintainers would find problems with the packages/updates of the same
and the Debian packages would be more likely be use by others when a big
installation like salsa uses them. And that would strengthen Debian as a
whole. However, this extra work /uncertainties may be something that
overloaded maintainers want to avoid.

I personally see the beauty of B. But if I cannot access the repository
because of some downtime -no good. So I am also a fan of A - it works.
The way to go may be to somehow convince the salsa maintainers that they
will save some work when they adopt the Debian packages. And that
whatever update they are doing is of no risk. No exact idea how to get
there. But the notion of interchangeable Docker images sounds very
reasonable ... and we work on exchanging them for singularity
(syslabs.io) images later.

Steffen

Accepted dazzdb 1.0+git20200115.d8adde7-1 (source) into unstable

[Steffen Möller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 19 Jan 2020 18:11:41 +0100
Source: dazzdb
Architecture: source
Version: 1.0+git20200115.d8adde7-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 

Changed-By: Steffen Möller 
Changes:
 dazzdb (1.0+git20200115.d8adde7-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version
   * Standards-Version: 4.5.0
   * Set upstream metadata fields: Bug-Database, Bug-Submit.
Checksums-Sha1:
 7dc7a7131ef84cfea99e288ef99ed5e6a6211569 2029 
dazzdb_1.0+git20200115.d8adde7-1.dsc
 fb2fa57614fedd9760968a7096315a9f61868347 69596 
dazzdb_1.0+git20200115.d8adde7.orig.tar.xz
 6cad056baec385477604c39ba52f5e54173344b1 4892 
dazzdb_1.0+git20200115.d8adde7-1.debian.tar.xz
 599bec805d12fd564ca7d6cb7a72d560823df41e 5781 
dazzdb_1.0+git20200115.d8adde7-1_source.buildinfo
Checksums-Sha256:
 c50f15b9b6197ca2a32f610088ab9080357be76015e61a6da7215feee2da4222 2029 
dazzdb_1.0+git20200115.d8adde7-1.dsc
 fdad09fe422327a61171ccb95fb3aa0aaf25f77d33b31989263a463b705db490 69596 
dazzdb_1.0+git20200115.d8adde7.orig.tar.xz
 a9a63e884285de6df24560eb79d032328aa97a8f7553eba3db29f0d3fd148971 4892 
dazzdb_1.0+git20200115.d8adde7-1.debian.tar.xz
 258f9216ef4797f64f2c446fca58b982dc2368e7a9a625ae635e1a43de1d78ca 5781 
dazzdb_1.0+git20200115.d8adde7-1_source.buildinfo
Files:
 aa7296bfcf041f7359b500f89228e8a4 2029 science optional 
dazzdb_1.0+git20200115.d8adde7-1.dsc
 21040ce355ae737c070f50f50156c3f1 69596 science optional 
dazzdb_1.0+git20200115.d8adde7.orig.tar.xz
 6a3287dad950f86f7ced06288b9d5980 4892 science optional 
dazzdb_1.0+git20200115.d8adde7-1.debian.tar.xz
 25b56f74598e25375a534a5cc675d4e7 5781 science optional 
dazzdb_1.0+git20200115.d8adde7-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhMGXeonn7+0+XKYuL9i+2sAg7tEFAl4oLswACgkQL9i+2sAg
7tGLoxAAkQfgPZFoDyNpJnBWXH3o9HL8YHIfjxteRdIxg7tl1tpiGtEOEeXankIb
JDXGO9fCb9el4ZWrKSvzk9eXZrdPR5BmaBRAAIwc6Siy2poQtwmt6kKEru67OAgT
+5oMIBI68F/Jb12s47IPWqbEizz6DQpXrV7wBmXtE8yOEb+tZpWD2TeI5BGGqXWV
nNyTnJlmVg0/f/JGg1mwn/PXANICDAYxirWss5HsLAnwCW8LVHy5i04FXULAGx9H
01n1csqgDdfbjViCEVjwmPReT6F9rDBFYdrBtUZV+xE61azAPt0atCfPD2l65+zp
D4FiF0KKqlRLjv+1lNJO5g80+G+zztVLtNpkcijiSLSbKSyLJfVB3MiVL2dr/nWo
cr7gykyCVj0itR0ptXbBYLdd/49qDDfYZhfkiV6j9K1F/DP/5UUAMWk6XkzhRlPz
eTSlHsSsSylUIO1YbqYiBUP/yOozVT3MfzB953O3ktQb852vpmrFak5OImZJhWwm
DNt3nk+cRNSMZD/WkpNucmunkNuHA70ponNd+jR+SEPN0WvHRFPnuGZ+/C9JMnmC
qbps8FytPDH3rlXy5HBh3NEtomR5YthgXApMj3o1C7JStwDgmb6pdtPIApRja5F1
DetS9G+7GNjpV4oYfJAQgqYUZ8ML+6DH/3xMgkEiJRjTC1bbV+o=
=gUPz
-END PGP SIGNATURE-

Accepted ricks-amdgpu-utils 2.6.0-1 (source all) into unstable

[Steffen Möller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 06 Oct 2019 09:36:29 +0200
Source: ricks-amdgpu-utils
Binary: python3-gpumodules ricks-amdgpu-utils
Architecture: source all
Version: 2.6.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 

Changed-By: Steffen Möller 
Description:
 python3-gpumodules - adjustment and inspection of AMD GPUs
 ricks-amdgpu-utils - AMD GPU performance adjustment and monitoring
Changes:
 ricks-amdgpu-utils (2.6.0-1) unstable; urgency=medium
 .
   * New upstream release (bug fixes).
Checksums-Sha1:
 ac342bc5c608d5fea85bd9457c81d505eac1c651 2190 ricks-amdgpu-utils_2.6.0-1.dsc
 76483879f29e933f332ffbb4a4e95980822ff2fe 1278924 
ricks-amdgpu-utils_2.6.0.orig.tar.gz
 bb1cf84a5cd16da9fbfafdfa5d04ecc267da9115 2072 
ricks-amdgpu-utils_2.6.0-1.debian.tar.xz
 7a35687d2de6434157ead644a0bc0cc20b1f4b34 32296 
python3-gpumodules_2.6.0-1_all.deb
 ce87780c6a8de22ac1545b86934269e9fdae7b67 1191380 
ricks-amdgpu-utils_2.6.0-1_all.deb
 3c650b5d4247ce15bbb70336f100b2b5611b6a3e 6734 
ricks-amdgpu-utils_2.6.0-1_amd64.buildinfo
Checksums-Sha256:
 117660f50239bd1fb27ee1a3074b6bcac3305764761f79c09499b4ab5b6c4e2c 2190 
ricks-amdgpu-utils_2.6.0-1.dsc
 00885db4aec23f9a030ad75e1bbb5b100dba840b20a3cdd93c490242be235a17 1278924 
ricks-amdgpu-utils_2.6.0.orig.tar.gz
 de64f18527ec2e52613e38332dbe2add7810899c325fab7c991d3b22fa514cc0 2072 
ricks-amdgpu-utils_2.6.0-1.debian.tar.xz
 abafecf253e1b39e73db0b5d38f4f30b10adbabf8401b8fc7820a25b7065c66b 32296 
python3-gpumodules_2.6.0-1_all.deb
 864218c6fb06216c849422bb8acbc899697ba85daf8692850d5c2df9f82c301f 1191380 
ricks-amdgpu-utils_2.6.0-1_all.deb
 0b0a88a09a1ae62c881dc0fa3230f7fce76d3c752b0813ca6a655e0f60f5dd85 6734 
ricks-amdgpu-utils_2.6.0-1_amd64.buildinfo
Files:
 5f5e588c14b26a82067c970896ac2786 2190 utils optional 
ricks-amdgpu-utils_2.6.0-1.dsc
 96d6846e917bb59e292cb4f1613261b6 1278924 utils optional 
ricks-amdgpu-utils_2.6.0.orig.tar.gz
 4769f994c053bec317f3fc455f76b01d 2072 utils optional 
ricks-amdgpu-utils_2.6.0-1.debian.tar.xz
 5235344a4162c69b1028170c710cc630 32296 utils optional 
python3-gpumodules_2.6.0-1_all.deb
 637574c77c61aa56fad9c41496009201 1191380 utils optional 
ricks-amdgpu-utils_2.6.0-1_all.deb
 5686b9f739c3a86923fa8a311a894950 6734 utils optional 
ricks-amdgpu-utils_2.6.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhMGXeonn7+0+XKYuL9i+2sAg7tEFAl2ZmisACgkQL9i+2sAg
7tEl5BAAho12vtsjxzqfS5OsoL6QBlpbeoeLOPrk8956n1HhYvL3wUhJ5Sny4eQe
c+PbIa9p5qaj0fp6pP/rsY4/l92SIP6gX23BFkYCWrcUm4R8wVHQrUYGuKkuc8Hk
vlG3pWC9aj/ZntV+IHGFk/yMRXir0T6mxQV+/25mDi7X2WQgPeOBVWEWNnZyAL9/
VdWwvLB5XlABVsVY32iQQY+SHT7ZZoymT5ns/hjsqW0BpCNFSVSa1nx8QsdezEUk
mKnpZeWnzV1y4S+RBZOo75EGKtcM8Pwtne5cpFoYzOAAaS73ZM0cEnvzDEY4lJhd
SNGwWUbsipIgTzglmbHdSk17aY7kzTb/GxnK2GQHdA5/d25MkveZ84EOBuaZZRTl
4iBSqGydBDBK4yw6K9D5kdZOz1hUI8MTHjyAaw8SdiyWi4c2C1V+x0Qezs8s/IaX
VmHjGSwIYQvYxQU9c8rJfxfYizmts8XTvhmVUANOoGOy1qt+Gi+GKX8UukFAX8a6
c3JPHAkUl4cnmSJ6SP4dBoNXo9d8ix42Bpl1hq0YaSu6A79RD5UWTD40ryNm0H8f
PMeB5jvLx8iuGMhyZL9zk6HGhHWfvGIbwd4apkYFCpmO8JOtmJ+zmlmnCtR9KgLM
ZmcaTcyvLV2zFo+NWLpFWFiXpixRTH01gZ+n9Bt8MhEC/J9p2Og=
=zfM9
-END PGP SIGNATURE-

Re: Debian Policy 4.4.1.0 released

[Steffen Möller]

Hello,

On 29.09.19 20:16, Sean Whitton wrote:

Here are the significant normative changes from the previously announced
release of Policy (4.4.0):

5.6.26
 A package control file must not have more than one ``Vcs-``
 field.

where type != "browser"?

 If the package is maintained in multiple version control systems,
 the maintainer should specify the one that they would prefer other
 people to use as the basis for proposing changes to the package.


And how does that relate to the Source entry in d/copyright?

Best,

Steffen

Accepted ricks-amdgpu-utils 2.5.2-1 (source all) into unstable, unstable

[Steffen Möller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 19 Jul 2019 01:00:13 +0200
Source: ricks-amdgpu-utils
Binary: python3-gpumodules ricks-amdgpu-utils
Architecture: source all
Version: 2.5.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 

Changed-By: Steffen Möller 
Description:
 python3-gpumodules - adjustment and inspection of AMD GPUs
 ricks-amdgpu-utils - AMD GPU performance adjustment and monitoring
Closes: 932554
Changes:
 ricks-amdgpu-utils (2.5.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #932554)
Checksums-Sha1:
 bd13607dbcdba6dd89aa036a831c0214d0cf69ab 2190 ricks-amdgpu-utils_2.5.2-1.dsc
 590b9c414684d14c010b93bbd35a6768ea526449 1276712 
ricks-amdgpu-utils_2.5.2.orig.tar.gz
 e8d44e22dbad50d3cf1f44017171ffd491588ad1 2012 
ricks-amdgpu-utils_2.5.2-1.debian.tar.xz
 95acf329199a7b1d0f1555d7d9f2824e9231d0c0 32496 
python3-gpumodules_2.5.2-1_all.deb
 9902abf5ea3235d62073e69160aa137550af7bfe 1189624 
ricks-amdgpu-utils_2.5.2-1_all.deb
 95b496c8717566c65a5da9f22faaf992a3c11e08 6613 
ricks-amdgpu-utils_2.5.2-1_amd64.buildinfo
Checksums-Sha256:
 8be9f93ad1996af14f6aa32bb3512dd425b07e514c77dff512779766f1896bd9 2190 
ricks-amdgpu-utils_2.5.2-1.dsc
 b0d09a87311f197c353250f716022c547d14ac0ac7a44cae99caea8c435276ee 1276712 
ricks-amdgpu-utils_2.5.2.orig.tar.gz
 6b441d7af0dcb5d144ae62f8eebcc9c4342d99a07e5ab594f972dfb80218d5b8 2012 
ricks-amdgpu-utils_2.5.2-1.debian.tar.xz
 423c0c954a498a3a9862fbec60201695faa0bcaeef736aa5049972e430b90d11 32496 
python3-gpumodules_2.5.2-1_all.deb
 e537c3e59fb4455594ded51607a9d1952102b74a48a677bec836f9b0ecb1d1f3 1189624 
ricks-amdgpu-utils_2.5.2-1_all.deb
 d50b357a16a39472de83a92dab2d3a9214926f6d123a559a4a60729fbbb47658 6613 
ricks-amdgpu-utils_2.5.2-1_amd64.buildinfo
Files:
 5b94093382c122ee368f6c4bafbe9495 2190 utils optional 
ricks-amdgpu-utils_2.5.2-1.dsc
 70568a762571511a329f9d27751f23fe 1276712 utils optional 
ricks-amdgpu-utils_2.5.2.orig.tar.gz
 f80922c94de08f29dfd8f87237a9a41b 2012 utils optional 
ricks-amdgpu-utils_2.5.2-1.debian.tar.xz
 dc70f841e9af51d5b5718cc38492e04a 32496 utils optional 
python3-gpumodules_2.5.2-1_all.deb
 49004af77c71cf7ca63d1b7f0fd9aed5 1189624 utils optional 
ricks-amdgpu-utils_2.5.2-1_all.deb
 c7fdc5fe2130a9eb793458228f557ac4 6613 utils optional 
ricks-amdgpu-utils_2.5.2-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhMGXeonn7+0+XKYuL9i+2sAg7tEFAl05nmIACgkQL9i+2sAg
7tGAzRAAjxUODqRuMQ08J+YIrDsq2Qi8C3zZaWVWtbiguksUgTN5d2DvOWluuFw+
dggaKDoHVFUmw3FUZQecutDN9iB5AZmlEQe+gvp8dUypNffECNICT6qSGk9xLuJf
lCniZnWtXT5RFKsazZ7878ywru53Kc54JhUGm3xSf3j/u2jWxq9HsrhDYo5dVpze
ZMpyG1amwYClbmOurIxb6J+bjBjcfvVF32DTvj3XCZbnxLDvXkPne9kEej6vN/mZ
g0N2rEzo8PdVYQamj5bulvcZ7mDxe2cOHiTCOt9foF8e0Y1zgEPUtW1CHz5renGE
pywLZ2ssVxxZBJ3SvvdKoLTMztoKvTpBy02sOrbnbWmt7eJT9W2Owy2pVjCWi38c
G/9Vq30aHkd0FepxT4E9chXAfspZBdUnRqm4qfn9MubMH7ZWIWO+EhpL6+Q8wicd
s4rYnNd3eeiEE3aMPc8SO4mQWRDfV2q2aqBnO2AE92oDwUEIJ8yj4GcCV1HediG7
YQidAHvso5nXmVgaTiIXgsrMWZeufR6bZdOx/JVJbrDtiN3GGfrR7zOEwezxQF5u
R/YGQXmDacDRDvwOHHRA5qDSLxdpUXWmF0ni/ENfwYTdJ5At+TzANF+4nOlLw4Fj
Gl5hb23hwe9NQuZB02G3hSunB4nk6UmXzzAKkuQtQ+Fv6DRB/AY=
=5T30
-END PGP SIGNATURE-

Re: On the Removal of src:tensorflow

[Steffen Möller]

Hi Mo,

Would you mind creating a wiki.d.o page that collects your insights? Or
shall I start and you fill in the gaps?

Best,
Steffen

On 26.08.19 04:04, Mo Zhou wrote:

Hi -devel,


I've just filed an RM(#935769) bug against src:tensorflow and I believe
this is the most appropriate choice at this stage. For packages that
would easily draw attention from the media, not providing them would be
much better than providing something much inferior than the users
expected (Recall "difficulty ... DL framework" and "conda ...").


A number of packages in our archive have referenced tensorflow:

   https://codesearch.debian.net/search?q=tensorflow=1

Or even called its C API (ffmpeg calls tensorflow for its super
resolution filter. ffmpeg package maintainers have disabled the
--enable-libtensorflow configure option). At this point, for good wish
some contributors may hope to put a little bit more effort to save the
package and at least keep its C/C++ interface available. To me avoiding
the Bazel build (the only build system for tensorflow) is costly, and
the yield isn't worth the cost. The most practical recommendation to
tensorflow users is "pip or conda".


Deep learning (DL) framework is NOT something too complex to be
implemented from scratch by a single person. A fundamental DL framework
can be implemented with the following functionalities:
  1) data loading, e.g. a CSV reader
  2) linear operations, e.g. matrix multiplication, convolution
  3) element-wise non-linear functions, e.g. max(x,0), exp(x), ln(x)
  4) the computation graph (sort of directed acyclic graph)
  5) automatic (of manual) differentiation (computing the gradient)
  6) first-order gradient-based optimization (network training)

That means tensorflow's complexity doesn't come from the theoritical
side, but engineering especially performance optimization. On the other
hand, it's easy for the users to find an alternative to tensorflow if
they don't heavily rely on some portion of its functionality.


Based on the following facts, I believe removing src:tensorflow is the
most appropriate choice at the current stage, and I DISCOURAGE any
effort trying to save or re-introduce it.

  1) TensorFlow's only well-supported build system, i.e. Bazel is
 hopeless to enter Debian.
  2) Maintaining an alternative build system (cmake, or any self-made
 one) could be costly.
  3) Even if somebody conquered the build system issue at a cost,
 it's only possible to upload the low-performance version to our main
 archive (out of SIMD acceleration due to our ISA baseline,
 out of CUDA acceleration or OpenCL acceleration).
  4) To mitigate the performance issue one could upload a CUDA version
 to contrib section, but I promise that dealing with nvidia stuff
 once anything went wrong is a painful experience to free distro
 developer.
  5) To mitigate the performance issue with OpenCL one could also try
 AMD's fully open-source ROCm/HIP software stack (AMD's opensource
 counterpart to the nvidia CUDA). However the usage of AMD graphics
 for machine learning is still not common, and none of the
 related software has been packaged yet.

With that said, I still encourage people who care about such topic to
maintain building block packages (I'm maintaining some of these) for
DL frameworks, or some alternative DL frameworks if you see appropriate.

And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?

[Steffen Möller]

Hello,

We just had SuSE embracing LTO
(https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html).
I am not sure about the progress on issues summarised in
http://blog.regehr.org/archives/1180 that Ian pointed to. But since I
last asked in 2016 we have more pedantic compiler settings and more CI -
and LTO, as much as compilers have improved on that, does not need to be
applied everywhere. Any change in opinion?

Steffen

On 30.03.16 17:22, Ian Jackson wrote:
> Steffen Möller writes ("-flto to become more of a routine - any change
in opinion since 2011?"):
>> I admit to be a fan of link time optimisation and would like to see this
>> challenge promoted towards more of a routine challenge to establish for
>> our packages. I found this informative thread
>>
>> https://lists.debian.org/debian-devel/2011/06/msg00181.html
>
> I have a concern not yet addressed in this thread.
>
> Recently we have seen spectacular advances in compiler optimisation.
> Spectacular in that large swathes of existing previously-working code
> have been discovered, by diligent compilers, to be contrary to the
> published C standard, and `optimised' into non-working machine code.
>
> In fact, it turns out that there is practically no existing C code
> which is correct according to said standards (including C compilers
> themselves).  (A full discussion of how this situation came to be is
> probably out of scope for debian-devel, and also might involve me
> becoming quite rude.  So I will avoid that.)
>
> I worry that LTO will exacerbate this problem, by extending the
> categories of technical non-compliance (with rules which are very
> difficult to fully comply with) which are detected by compilers and
> transformed into actual non-working code.
>
> IMO Debian should not arrange for users to be using LTO-affected
> executables (in general[1]) until there have been major advances in
> the manageability of the C dialect we are using.
>
> To give an idea of what I think would be necessary, here is an
> excellent posting from Pascal Cuoq, Matthew Flatt, and John Regehr:
>   http://blog.regehr.org/archives/1180
> (I don't necessarily agree with this in every detail, but it gives a
> very good idea of the breadth and depth of the changes I think are
> needed.)
>
> In general I highly reccommend Regehr's blog for this kind of topic.
>
> Thanks,
> Ian.
>
> [1] Of course if there are specific programs that are somehow known to
> be in compliance with the rules being newly enforced in LTO, then it
> might be reasonable for those specific packages Debian build systems
> to enable LTO.
>
> However it seems like it will be very rarely in practice possible to
> establish that a program is correct enough to safely enable LTO.

Comparing/Using Conda with Debian

[Steffen Möller]

Hello,

On an project-internal mailing list the thread "Conda vs Debian"
evolved. Sam kindly reminded us to discuss this publicly. So, here you
go, issues raised were

 * interaction with industry-standard non-free software

    + Intel compilers and libraries

    + NVidia drivers and libraries

 * multi-version installations

    + upstream defines what is stable to them

    + drive of users to use the very latest versions vs more
conservative adoption of library versions by developers

  * QA and CI and ...

  * perpetual vs backporting

Please don't hold back. The topic of the initial thread asked why Debian
packaging is fun. Conda may not be the best possible answer, but let
this thread nonetheless enlight ourselves.

Steffen

Re: AMDGPU+OpenCL with Debian?

[Steffen Möller]

On 17.06.19 22:16, Carsten Schoenert wrote:

Am 17.06.19 um 21:15 schrieb PICCA Frederic-Emmanuel:

Same here... with WXX100 cards.
what about rocm packaging ?

(I'm not using an AMD graphic card but ...)

there was recently a new article added to the Debian wiki regarding this
topic about using the official AMDGPU driver. Maybe this helps solving
some questions?

https://wiki.debian.org/How%20to%20install%20official%20AMDGPU%20linux%20driver%20with%20kernel%204.19.x%20on%20Stretch%20and%20Buster


Thank you for that pointer, Carsten. I think that likely would have
helped. Still, when working on a new system, would you follow these
instructions or rather install Ubuntu? As helpful as such instructions
are, most folks don't want to be bothered. They want their graphics card
to work. When Debian describes tinkering with GPUs, then this should be
something constructive, like for flashing some new bios with extra feats
- not for the basics.

Best,

Steffen

AMDGPU+OpenCL with Debian?

[Steffen Möller]

Hello,

Running Debian unstable, I failed to set up OpenCL to work with BOINC
and an AMD RX580. The card worked just fine with the monitor, but it was
not recognised as an OpenCL device by BOINC. When I then tried to
install the 19.10 release of the driver AMD provides on
https://www.amd.com/en/support/graphics/radeon-500-series/radeon-rx-500-series/radeon-rx-580
on our distribution, the kernel module did not compile.

I then installed Ubuntu and basically did not need to do anything - it
just worked upon installing boinc-client-opencl. I could also install
the .debs provided by AMD with no difficulty. Are there others on this
list with similar experiences under Debian? Is there something we
can/want to do to help that situation?

Cheers,

Steffen

How to properly upload a bunch of packages with mutual dependencies?

[Steffen Möller]

Hello,

When packaging, it typically happens that there is the tool you really
want to package and a set of build dependencies that you package with it
because they are build dependencies. So, after lots of packaging,
packaging, packaging,  you eventually get the package of interest to
build and test properly. Now you want to upload and forget until there
is a new version.

What has bitten me a few times is that I sequentially (package with no
dependencies first)  uploaded to the new queue. One then has a couple of
packages in there. And then the first-uploaded leaf package gets
rejected. There is then no need whatsoever for the ftpadmins to inspect
all reverse dependencies. And it also happens that I miss the rejection
email that GMX often directs to my spam folder - not helpful. I have
since started to just upload to salsa and to only upload once the build
dependencies are in the distribution. But I then also forget about them.
And I _want_ to the luxury not need to think about them. My mind should
be busy with other things.

Would it be helpful to transform our New Queue to a New Tree? To a New
DAG? Packages rejected from the queue should be indicated as a "ghost
package" when there are dependencies? Maybe link rejected packages with
their whereabouts on salsa to invite for team maintenance? This may then
look a bit like a "packaging management system".  Would this be a
reasonable Google Summer of Code project for 2020?

Cheers,

Steffen

Should we list Patreon funding pages in d/u/metadata?

[Steffen Möller]

Hello,

at times I now find pointers to Patron (https://www.patreon.com),  
Flattr (https://flattr.com/) et al. 
(https://alternativeto.net/software/patreon/)  in the READMEs of a 
software I am about to package. Is this something that should be 
referenced in debian/upstream/metadata? Anything speaking against it?


The place this should go to IMHO is d/u/metadata.  Something like:

Donations:
 - Name: Patreon
    Entry: ImGui

These kind of requests are not too frequent, yet. I hence expect this to 
be a bit of a side-issue for everyone. Anyway - I think it is a nice 
gesture. And upstream should appreciate this extra effort to help them.


Best,

Steffen

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Steffen Möller]

Hello,

On 09.09.18 02:11, Russ Allbery wrote:
> Paride Legovini  writes:
>
>> However, there are clearly cases where renaming binaries makes several
>> people unhappy (most likely: the package maintainers, upstream, people
>> writing scripts, users of different distributions), while not making a
>> single user happier. This is especially true with low popcon packages
>> with a small use case intersection.
> If the packages conflict, though, this is extremely unfriendly to the
> users who do want to use both packages.  They cannot use both packages on
> the same OS installation, and have to resort to chroots or VMs or
> containers, which is a lot of extra complexity.  I'm therefore in favor of
> keeping Policy's prohibition on using Conflicts for this case; maybe a
> combination of two packages will get lucky and there will be literally no
> users who want to use both at the same time, but it's very hard to tell
> when that's the case and the failure mode is ugly.
>
> I kind of like the solution of putting the binaries in a different
> directory.  This is also a little irritating, since users have to add an
> additional directory to their PATH, but they only have to do that once and
> it works consistently going forward, and they can still use the other
> program.
>
> It's not totally unheard of to have to modify PATH to use a package,
> particularly one that wants to use a bunch of very generic command names.
> That was always the official way to use MH, for example.

You may be referring to some alike http://modules.sourceforge.net/   And
yes, I personally would not mind if Debian packages would have an option
to install into such a module. Actually, this would even help a lot for
the parallel installation of multiple versions of the same
library/binary, which is not uncommon in scientific workflows (sadly).

It seems like I am a bit in a minority position here. And it hurts me to
contradict all those folks who one respects for all the good work they
do. Anyway, in my very humble and personal opinion, the policy of not
having conflicts makes perfect sense for anything that is essential to
have. But for anything optional, well, that conflict is optional, too.
We should allow ourselves to rely more on upstream's communities to take
care not to conflict with names. That is because they talk with each
other and most likely they have an idea what they talk about. If someone
happens to be in two such communities then Debian makes it easy enough
for everyone to just install a package quickly when this is needed and
to then deinstall it when that tool's execution's purpose is done. I
mean, this is why we are doing this all after all. We should take some
pride in what we achieved and tell people to use our package managers
when conflicts arise as a dear exception. Conflicts are natural. We
should find a way to deal with them and not come up with a dysfunctional
world of compromises that annoys by default and not just as a
theoretical construct. Also, I think we can rest assured, if communities
have not talked and named binaries the same, then the conflicts between
the respective packages is what will help to persuade those communities
to adjust their naming.

Cheers,

Steffen

Re: Missing: Mobile Debian-Solution referring to Smartphone Operating Systems (Alternative to Google/Android OS)

[Steffen Möller]

On 8/16/18 5:24 AM, Paul Wise wrote:
> On Thu, Aug 16, 2018 at 12:31 AM, Steffen Möller wrote:
>
>> Would it make sense to join the
>> https://docs.automotivelinux.org/docs/getting_started/en/dev/reference/homescreen/index.html
>> crowd?
> Automotive and mobile are quite different form factors. Also, I'd
> expect that even if a car was running a Debian derivative or another
> Linux distribution, it would be locked down (either technically or via
> legal instruments) such that one could never gain control over the
> system to install plain Debian.
I do not necessarily want Debian in my car. But I could well imagine that
I want to continue working with an application that I had worked with
during a plane or train or car ride.
> That said, packaging AGL or other
> automotive components could be useful if we want to attract
> manufacturers to basing their systems on Debian and sponsoring
> DebConf. For end-users though, probably not so much.
It could well be in the interest of car manufacturers to see

more of their applications on people's desktops, indeed.

Cheers,

Steffen

Re: Missing: Mobile Debian-Solution referring to Smartphone Operating Systems (Alternative to Google/Android OS)

[Steffen Möller]

On 8/15/18 1:53 PM, Paul Wise wrote:
> On Wed, Aug 15, 2018 at 7:35 PM, Steffen Möller wrote:
>
>> https://wiki.debian.org/Teams/DebianFSO may be worth a look. I mean, we
>> once had the complete stack in Debian. I do not think that work
>> transitioned to salsa.
> The packages have been removed from Debian already and upstream isn't
> really active any more. The whole stack from the OpenMoko days, all
> the way down to apps and games has bitrotten and or disappeared from
> the web.

Would it make sense to join the

https://docs.automotivelinux.org/docs/getting_started/en/dev/reference/homescreen/index.html

crowd?
https://events.linuxfoundation.org/events/elc-openiot-europe-2018/ has
last year's keynote.

Steffen

Re: Missing: Mobile Debian-Solution referring to Smartphone Operating Systems (Alternative to Google/Android OS)

[Steffen Möller]

Hello,

On 8/15/18 12:30 PM, W. Martin Borgert wrote:
> Dear Andreas,
>
> Quoting Andreas Jakowidis :
>> Because of a long experience in developing Debian-Software since the
>> year
>> 1995 it would be
>> important/necessary for everyone if you could offer Debian also as a
>> mobile
>> solution
>> for smartphone hardware in near future.
>
> Debian has a long history on mobile devices, going back to the Nokia
> N770¹
> and the OpenMoko². For current developments, please check the Debian
> mobile
> wiki page³, mailing list⁴ and IRC channel⁵.

https://wiki.debian.org/Teams/DebianFSO may be worth a look. I mean, we
once had the complete stack in Debian. I do not think that work
transitioned to salsa.

Cheers,

Steffen

>
> Recent mobile devices running Debian or similar are the e.g. GPD Pocket⁶,
> the Purism Librem 5⁷ (maybe available next year), or the Pyra Handheld⁸
> (maybe available this year).
>
> There are also developers trying to run Debian on different Android
> devices,
> with different levels of success. Very often, it is not possible to
> update
> the kernel, because drivers are not upstreamed or even non-free.
>
> Cheers, Martin
>
> ¹ https://en.wikipedia.org/wiki/Nokia_770_Internet_Tablet
> ² https://en.wikipedia.org/wiki/Openmoko
> ³ https://wiki.debian.org/Mobile
> ⁴ https://lists.debian.org/debian-mobile/
> ⁵ #debian-mobile on irc.oftc.net
> ⁶ http://www.gpd.hk/gpdpocket
> ⁷ https://puri.sm/shop/librem-5/
> ⁸ https://pyra-handheld.com/boards/pages/pyra/
>

Re: Should the weboob package stay in Debian?

[Steffen Möller]

On 7/22/18 2:50 AM, Wookey wrote:
> On 2018-07-21 12:54 +0200, Wouter Verhelst wrote:
>> On Fri, Jul 20, 2018 at 01:34:19PM +1000, Dmitry Smirnov wrote:
>>> I refuse to judge the matter with my feelings.
>> Rationality has a place, but so do feelings.
>>
>> The names in this package are offensive, plain and simple. 
> _To_some_people_. 
>
> I think they're funny, which I think is what was intended by
> upstream. I enjoy a gratuitous boob-or-handjob mention as much as the
> next 14 year old. On the other hand I don't think the homophobic
> user-abuse is funny, but the authors probably do/did (apparently still do
> given the change from 'fag' to 'soyboy').
>
> Yes, it's pretty-much the definition of puerile humour. No it's not
> inclusive or welcoming. But on balance I think we should err on the
> side of live and let live, because this is a very diverse place, we
> don't agree on much beyond the benefits of free software, and
> providing useful software in Debian is a good thing for all our
> downstreams to choose from.
>
> So yes, I'd leave it in, whilst encouraging upstream to reduce the
> laddishness, because that is offputting for quite a lot of people, and
> is just no longer cool amongst adults. (if it ever was).

I think we are mixing two discussions here. One is, if the humor shown
is offensive for Debian to redistribute it. The other is, if the package
treats fellow-humans that have boobs (females, older males, others)
particularly badly.

>From what I observed in this thread, few consider the package to be
unbearingly offensive in its own right. This is in particular so since
the names of binaries are only seen after the installation. "weboob" is
a "web"-tool and shall be read as "web-oobs" by the unprimed reader.

This leaves it to the concern focusing with the naming on a body feature
that is mostly associated with females. I hence suggest to add
semantically mostly equivalent names that refer to features mostly
associated with males. Here some suggestions for the ones considered
most disturbing:

wetboobs -> dripdick
handjoob -> handjob
boobtracker -> dicktracker
flatboob -> accomodick
boobooks -> readick
boobcoming -> dickoming


This way, basically short of a dh_links instruction, we would maintain
our gender balance and don't start censoring what typically ends with
puberty, anyway.

Cheers,

Steffen

Re: Hi, I am blind

[Steffen Möller]

Hi,

the Debian derivative KNOPPIX comes with a boot option "adriane" that 
may help you.  An English page I found on 
https://www.dedoimedo.com/computers/knoppix-adriane.html which is a bit 
old (2009). The latest version with the Ariadne boot parameter is 
described and downloadable on 
http://www.knopper.net/knoppix/knoppix810.html .


The problem with Debian for supporting blind users is that most of its 
developers are not (yet) visually impaired beyond wearing glasses. They 
don't have the devices which are costly and even if they had then they 
likely have nobody to test it. I have no immediate idea how to help that 
situation.


Cheers,

Steffen

salsa editor omits \n at end of file

[Steffen Möller]

Hello,

not only for files newly created but also for changes done to the end of 
a file, there is no terminal \n.


Knowing that I will now just go and add an extra empty line at the 
bottom of the text/source code files edited, but, well, maybe there is a 
bit more UNIXish solution to that?


Cheers,

Steffen

Re: Bug#880014: Technical committee appointment

[Steffen Möller]

On 3/26/18 10:29 PM, Geert Stappers wrote:

On Mon, Mar 26, 2018 at 10:18:18PM +0200, Thomas Goirand wrote:

On 03/16/2018 07:51 PM, Gunnar Wolf wrote:

I have to pick a nit here - I know this mail probably comes from a template
and you are repeating what used to be true here. But, according to GR
003 in 2016¹, Didier is the "Chair" of the Technical Committee, not
the "Chairman".

¹ https://www.debian.org/vote/2016/vote_003

Does this mean tech committee members can sit on Didier? :)

Yes, sit without h


Maybe just "rely on him" or "rest assured".

Re: A proposal for improving transparency of the FTP NEW process

[Steffen Möller]

On 3/3/18 7:54 AM, Lars Wirzenius wrote:

On Fri, 2018-03-02 at 22:05 -0600, Steve Robbins wrote:

I assume that the reason my packages have been processed is due to one

of two reasons: a) I get quoted on LWN several times a year, so I'm a
celebrity and get special treatment

I expect that's it.

For the avoidance of doubt, especially for onlookers: I was, of
course, being sarcastic with that LWN command, and I think Steve is
continuing by being deadpan sarcastic in response.

I wish text/plain carried font information so I could use a font to
indicate when I'm being sarcastic (Times, Helvetica, or Courier).


But you are a celebrity. Just not the kind of celebrity that gets
free coffee at Starbucks, though. Except for when you fix their Wifi,
I mean. But if I was an ftpadmin and saw a package of yours uploaded,
you'd find me priorising this up ... and if there is not something
more interesting like a new version of bsdgames that one needs to
quality-control ... being a tech-celebrity must be good for something.

And nobody diss sarcasm, please. It is a tremendous helper,
not only to stay mentally afloat but also for brain storming to help
stimulating lateral thinking. It is mainly problematic in broadcast
communication like mailing lists when you do not know with whom
you are working with.


Or possibly you have a more generous notion of "fast".  Currently there are
five or six dozen packages waiting more than 2 months.  That's not fast in my
books.

By "fast" I mean "less than 24 hours". I uploaded vmdb2 (new source
package) about a month ago. The timestamp of the mail saying it's
going into the NEW queue is 16:27. The ACCEPTED mail has a timestamp
of 18:00. That was on February 10.

I had this, too. Just yesterday. Thrice. My fourth package had a problem,
which I kind of knew when it was not going through as quickly.

Admittedly, it is quite a small package, but that's kind-of my point.
Making it easy for others to do the thing you need them to do is what
you can do to make things easier for you. Asking them to do more work,
or to change how they do their thing, is less likely to go well.

The Linux kernel maintainers flat-out reject large patches that dump
big changes without prior discussion. This is because it's easier for
them to digest changes in smaller chunks, and they put the
responsibility for presenting the changes that way on the people
producing the patches.

For Debian, I think we should have the same approach. Not literally
the same approach, of course, since that would mean having the Debian
package maintainer refactor the upstream code into smaller programs,
and that would just be silly.


I disagree here. We think in units. What is released together should not
be split into multiple source packages with Debian. I am still living
through that with my mgltools packages that made everyone unhappy,
also making my communication with upstream more difficult. And the
overall workto review it all is the same.


But the same approach of making it the
uploader's responsibility to present a new package in a way that makes
it easy to review it. This includes making copyright information easy,
and working with upstream to make it clear, possibly by using SPDX
markup for copyrights and licensing. For all of Debian it meants
finding or developing tools for automating extraction of copyright
information into debian/copyright in whatever manner is needed.
We have licencecheck, and if that isn't good enough, we can improve
it.


Ha! And here I agree again. We should somehow improve our infrastructure
to allow for

 * an increase automation, e.g. by something like debian/licencecheck
   to  help customizing the otherwise unknown licenses* replies to the 
ITP with


 * issues to address prior to a reload? issues on salsa?Just a nything that
   renders the ftpadmins' reviewing reentrant.

 * maybe ftpmasters can delegate some work to an individual they trust
   for some particular checks when the source tree is on salsa? We would
   effectively then have temporary volunteer ftpadmin assistants.


There may be other reasons why some packages stay in NEW for a long
time. Getting information from ftp masters about the reasons why, and
a discussion of how we can make easier for them to make NEW review
easier would, I feel, take us forward better than another than us
complaining that things are taking too long.


Yes. I am very happy not to be an ftpadmin and cannot thank our
ftpadminning peers enough for their efforts. Our current infrastructure
is not really set out to be communicative in that process.

Steffen

ITP: pluto-jpl-eph -- command line handling of JPL ephemeres data

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name    : pluto-jpl-eph
  Upstream Author : Bill Gray
* URL : https://github.com/Bill-Gray/jpl_eph
* License : GPL-2
  Programming Lang: C++
  Description : command line handling of JPL ephemeres data

The package is prepared on 
https://salsa.debian.org/debian-astro-team/pluto-jpl-eph

Re: Auto-update for sid? Auto-backport?

[Steffen Möller]

Hi Jeremy,

On 18.11.17 01:12, Jeremy Bicha wrote:
> On Fri, Nov 17, 2017 at 7:00 PM, Steffen Möller <steffen_moel...@gmx.de> 
> wrote:
>> If the positive vibes I have felt are kept up then I propose the
>> individuals running relevant services in/around Debian (ftpmasters, web,
>> backports, mentors, ...) determine what team then takes that summary to
>> transform it into a white paper that proposes steps to address so we
>> eventually have something to have a vote about?!
> Why don't you (or someone) work on an opt-in service to help automate
> everything *except* for the actual upload to Debian part? Since that's
> the part that is controversial and complicated to set up in a trusted
> way. I don't think you need a vote to work on implementing and
> offering the rest.
I was impressed by the work that Guido has described (see
https://lists.debian.org/debian-devel/2017/11/msg00154.html).
He would certainly be one of the first individuals I feel like contacting
about something from where to grow.

My request was less about the technicality and more about learning
to what degree what kind of uploads would find general or partial
acceptance in our community.

But you are right, an external service is a safe bet as a first start that
we do not need to vote about - nor would I need to ask ;) However,
any such automation is something, if brought closer to Debian, that
has the potential to change us quite a bit. I felt that more than one
individual should be involved and at least should I myself be the
one to set it up, I would want (most of) you (all) to want it.

Best,

Steffen

Re: Auto-update for sid? Auto-backport?

[Steffen Möller]

Dear all,

On 15.11.17 16:43, Steffen Möller wrote:
> [question about how to realise auto-updated packages]
>

Thank you tons for all your nice and constructive ideas, experiences and
comments.

My (biased) impression is that there is a majority in favour of some
automation to become an option for routine package maintenance. We just
do not know how this should look. But we do know that this is dangerous
to have and by no means applicable to packages of all sorts and the
maintainer and the maintainer's responsibilities shall not be circumvented.

I do not know how to best proceed. Shall we collect more emails for a
week and I (or preferably some less biased observer) then summarise(s)?
If the positive vibes I have felt are kept up then I propose the
individuals running relevant services in/around Debian (ftpmasters, web,
backports, mentors, ...) determine what team then takes that summary to
transform it into a white paper that proposes steps to address so we
eventually have something to have a vote about?!

Best,

Steffen

Auto-update for sid? Auto-backport?

[Steffen Möller]

Hello,

my QA page or our blend's task page (like
https://blends.debian.org/med/tasks/bio-ngs) regularly informs me about
updates that should be performed to packages I alone maintain or (more
likely) with the help of my blend. The updates are often (but now
always, admittedly) easy to do.

I would really like to see updates performed in some automated fashion.
Maybe into a different section of Debian like sid-auto? The problem with
that obviously is the missing scrutiny by the human maintainer, so it
cannot go straight into sid. Or can it? Maybe with an auto-created bug
report against the package so it does not auto-migrate into testing?

A similar situation I see with backports. Most commonly all that is
needed is a recompilation. Would an automation of that process be
acceptable? Would it be acceptable for packages that offer some means of
automated testing and are in backports already?

Many thanks for your opinions

Steffen

references to software catalogs

[Steffen Möller]

Hello,

Because of ever-more complicated workflows in computational biology,
researchers combine more and more tools within a project and people
start getting confused over what (flavour of) tool has been involved in
an analysis when exchanging worklows or when skimming through notes of
an analysis done a few years back. To help this situation, the old
concept of software catalogs and assigning IDs to software has gained
some new attention.

We have come up with an extension to the debian/upstream/metadata file like

Registry:
 - Name: NameOfCatalog
   Entry: SoftwareIdentifier

and at the moment support SciCrunch RRIDs, OMICtools and bio.tools.
These IDs are earmarked to eventually appear on the Debian Med task
pages and point to the external source, which in part already point to
Debian (like OMICtools) and add additional information helping our users
like informing on similar tools or about tools co-cited in scientific
publications. This is meant to help our users to craft better workflows
more quickly. And it helps our visibility, too.

Also for less scientific software it may be of interest, e.g. for our
package trackers, to point to catalogs. I just now found
https://en.wikipedia.org/wiki/Open_Hub and find to like it. There may be
others. What does our community think? There is
https://www.openhub.net/p/inkscape and one could add

Registry:
 - Name: Open Hub
   Entry: inkscape

to debian/upstream/metadata to give whoever is interested the
opportunity to add a pointer to or from that catalog when talking about
that software. I would not place the full URL since those paths are not
unlikely to change over time.

The immediate concern is obviously yet another overhead that we impose
on our developers. But once we have everything in the successor of
alioth, I see this to be a very inviting first contribution by our next
generation of developers or just some motivated users of ours. So, the
overhead should not be too bad for us.

Please discuss.

Many thanks

Steffen

Re: Call for volunteers: FTP Team

[Steffen Möller]

On 18.08.17 09:33, Joerg Jaspert wrote:
> On 14768 March 1977, Philip Hands wrote:
>>> ...Well, in keeping with the Toy Story theme, FTW Masters is
>>> worshipped by the Squeezes (packages alien to the archive) and at the
>>> time of a "Win" a package new to the archive is selected as for the
>>> "World".  Finally, New Maintainers tremble with trepidation at the
>>> power of The Claw, as it is known internally.
>> I like "The Claw" -- responsible for picking up NEW packages, and giving
>> them to the kids, or dropping them.
> Don't you all have something more important to do?
>
Something more important than to point out that besides deciding on
a new name we may also waste more time on deciding how it shall be
pronounced?

In analogy to once upon a time "netscape" being pronounced "mozilla"
we could leave the name "ftp-team" and pronounce it "pinocchio".

No, I am not serious. Thank you for all your good work!

Steffen

Re: User-installable Debian packages?

[Steffen Möller]

On 30.07.17 13:47, Simon McVittie wrote:
> On Sun, 30 Jul 2017 at 19:34:42 +0900, Benda Xu wrote:
>> As far as I can see, the easiest relocations are those modifiable in a
>> plain text, like configuration file, script shebang, etc.  The medium
>> ones are ELF, with which we have tools like patchelf and chrpath, etc.
>> The most difficult part includes quite a few hidden path assumptions
>> that can only be specified at build time, like the default GCC include
>> dir.  I don't know whether distributing binary packages can alleviate
>> the barrier.  Chances are many patches are needed to be carried to be
>> able to override paths at run time.
> Lots of packages hard-code paths at build time. This is often not
> considered to be a bug.
>
> Flatpak's approach to this is to use bind-mounts (in a new mount
> namespace set up by bubblewrap) so that the "app" (the leaf package,
> together with any libraries that are bundled with it) always appears
> to be installed in --prefix=/app, which can safely be hard-coded into
> binaries that are built as Flatpak apps.
>
> Flatpak apps are normally recompiled from source with --prefix=/app,
> but I don't think it's coincidental that /app is the same length as
> /usr and can therefore be patched in with a binary editor as a last
> resort :-)
>

Users will not care if it is flatpak, singularity, conda or prefix -
they want
all the packages and the packages shall work. What I like about all of these
efforts is that from what I grasped we will stop caring too much about
backports.
Also, what is today a bit clumsy to use because of all the dependencies,
may become easier: snapshot.debian.org, once it decides to also monitor
flatpaks, I mean.

What it somewhat boils down to me is that we need to decide about  the
roles a Linux distribution shall have. And if we want problem-centric
communities (like BioConda) to come up with a pan-distributional
gentoo-prefix-like setup. The folks that are only after the immediate
scientific
findings will go for the community-effort. Those aiming for more, and
here I see all the effort that goes into
 * package description + translation
 * man pages
 * hardened builds
 * reproducible builds
 * continuous integration tests (ok, BioConda does those too, now)
 * redundancy removal between packages
I see our distribution's infrastructure as still relevant and also as an
important momentum to drive the developments on upstream's side.

To me, Singularity solves quite a bit as of today. But to win the
contributors
to BioConda of today, we would need to change a lot. Most drastically is the
need for immediately relevant user feedback. The conda/brew folks solve
that by
github forks of their build instructions, which every user can
immediately use.
Debian falls behind on that front. And even when Debian decides to
eventually
surface more with its package build instructions, we would not have anything
in place for users that want the binary update _now_ and not after an
upload plus
a likely manual review.

So, for embracing our users more, we need to
 * allow them to install packages as users, not only as admins, which is
what this thread is mainly about
 * allow them to seamlessly give feedback from which they can
immediately benefit, which I do not see how to address without an
autogenerated launchpad.

Need to think about it all,

many thanks for all your constructive feedback

Steffen

Re: User-installable Debian packages?

[Steffen Möller]

Hi Benda,

On 30.07.17 09:37, Benda Xu wrote:
> Hi Steffen,
>
> Steffen Möller <steffen_moel...@gmx.de> writes:
>
>> I just had a quick look and it seems really nice, indeed! Thank you tons for
>> pointing that out to us. Has anybody already tried that with Debian?
> I am one of a few guys behind that project.  Gentoo Prefix with its own
> libc runs on Debian very well, the explicity tested distributions are
> listed at,
>
>   https://wiki.gentoo.org/wiki/Prefix/libc#Tested_distributions
>
> The highlights are:
>
>   1. you can compile almost any package available in Gentoo.
>   2. you can run x86 Gentoo Prefix on a amd64 Debian, thus another form
>  of multiarch.
>
> The downside compared to Debian and any binary distribution is that,
> everything need to be compiled from source.  That's slow.
>
>
> A preliminary draft has been prepared to discuss its use on HPC
> environments:
>
>   https://arxiv.org/abs/1610.02742
>
>
> Alternative projects are _spack_ and _easybuild_, with slightly
> different motivations and implementations.
>

This is good to hear. While I like all that I read about Gentoo, I do
not know about how well equipped it is with packages in computational
biology [edit: I had a look at
https://packages.gentoo.org/categories/sci-biology and am impressed,
well done!]. This is where BioConda (bioconda.github.io) is very strong
now. And while the Conda community gets increasingly sophisticated with
their packaging, we can decide to either just let them go for it or to
find ways to compete. These folks start as low as libz, i.e. just above
libc, really. I hence tend to think that it is something that we as a
Linux distribution should care about.

I have followed Johanness' link to
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap but frankly do
not yet know how to transform that into something computational
biologists would like to use and trust more than Conda. It would all
start with cross-distribution packages of dpkg, right? And the testing
infrastructure of Debian would need to care for such
off-root-experiences, too. I do not see that just around the corner.

Best,

Steffen

Re: User-installable Debian packages?

[Steffen Möller]

On 29.07.17 17:51, Jeff wrote:
> On 29/07/17 17:26, Steffen Möller wrote: >> The HPC community does not want 
> to need root privileges to get their
>> software installed/used on the HPC setup. This excludes regular >>
Debian packages, traditional containers like Docker and chroot
environments. > I use a gentoo prefix for stuff like this. See > >
https://wiki.gentoo.org/wiki/Project:Prefix
I just had a quick look and it seems really nice, indeed! Thank you tons for
pointing that out to us. Has anybody already tried that with Debian?

Best,

Steffen

Re: User-installable Debian packages?

[Steffen Möller]

On 29.07.17 17:41, Paul Wise wrote:
> On Sat, Jul 29, 2017 at 11:26 AM, Steffen Möller wrote:
>
>> If flatpak is an answer - great. But from what I get, there is no automated
>> transformation from .deb to it, so we would need to decide for packaging
>> in that different format instead of our regular effort.
> We could probably leverage our existing efforts and add a layer on top
> to get Flatpaks out of Debian binary packages. Simon mentioned on IRC
> that he is working on a demo of a Flatpak app produced from the
> corresponding Debian binary package, with a runtime built from Debian
> binary packages.
This sounds great!
If it is any easier, I could also imagine to have a Debian source
package transformed
into a flatpak source package.

Best,

Steffen

Re: User-installable Debian packages?

[Steffen Möller]

On 25.07.17 12:04, Florian Weimer wrote:
> * Simon McVittie:
>
>> On Sat, 22 Jul 2017 at 12:28:04 +0200, Steffen Möller wrote:
>>> And quite some packages in our
>>> distribution do not really need to be installed as root if they were
>>> installed where the user has write permissions. There would hence be
>>> little overhead over what we have now. Should we not somehow find ways
>>> to tag any such location-agnostic packages and prepare dpkg for
>>> installing e.g. in $HOME/.debian when it is executed as non-root?
>> Rather than inventing a new wheel and having another Debian-specific
>> thing that can only be used on Debian (and not even on derivatives
>> without it being a "Frankendebian" system), might it be better to use
>> Debian's source, binaries or a mixture of the two as input to creating
>> something cross-distribution like Flatpak, AppImage or Snap? I would
>> personally recommend Flatpak.
> But it's not clear if the HPC community wants to run
> containers/namespaces at all.  Maybe Steffen can comment.
The HPC community does not want to need root privileges to get their
software installed/used on the HPC setup. This excludes regular
Debian packages, traditional containers like Docker and chroot environments.

If flatpak is an answer - great. But from what I get, there is no automated
transformation from .deb to it, so we would need to decide for packaging
in that different format instead of our regular effort. And then, to me,
flatpak
presents itself much like a regular container, so I do not see an
advantage over
Singularity. But I have no practical experience with it, just correct me
if I am wrong.
Steffen

User-installable Debian packages?

[Steffen Möller]

Hello,

There is a fairly new trend out there, best represented by brew.sh and
conda.io, to have user-installable packages. These come very handy in
HPC-near environments or other shared resources that do not grant root
access. In computational biology it is bioconda that is attracting many
users.

I have not completely thought this through. Admittedly, there is
something in me that says that it does not matter since Debian should
care more about what the OS is and not what the users use on it. But
then again, it is exactly via those user-centric bits that we attract
new developers for our distribution. And quite some packages in our
distribution do not really need to be installed as root if they were
installed where the user has write permissions. There would hence be
little overhead over what we have now. Should we not somehow find ways
to tag any such location-agnostic packages and prepare dpkg for
installing e.g. in $HOME/.debian when it is executed as non-root?

Best,

Steffen

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Steffen Möller]

On 16/05/2017 07:07, Mechtilde wrote:

> these two questions come into my mind: > > What does a "newcomer" expect from 
> such a website? > what do we
expect from a newcomer? >  > To go from user to dev is a gliding
way. > > "Want To Become Debian Developer" is the last step for a dev
not the > first one. IMO > > We should try to differ into the different
tasks for the user e.g: > > * Installation > * Configuration > *
Applications > * ... > * How can I help > * Structure of the Packages >
* Packaging > * ... > > +1

And there is a confusion over "dynamic web sites" (maybe problematic)
with "non-static content" (must have).

We should vividly demonstrate on our home page that we are just that -
alive and developing. If we could have users contribute success stories
like "I switched my Granny from Windows to Debian and she likes it" or
"We autoconfigure our HPC cluster in the cloud with Debian and Ansible,
saving us 30 grand this year" then we have enough to get people hooked
and invest to dig deeper into the site, I tend to think.

So, I see:
 * something along the lines of Mechthilde
 * dynamic user-provided feedback that we can annotate further with
references to HOWTOs etc for new users that want to share that
experience, i.e. a smaller Debian+Derivatives-centric stackoverflow kind
of thing that starts off with a success rather than with a problem

Steffen

ITP: toil -- cross-platform workflow engine

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: toil
  Version : 3.5.0~alpha
* URL : https://github.com/BD2KGenomics/toil
* License : Apache
  Programming Lang: Python
  Description : cross-platform workflow engine

The package will be maintained in the Debian Med git repository.
Toil goes together with the CommonWorkflowLanguage to distribute
processes in distributed environments, which means clouds and
clusters alike.

ITP: python-bd2k -- general utility library for bd2k python package

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-bd2k
* URL : https://github.com/BD2KGenomics/bd2k-python-lib
* License : Apache
  Programming Lang: Python
  Description : general utility library for bd2k python package

The package is a 2nd degree dependency of the Toil workload distributor
expected in Debian any time soon. It is about to be group-maintained at
anonscm.debian.org/cgit/debian-med/python-bd2k

ITP: python-bx -- library to manage genomic data and its aligment

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-bx
  Version : 0.7.2
* URL : https://github.com/bxlab/bx-python
* License : MIT
  Programming Lang: Python
  Description : library to manage genomic data and its aligment

python-bx is a requirement for getting the Galaxy workflow suite closer
to our distribution.

The packaging is maintained by the Debian Med team and hosted on
https://anonscm.debian.org/cgit/debian-med/python-bx.git/

Re: Overall bitrot, package reviews and fast(er) unmaintained package removals

[Steffen Möller]

On 06/04/16 21:19, Wookey wrote:
>> > .. perhaps be more aggressive in
>> > removing software that's no longer useful and just lies in the archive
>> > dormant.
> The fact that Debian has a lot of software is a genuine benefit. Just
> because stuff is old, does not mean it is no longer useful. The
> problem is that we don't really know how to distinguish between
> old-and-just-cruft and old-and-still-handy.
The popcon stats may help.

For the packages in Debian Science and Debian Med I tend to think that
it accommodates a bunch of packages that mostly are of historic value
now. People may  use them to compare how well their new methods compare
against the old stuff but the package itself may not be used that much
and the authors never did much maintenance beyond their scientific
questions, anyway - which is also because of the grant-driven funding
schemes and the scientics moving institutions after some 1-5 years.
Those archeological gems I consider to be valuable, in particular when
original binaries were only offered for the then common but today unseen
platforms like DEC, SGI and Sun. So, we have old-and-just-craft,
old-and-still-handy, and some first-step-on-the-moon kind of packages.

Steffen

That said, now, with Debian-Astro established, do we possibly find
someone to adopt the code and emulators for the Apollo missions
(http://www.ibiblio.org/apollo/) for us? And, no, I do not really think
that footprints on the moon are good for much scientific benchmarking.
Although, who knows, some extraterrestrials may find those more easily
accessible than any such on earth. Uh, bed time.

-flto to become more of a routine - any change in opinion since 2011?

[Steffen Möller]

Hello,

I admit to be a fan of link time optimisation and would like to see this
challenge promoted towards more of a routine challenge to establish for
our packages. I found this informative thread

https://lists.debian.org/debian-devel/2011/06/msg00181.html

that in particular sees the challenge for the buildds to cope with the
additional demands on compute time and/or memory.  With a couple of
compiler versions down the road I still see no conceptional difference,
except that possibly the build demons may have become more powerful
compared with the average package size, especially so for the often
embedded architectures.

Spending most of my Debian time with scientific packages, I see a gain
of speed on those routines as particularly rewarding. And this may also
be a feature that would attract many to our platform as an extra
advantage over the regular self-built or downloaded binary.

Opinions?

Steffen

Re: debian/control: enhanced version dependencies?

[Steffen Möller]

On 15/01/16 09:33, Harald Dunkel wrote:
> On 01/14/2016 10:11 AM, Andrey Rahmatullin wrote:
>> On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
>>> For running a local set of meta packages I would like to
>>> express package dependencies depending upon other packages
>>> installed, e.g.
>>>
>>> Package: xyz
>>> Version: all
>>> Depends: ${misc:Depends}
>>> , dbus (systemd >= 215)
>>>
>>> Hopefully you get the meaning. 
>> I'm not sure I do.
>>
>>> Package xyz could make sure
>>> that dbus is installed, if systemd is installed. (systemd
>>> version 215 itself just recommends dbus.)
>> What if systemd isn't installed? Nothing happens?
>>
> Thats what I was trying to express.
>
>>>
>>> Another example:
>>>
>>> Package: mykde
>>> Version: all
>>> Depends: ${misc:Depends}
>>> . kde-full
>>> , mykde1 (kde-full >= 5:66)
>>> , mykde2 (kde-full >= 5:77)
>>> , mykde3 (kde-full >= 5:84)
>>>
>>> Package mykde1
>>> :
>>> :
>> This is even less clear.
>>
> In this example mykde depends upon kde-full and a set of other
> packages, depending upon the version of kde-full.
>
> I am not proud of the syntax, either. Surely you have a better
> suggestion about how to express this kind of package dependencies.
>
The '|' character to express a condition is already taken,
and so are the parentheses.

How about some Perl-like post-annotation as in

Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 if kde-full >= 5:66
, mykde2 if kde-full >= 5:77
, mykde3 if kde-full >= 5:84

This way you can mix the two semantics

Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 (>= 4.99)if kde-full >= 5:66
, mykde1 (>= 5.0) if kde-full >= 5:77

How long will it take until someone implements tic-tac-toe
with Debian package dependencies? Just kidding.

If the package maintainers get this right, then I
think these logics would indeed help to get Debian systems
leaner and possibly also more stable. But I primarily see
some beauty that intrigues me.

Steffen

Aw: Let's abandon debian-devel.

[Steffen Möller]

Hi Charles,
 
 after unsubscribing from debian-vote, I had a bit of a thought about
 debian-devel, which is hard to follow now, and suddenly I saw something very
 clear.  This year's freeze seems of an excellent quality and promises to be
 brief.  Is that thanks to debian-devel ?  Not much.  Excellent work is being
 done on the Installer and is that thanks to debian-devel ?  Not much.  In 2010
 when I was candidate to become DPL, I wrote that Debian was in growth crisis.
 I think that it never has been so true.  Places like debian-devel, which can 
 be
 instrumental in smaller projects, are very toxic in larger ones.
 
 From now on I will try to see if I can give to Debian the same quality of
 contribution without being subscribed to debian-devel.  And I invite you to
 think about it and *not* to discuss it on this list.
 
 With most of the work done on topic mailing lists, trolls lose the lever 
 effect
 they have when feasting on debian-devel or debian-vote.  Let's make our 
 project
 stronger by reducing thr attack surface for troublemakers.

To me, the Blends of Debian and the many pkg-xyz lists are a bit of an answer.
Those are full with positive vibes, over time and with the help of sprints
we often came to know each other personally, too.

Debian-devel came to have problems. I personally found the answer in asking my
geographically local (and, admittedly, 20 years younger) hackers environment
about the issues that Debian is discussing, thinking that any vote in Debian
should also have me a bit as a representative of my surroundings whenever I
feel undecided. This was quite curative (I suggest to everyone take that
medicine yourselves) and somewhat also returns the strenghts to find the gems
in debian/devel again.

Best,

Steffen


-- 
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/trinity-fd49eeea-cf51-4c93-8402-779c4e2ce46e-1415702045107@3capp-gmx-bs59

Aw: Re: Java 9 dropping support for source/target level 1.5

[Steffen Möller]

 Gesendet: Mittwoch, 16. Juli 2014 um 09:50 Uhr
 Von: Sylvestre Ledru sylves...@debian.org
 An: Matthias Klose d...@debian.org, Emmanuel Bourg ebo...@apache.org, 
 Debian Java debian-j...@lists.debian.org
 Cc: debian-devel@lists.debian.org debian-devel@lists.debian.org, Debian 
 Release debian-rele...@lists.debian.org
 Betreff: Re: Java 9 dropping support for source/target level 1.5

 On 15/07/2014 23:55, Matthias Klose wrote:
  Am 15.07.2014 23:08, schrieb Emmanuel Bourg:
  This was expected but now it's effective, Java 9 no longer supports
  source/target level 1.5:
 
  http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-July/000972.html
 
  So if you update a package and see these settings please bump them to 1.6.
 
  It might be interesting to add a Lintian warning when a jar with the
  class format = 49 is detected, that would mean the package was compiled
  with a target = 1.5 and will probably fail to build with Java 9.
  No. Don't do it. This is complete bullshit for Debian at this point.  We are
  trying to prepare a release, working on a possible update to Java 8, and we
  don't have the resources to work on Java 9 at this time.
 
  You seem to have your own agenda, but it doesn't seem to match Debian's 
  agenda.
 
 I think that is unfair statement against Emmanuel (especially when
 adding d-d  d-r to the cc list).

+1, shocking.

Steffen


-- 
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/trinity-34c90251-3d4c-47f6-b78a-65cf0a93dac8-1405503631555@3capp-gmx-bs52

Aw: Re: Valve games for Debian Developers

[Steffen Möller]

Hello,

 
  (what, am I the only old grump who's not attracted to game playing?)
 
 I'm attracted to game playing. But not to offers of software on non-free
 terms, regardless of price.
 

I suggest to halt thinking about game playing. What about game producing?

Tech aspect:

To have Debian-based game development eased with the help of Valve will
help our distribution in many ways, and if it is only to get NVidia and AMD
interested in us more than they were in the past.

Social bits:

I will get really excited about the community aspect of it all. With
the Debian community Valve gets a bunch of individuals that are
all exceptionally well trained, are willing to share code among
themselves and beyond, and function as a community with annual conferences,
Sprints, local outreach etc.  I have little doubt that there will some
enthusiasts among us who will produce bits and pieces with Valve's
technologies and will know how to explain what they did to everyone.
And, conversely, I would like to see those interested in game development
have more of a chance to find a community that is also interested in
the lower levels of their machine. Who knows about what ideas may 
come up from such gatherings - maybe even something educational.

Wish bits:

Raspbian is a another gem, attracting many more individuals to .deb
distros and establishing some twilight zone between embedded and
desktop bits. Can we have more of this?

Cheers,

Steffen


-- 
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/trinity-006bcbf8-dc62-478a-8fd4-a824f98ffa14-1390740987489@3capp-gmx-bs37

Aw: Re: Bits from ARM porters

[Steffen Möller]

Hello,

 That being said: becoming a DD would be ok for me, but would it be ok with 
 the project as well? The scope of my work would be rather limited, I think... 

We have non-programming DDs
http://www.debian.org/News/2010/20101019 
http://www.debian.org/vote/2010/vote_002
which is not exactly what we want since those lack the upload privileges, but 
it would get Ingo the (overdue) member status.

Cheers,

Steffen


-- 
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/trinity-5dca2fdc-1cc5-41f4-94a2-815aa54a26c2-1386160598187@3capp-gmx-bs36

Aw: Re: Reporting 1.2K crashes

[Steffen Möller]

 Gesendet: Donnerstag, 27. Juni 2013 um 14:21 Uhr
 Von: Paul Tagliamonte paul...@debian.org
 An: Alexandre Rebert alexandre.reb...@gmail.com
 Cc: debian-devel@lists.debian.org
 Betreff: Re: Reporting 1.2K crashes

 On Tue, Jun 25, 2013 at 01:28:10AM -0400, Alexandre Rebert wrote:
  I am a security researcher at Carnegie Mellon University, and my team
  has found thousands of crashes in binaries downloaded from debian
  wheeze packages. After contacting ow...@bugs.debian.org, Don Armstrong
   ^^ wheezy :)
 
  advised us to contact you before submitting ~1.2K bug reports to the
  Debian BTS using mainto...@bugs.debian.org (to avoid spamming
  debian-bugs-dist).
  
  We found the bugs using Mayhem [1], an automatic bug finding system
  that we've been developing in David Brumley's research lab for a
  couple of years. We recently ran Mayhem on almost all ELF binaries of
  Debian Wheezy (~23K binaries) [2], and it reported thousands of
  crashes.
 
 One such crash was reported on a small fluxbox tool to be manually run,
 which used $HOME blindly. When it ran, it segfaulted, which is a bug,
 yes.
 
 However, it's not security, and to see the bug tagged 'security' was
 troubling - what oversight do you have to prevent the security team to
 get flooded with such bug reports (this bug is not a security risk.)
 

I wished the respective report would have been sent to the upstream developers,
not to Debian. We could have been a second resort when upstream does not
react to the reports (not unlikely, admittedly). Now, the Debian maintainer
sees the findings two weeks before the bug is made public. I do not feel this
to be right.

Steffen

Steffen


-- 
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/trinity-a27b0448-d731-4ad0-8976-c99bcb8f4add-1372338916014@3capp-gmx-bs49

Aw: KickStarter for Debian packages - crowdfunding/donations for development

[Steffen Möller]

I am less critical about it - it just should remain outside Debian. We would 
gain a deb-store, I presume. The ties should be more with the respective 
program's developers than with us the Debian community. After all, the money 
would flow because of the functionality, not because of the availability for 
the disitribution.

Any particular support from the Debian community would be nice, but if the 
concept works, then this would not be required. 

Cheers,

Steffen


-- 
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/trinity-c368a183-4a11-4e9f-99cb-47bfa8f8e923-1371207111589@3capp-gmx-bs28

ESA's SOCIS Programme (GSoC analog) and Debian?

[Steffen Möller]

Hello,

The European Space Agency comes up with another run of its Summer of Code
  http://sophia.estec.esa.int/socis2013/?q=timeline
and at least little me would like to see Debian to participate. We are
already on the Space Station, after all. And we had at least one DD on
it, too.

I am not sure about what exact project there could be for us. But if
we accept for a moment Debian can contribute to the dissemination of all
the software produced anywhere within the ESA SoC, then we should fine
our niche, I am somewhat confident. We help bringing people together,
vertically (professionals with students/hobbyists) and horizontally
(students and professionals of different projects among themselves). And
this is all much like what this SoC is after in the first place.

With not too many negative vibrations following this email, I would
then ask our DPL to assembl a team of volunteers to craft the application
as a mentoring organisationnot truly knowing if this is the way to go
for it, well, you'll tell me.

Cheers,

Steffen



-- 
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/trinity-3dc4ebc7-16ee-48ee-bfbe-be7f161c66fb-1370440270483@3capp-gmx-bs01

Aw: Re: Candidates for removal from testing (2013-06-04)

[Steffen Möller]

Hi,

 On Wed, Jun 05, 2013 at 09:37:54AM +0900, Charles Plessy wrote:
  Le Tue, Jun 04, 2013 at 02:06:26PM +0200, Niels Thykier a écrit :
  
   Our automated tools for finding RC buggy leaf packages in testing have
   found 79 potential candidates (see attached files).
  
   The packages have been selected based on the following criteria:
* The package had at least one RC bug without activity for the past
  14 days.
* If a bug is assigned to multiple packages, both packages will be
  affected.
* The RC bug affects both unstable and testing.
* The affected package does not have any reverse dependencies in
  testing.
 
  Thanks a lot.

 +1

I also like it, somewhat, but am also aware of this approach rendering
unstable more stable than testing. I would prefer another kind of punishment
for neglect / some difficulty than the mere removal.

  Please do not hesitate to remove leaf packages like mira
  in an automated manner.

 ... which does not mean that we (= Debian Med team) are not working on
 it - we just did not managed to find a solution.

I was not aware of it. And even that I am now, I do not have the time to
address this within the next 14 days. So, hm, ... those 14 days are truly
challenging.

Steffen


--
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/trinity-ae369310-002e-4f23-9c9f-acfeeca278ba-1370441714196@3capp-gmx-bs01

Aw: Re: DPA instead of PPA

[Steffen Möller]

Hello,

Von: Steve McIntyre st...@einval.com
An: debian-devel@lists.debian.org
Betreff: Re: DPA instead of PPA
In article 518b7cf6.3080...@debian.org you write:
On 09/05/13 07:38, Raphael Hertzog wrote:
 bikeshed \o/

You probably meant this to be a comment on the discussion rather than a
suggested name, but until it gets uploaded to unstable, you can get
GNOME 3.8 from the GNOME Team bikeshed actually sounds like a
reasonable sentence to write. :-)

+1 for the bikeshed name. I think it's a *perfect* fit! :-)

A +1 also from my side for using bikeshed instead of [DP]PA
for the Debian PPAs, so they would become Debian bikesheds.

Steffen


--
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/trinity-a063e78e-c6b2-4131-8bfa-7634363148bb-1368527437187@3capp-gmx-bs42

Allowing multi-arch specs in depends line?

[Steffen Möller]

Hello,

I prepared a package for BOINC (http://boinc.berkeley.edu) with all the 
dependencies for owners of CUDA-savvy NVidia cards to help
installing the libraries. Since many scientific applications with BOINC only 
have 32bit binaries, there are extra dependencies for
the amd64 platform on the respective 32bit variants. This looked like
libcuda1-ia32 [amd64]|nvidia-current [amd64]
in the past and was just fine. But recently the nvidia drivers became 
multiarched, so libcuda1-ia32 no longer exists. A respective
update built nicely, but lintian complains:

E: boinc-nvidia-cuda: bad-provided-package-name libcuda1:i386

The package name is fine, it is even installed:

$ dpkg -l libcuda1* | egrep '^(ii|\|\|)' | awk '{print $2,$3,$4}'
Name Version Architecture
libcuda1:amd64 304.37-1 amd64
libcuda1:i386 304.37-1 i386

Is there another way to express the dependency? Or is this a lintian bug? I 
found my specification rather intuitive.

Many thanks for your insights

Steffen


-- 
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/502f941a.5040...@gmx.de

buildd on Armel, PowerPC and S390(x)? agree on narrowing error, why?

[Steffen Möller]

Dear list,

I just sponsored a package that built nicely locally with g++ 6.4.2-5 on
amd64 but fails on the platforms listed in the subject line:

https://buildd.debian.org/status/package.php?p=ballsuite=sid

which gives plenty of repeats of

 .. /source/DATATYPE/hashGrid.C:23:3: error: narrowing conversion of 
'-0x1' from 'int' to 'const char' inside { } [-fpermissive]


I am starring at it for a while now and googled, and from
From http://msdn.microsoft.com/en-us/library/c70dax92.aspx I can understand 
that
the regular 1 is taken as an integer constant. So in the code below it should
instead possibly read {'\0', '\1', (char) -1 }  for {0,1,-1} ? I would not like
that too much. And even if so, all platforms should behave the same.


#include BALL/DATATYPE/hashGrid.h

namespace BALL
{
namespace __private
{
const char neighbour_table_[27][3] =
{
{ 0,  0,  0 }, { 0,  0, -1 }, { 0,  0,  1 },
{ 0, -1, -1 }, { 0, -1,  0 }, { 0, -1,  1 },
{ 0,  1, -1 }, { 0,  1,  0 }, { 0,  1,  1 },
{-1,  0, -1 }, {-1,  0,  0 }, {-1,  0,  1 },
{-1, -1, -1 }, {-1, -1,  0 }, {-1, -1,  1 },
{-1,  1, -1 }, {-1,  1,  0 }, {-1,  1,  1 },
{ 1,  0, -1 }, { 1,  0,  0 }, { 1,  0,  1 },
{ 1, -1, -1 }, { 1, -1,  0 }, { 1, -1,  1 },
{ 1,  1, -1 }, { 1,  1,  0 }, { 1,  1,  1 }
};
}
}

/// file ends here

where the header file reads

namespace BALL
{
namespace __private
{
extern const char BALL_EXPORT neighbour_table_[27][3];
}



}


Gcc 4.6.2-5 on amd64 does not complain at all. I do not know the version of gcc 
on the buildds.

Suggestions?


Many thanks


Steffen


-- 
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/4ee1d7cf.2040...@gmx.de

Re: Bug#643669: ITP: pp-popularity-contest -- PredictProtein popularity contest

[Steffen Möller]

Hello,

I am Laszlo's sponsor.

On 09/28/2011 05:01 PM, Simon McVittie wrote:
 On Wed, 28 Sep 2011 at 16:38:11 +0200, Laszlo Kajan wrote:
 Without the funding received based on the usage statistics you contribute by
 installing this package none of the packages on Debian could have been made
 available to you at no cost.
 
 I'm pretty sure that's not true. None of the PredictProtein packages, maybe...

:)

The wording of the package's description leaves some room for optimisation.

 Would data from the normal popularity-contest package be enough for your
 usage statistics?

Upstream (the group Laszlo works in) thinks no. I am sponsoring the package
since there is no hidden activity, and the contribution to the statistics is
completely voluntary, even the reminder can be switched off with a mere touch.
This sounds fair enough to me.

I appreciated the separation of that counting facility into its own package
and anticipate its development into a PP-independent library.

Cheers,

Steffen


-- 
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/4e84503b.8090...@gmx.de

Re: Status of circulars dependencies in unstable

[Steffen Möller]

On 09/05/2011 10:13 PM, Bill Allombert wrote:
 Le samedi 03 septembre 2011 à 11:54 +0200, Bill Allombert a écrit : 
 Today circular dependencies in unstable reached an all-time low, with
 only 40 circular dependencies.

 I think it should now be clear that there aren’t any such issues that
 cannot be fixed, with more or less complication.

 Given the benefits for dependency resolvers to be able to guarantee the
 dependency tree is actually a tree and not a DAG, isn’t it time to start
 mandating this in the policy? I also wonder whether it would be possible
 to check for these circular dependencies in britney (if it’s relevant).
 
 As a start, what I suggest is to handle circular depends the same way as 
 Pre-Depends:
 
  You should not specify a `Pre-Depends' entry for a package before this
  has been discussed on the `debian-devel' mailing list and a consensus
  about doing that has been reached.
 
 i.e to require a consensus on debian-devel.

We are so large now with so many packages that I would prefer to reduce the
number of opportunities to be involved in any decision making over other
peoples' packages. Just sum up all the time that is wasted alone by deleting
the email by its subject line.

Your effort works fine, from what I observe. Good agreements on
the list. People do things. You are down to mostly peripheral packages that
seem mostly non-trivial and hence are not immediately fixed.

Sounds all very nice to me.

Steffen


-- 
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/4e654791.5040...@gmx.de

Are we monitoring disk space per package over time anywhere?

[Steffen Möller]

Hello,

with more people using Debian on phones and SSDs, the size
of packages keeps being an issue. And some claim that there
would not be much difference of current distros to all the
overhead that Redmond brings.

Are we monitoring any sudden in- or decrease in disk
space per package or per tasksel anywhere already?

Many thanks and regards

Steffen


-- 
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/4e61f7ec.2060...@gmx.de

Other OpenCL users anywhere?

[Steffen Möller]

Hello,

it seems like OpenCL is becoming routine.  The  -dev files are luckily
shared between many architectures from what I understood, just the
libraries/drivers are platform specific. The NVidia maintainers have
http://packages.debian.org/sid/nvidia-opencl-icd
in our distribution. For AMD/ATI, there is
http://wiki.debian.org/ATIStream
giving some direction. For those having no such card, it seems
worthwhile to check out
http://software.intel.com/en-us/articles/opencl-sdk/
which works with the CPU.

What we'd now possibly need are some libopencl and libopencl-dev
metapackages. This would then allow to specify at least the build
dependencies for those packages depending on those. No idea if this also
works for the binaries. Is anybody working on anything like it? Should I
otherwise come up with something? My immediate aim is a proper Debian
package for
http://cran.r-project.org/web/packages/OpenCL/index.html

Many thanks and regards,

Steffen


-- 
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/4e5ccf2f.8090...@gmx.de

Re: Providing official virtualisation images of Debian

[Steffen Möller]

Hello,

On 07/26/2011 11:08 AM, Stefano Zacchiroli wrote:
 On Tue, Jul 26, 2011 at 12:27:09AM +0200, Moritz Mühlenhoff wrote:
 I believe it's high time we start to providing Debian in form of official
 virtualisation images
 Yes, absolutely. These days having virtual images is yet another way of
 distributing an operating system and I think we should do that.

 What virtualisation solutions should be supported?
 As a general principle we should at least have all images needed to run
 virtualisation technologies which we do have in the archive.

 Additionally, I think we should also consider getting contacts with
 cloud providers (e.g. Amazon, as mentioned in this thread) and have
 them offer Debian images provided by us.
Amazon has granted me an AWS voucher for Debian Med associated bits.
I happily store instances that you want me to store.

  Some of those provider already
 offer, possibly via third parties, Debian virtualization images. It
 would be much better if they can offer the official ones provided by
 us. For this we need contacts though, possibly of people who are
 Debian/FOSS friendly within the companies.  Of course we should strive
 for not singling out any single company, hence the way it could work is
 to have a page listing providers offering official Debian virtualisation
 images + offering a contact point that providers could mail to get
 listed. In that respect, it could work very much like
 http://www.debian.org/distrib/pre-installed.
I agree with everything you are saying.
 How should the images be generated? IMO the images would need to be
 created by a DD and to provide at least some form of trust path
 validation we could provide PGP signed hashes of the download images.
 No matter what internal process we decide to have for generating the
 images, we should advertise them as official images rather than
 distributing them under some sort of personal URL.
There are instructions on http://wiki.debian.org/Cloud on how to set
images up from various authors but of course some considerable
contribution by the past two
GSoC projects we had on this. Time is floating, feel free to improve on
them.

Best regards,

Steffen


-- 
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/4e3aab9a.50...@gmx.de

Re: Providing official virtualisation images of Debian

[Steffen Möller]

On 07/26/2011 09:53 AM, Olivier Bonvalet wrote:
 Le 26/07/2011 09:28, Lucas Nussbaum a écrit :
 On 26/07/11 at 00:27 +0200, Moritz Mühlenhoff wrote:
 Hi,
 I believe it's high time we start to providing Debian in form of
 official
 virtualisation images. In contrast to the ISOs currently provided it
 allows a quicker evaluation/testing of Debian (and can also be very
 useful for testing (e.g. someone wrote on debian-release that he
 doesn't have
 access to oldstable/stable systems, with prepared virtualisation
 images that would no longer be an issue). For many setups this could
 even
 replace the installer since software selection and hostname can easily
 be tweaked post-install.

 I think it's sufficient for starters to provide images for stable
 (they can be updated for every few point updates if needed).

 What virtualisation solutions should be supported?
 - Virtual Box seems like a natural candidate since it's free and
included since Squeeze.
 - Vmware has a significant installed base and is relevant, although
proprietary
 - Microsoft Virtual PC is likely also needed
 - Qemu
 - Citrix XenServer?

 - images for cloud infrastructures (AMI -- Amazon Machine Image)

 +1

 I would love to have an official Debian Image for Amazon and other
 cloud infrastructures.
Please allow to bring
http://alestic.com/
with a series of fine images to your awareness. Those folks are not
beaten too
easily, and should rather be joined in some way.

The cloudbiolinux.org community is also preparing Debian-based images.
Everyone
out there in the cloud not using Azure likes Debian and/or its
derivatives. Rather than
having their effort duplicated, I would aim at embracing them and find a
niche for the
with or next to us.

That all said - we should be (and are) experimenting with those technologies
and come up with bits that those downstreamers might not have yet
thought of.
There is for instance Rudy at the very moment exploiting cross-architecture
virtualisation for the cloud with Eucalyptus as his Google Summer of
Code project.

Steffen




-- 
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/4e2ef238.8080...@gmx.de

How to change the world, was: Re: Bits from the Release Team - Kicking off Wheezy

[Steffen Möller]

Hello,

Marc laid that wonderful bait in this thread to which then Stefano
bite, and then the thread ended after some clarification by Marc
where IMHO there was no clarification needed [not shown].

On 04/30/2011 12:28 PM, Stefano Zacchiroli wrote:

On Sat, Apr 30, 2011 at 11:28:17AM +0200, Marc 'HE' Brockschmidt wrote:

In the last years, Debian hasn't been able to contribute any important
feature to the F/OSS distribution world - change (leading to both good
or bad results) happens at other places (namely Ubuntu) at the moment.
I believe this has a simple, technical reason - Debian has become too
big. Every change requires a massive amount of work on thousands of
packages, interaction with hundreds of (sometimes absent) volunteers and
is thus increasingly costly. This high cost makes experiments
impossible, because backing out of a change is a waste of the scare
resources of the Debian project.


No, no, and ... uhm ... no :-)
(although we're getting a bit off-topic here, I'll bite)

I agree with your analysis above, but exactly because I agree with it, I
argue that you cannot single out big as the main cause. To disprove
that as the main cause, it would be enough to notice that some of our
derivatives are, by definition, as big as Debian is, but still can make
significant changes on top of what we offer them.

So the overall issue is rather the interaction among the size and the
processes that govern that huge package repository monster that we
are. As an example, consider a maintainer willing to devote her time in
making a change that touches 300 packages. Let's assume that the change
is consensual. To deploy the change in Debian either you are lucky and:
1) all the packages are in the same VCS and 2) you've commit write
access to it (in which case you've very little procedural obstacles in
your way). Or rather you need to ping maintainers, chase the sometimes
absent people, do NMUs, etc. And that is the easy case where the change
is consensual!

Size is just one ingredient. There are plenty of other ways to diminish
barrier to deploy big changes in Debian: wider commit access rights,
larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly,
several Debian derivatives have decide to pursue those other ways and
one might argue that they have done so learning from Debian experience.)

Of course each such change will have consequences elsewhere, but please
don't assume that size is the only problem. I've the impression that
will simply stop our creativity in improving our processes.


Debian is perfectly good at holding the status quo - it's a
well-integrated, stable, mostly state of the art distribution suited for
almost anything you can come up with. Trying to repaint one of the
existing bikesheds with your new rolling color will not attract the
developers (nor users) interested in making it a hip place again.


And how do you know that?

In fact, I'm even happy to see becoming manifest the various
disagreement and different expectations we have around testing: on such
vague aspects it's hard to have upfront agreements.  But both you and
Raphael are taking guesses on the number of users / developers / effects
of a thing which does not exist yet. At this point, it can only be
speculation. You might disagree how much as you please, but there is
only one way to know who is right: build the thing.

As long as that does not step on others toes and as long as there are
volunteers willing to put their energy into a new experiment, that's
just fine.  Big changes after all also need people willing to go ahead
against some odds and show they were right --- or alternatively fail
miserably.


I very much agree to what was said above - from both sides. What I would like
to add is that Debian's most amazing resource is our community. We have
an enormous outreach into many many disciplines in Engineering and Science
and academia and industry. That Open Source has achieved that, and is
getting steadily better in getting that outreach, is truly amazing. Yes,
it is increasingly difficult to manage out packages. And I have good
confidence that we will find the energy to get those changes established that
are required to get this done. We are doing so already:
 * the Debian PPAs are such a means, basically separating core and periphery of 
Debian
 * rolling.d.n is up for such
 * snapshots.d.o is of tremendous value, very much underrated by many
 * backports.d.o
 * community maintainerships in our blends
 * ...?

The community will become increasingly important to get their production
tools into our distribution (or into some PPA). This will especially change
our Java world more, from what I observe. When they do, this seems likely to
have a very positive impact especially on developing countries. If it does,
then we have changed the world more than with the invention of some special
technology for ourselves.

From a more technical point of view I am thrilled about the surprises and
conflicts that we will run into 

Re: time based freezes

[Steffen Möller]

Hello,

On 04/03/2011 06:15 PM, Stefano Zacchiroli wrote:
 On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
   
 Time based freezes
 --
 
I very much agree that with an increasing complexity
of our distribution that goes together with an increasing
heterogeneity of tools and teams, there will always be
some waiting for something to get fixed/improved. A
particular time to freeze, if one does not freeze too often,
seems like a very good idea, then.

The time-based freeze should be decided together (if
possible) with accepting a constantly usable testing [1].
This way, the release team and the commnity may have
some better understanding what exactly it is freezing.

 Road maps
 -
   
To me, it would be interesting to have releases to be
associated with particular new features that are not too
likely to be backported. When there is no such unique
feature, one should not freeze but just continue updating
CUT and help backports where appropriate.

We should all be waiting for those new features to become
functional and stable in Debian, not for the release team
to make a particular decision - even though this effectively
may be the very same thing.

 Freezing what?
 --
   

When backports are integrated very closely with the
main distribution, the question what or when to freeze is not
really a question any more, I tend to think.

We do have quite a number of packages, especially in the
scientific world, for which the versioning is very important.
Different users, or even different projects for the same user,
may require different versions. To have snapshot.debian.org
and backports, together with good support for chroots and
virtualisation, which we have, shall be considered more
important for many than the question when and what to freeze.

Many greetings

Steffen

[1]   http://cut.debian.net/


-- 
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/4d9988af.9020...@gmx.de

[RFH] BOINC fails to compile on kfreebsd-i386

[Steffen Möller]

Dear kfreebsd users,

amd64 is fine, but i386 does not build the BOINC package. The only other
platofrm making difficulties is hurd, but this is something very
different and will most likely be already fixed with the next upload.

On kfreebsd
https://buildd.debian.org/build.cgi?pkg=boinc;ver=6.12.18%2Bdfsg-1
there is something wrong with the Makefile that is generated on that
platform.

make[1]: Entering directory 
`/build/buildd-boinc_6.12.18+dfsg-1-kfreebsd-i386-gQNKMv/boinc-6.12.18+dfsg'
docbook2x-man debian/manpages/update-boinc-applinks.xml

*
 Making 
*

/usr/bin/make
make[2]: Entering directory 
`/build/buildd-boinc_6.12.18+dfsg-1-kfreebsd-i386-gQNKMv/boinc-6.12.18+dfsg'
Makefile:189: *** missing separator.  Stop.
make[2]: Leaving directory 
`/build/buildd-boinc_6.12.18+dfsg-1-kfreebsd-i386-gQNKMv/boinc-6.12.18+dfsg'
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory 
`/build/buildd-boinc_6.12.18+dfsg-1-kfreebsd-i386-gQNKMv/boinc-6.12.18+dfsg'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


This problem is preventing the migration to testing. Any suggestion
would be much
appreciated.

Many thanks and best regards,

Steffen


-- 
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/4d8b159e.1000...@gmx.de

Re: [poll] Ubuntu column on DDPO visible by default?

[Steffen Möller]

 On 08/26/2010 11:20 PM, Thomas Weber wrote:
 On Thu, Aug 26, 2010 at 07:42:07AM +0200, Lucas Nussbaum wrote:
 I don't see what a discussion on -devel@ would bring. We are unlikely to
 come up with a better choice of solutions than what we already have
 (keep it on by default, revert the change and make it disabled by
 default).
 Maybe this is a stupid question, but what purpose does the Ubuntu column
 have at all? If I'm interested in a package in Ubuntu, that's what
 Launchpad is for. I mean, we don't have the information for the 120
 other derivatives there, either (should we ever have that, I'm not sure
 that it's just 120 clicks and then it's stored in a cookie would cut
 it, btw.).
Many of us take quite some satisfaction from seeing their packaging
work affect so many more individuals that are using that downstream
distro. They are users of our packages and as the package maintainer
one cares about them, too.

Another idea is to have more and more downstream developers
become maintainers also for Debian. And then the PTS and other bits
of our infrastructure should not let them miss too much, especially
not the bugs submitted from their own userbase.

Steffen

 


-- 
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/4c7789f5.1000...@gmx.de

Re: How to make Debian more attractive for users

[Steffen Möller]

On 07/23/2010 01:56 PM, Mike Bird wrote:
 On Fri July 23 2010 00:41:12 Neil Williams wrote:
   
 Critical bugs cannot be ignored and buggy packages cannot be left in the
 archive to trip up someone else
 
 For people who are relying on the package and are not affected by the
 critical bug, the removal of the package is itself the problem.
   
This depends on the package, the bug and on the user. It seems like
I only now start to understand the importance of snapshot.d.o .

And then, for all the important bugs that are not ours but that of
upstream, we need a good connection in that direction, too. But
the metaphoric phone number I really meant to be called only, not
to actively call.

Steffen


-- 
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/4c498810.6070...@gmx.de

Re: How to make Debian more attractive for users

[Steffen Möller]

Hello,

after reading through this long thread, I find many somewhat diverging
opinions, but not a single posting I could not at least partially agree
to. This includes Lucas with we should not include Debian money, while
I hope we could somehow have him agreeing to a separate account from
which any Debian phone number and/or friendlier face could possibly be
financed, with the community voting on what to do with profits (if any).
The problem I see with any Debian-independent solution is that we as a
community would have less of a control over it, and there is again the
problem of additional insecurity on the users' side if the number dialed
was the correct one. Maybe this analogon helps: I have one number on my
mobile called Taxi which will get me to the closest Taxi company,
wherever I happen to travel. A Debian number should ask for more than
GPS coordinates but also try to figure out what company is closest with
its spectrum of services/products,  etc. I can imagine that many
smaller companies are also afraid of doing contracts or so in a foreign
language, i.e. there is a lot to which a central contact point may
contribute.

From Cate

On 07/22/2010 11:55 AM, Giacomo A. Catenazzi wrote:
 On 22.07.2010 10:38, Andreas Tille wrote:

 On Thu, Jul 22, 2010 at 10:28:36AM +0200, Giacomo A. Catenazzi wrote:
 [..]


 So, let see how to improve Debian, not how to increase
 our userbase!

 I do not think that we succeed in improving Debian if the userbase is
 decreasing.  IMHO this would mean we are trapped in an ivory tower.  So
 both parameters quality of distribution and number of users are
 somehow connected and you can not ignore this relation.

 Yes, my point is that we should think how to improve Debian (from
 our selfish point of view: an happy hacker programs more), and
 then users will follow us.
+1 we should always do that. And we are doing so at the very moment, I
think.

 But the thread seems like: what we could steal from other distributions
Ooops, no, I definitely don't want to take users from other distros
away. When
pointers are made to others then because they may seem to do something
better
than us and this should make us think more.

I am after the many Linux users that are still isolated from us
distribution makers
for various reasons. I want to make them happier with us. This happiness
will
then shine over to other Linux distributions (sorry for that) but more
so I hope
to improve our product and get fewer people migrate to the Mac or come to us
from closed source OSes.
 to gain some market share. But I think all distribution are different
 and should try to be different, so ok to copy if we improve ourself,
 but not copying only to attract users.
We have so far mentioned the distributed-community-ness of Debian as a
disadvantage.
And it certainly is when one thinks about making deals of various sorts.
But it is
a plus when a vendor wants to feel a part of a Linux distro. How can you
feel part of
SuSE? Well, you could buy some Novell stock, but this does not get you
in. You can
contribute to OpenSuSE, but this is not SuSE, still. Hence, I think we need
a metaphoricphone number/metaphoric and the confidence of the community
that when that phone number is called that they would contacted as a member
of our community when the caller actually meant to call them but just
did not
know about their prior existance.
 IMHO the priorities are:
 1- enjoy us (thus indirectly also to be proud of our product, so
 enjoying users)
 2- quality and freedom
 3- increase GNU/Linux (and other free kernels) users
 4- increase our users
+1

 IMHO most of this thread discusses only to the last point, without
 thinking some negative effects on the other points
This thread is about the observed _decrease_ of users (ok, probably some
contribution
is just from people on vacation having switched their machine off) and
we wonder
why this happens and what we should possibly change. The phone number(s)
shall
help to weaken what separates us from them, but I am otherwise fully
with you.


Many greetings

Steffen


-- 
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/4c484332.1040...@gmx.de

Re: How to make Debian more attractive for users

[Steffen Möller]

On 07/22/2010 03:21 PM, Nicholas Bamber wrote:
 I reckon a forum would be much easier to finance (even with
 moderators) than a phone line. It could probably be integrated with
 one of the mailing lists which would go a long way to make it look
 friendlier.
+1   there are various Debian support forums already, but I agree that
to have one closer to us would be helpful.   Actually I very much like
your notion of a Moderator.  The disadvantage of a forum is that
everything is public and I could imagine that someone would like to call
or email in without that call to be reported somewhere publicly (like:
we have this IT staff, they could have told that, or uh, they use
GENtle, we should email them so they use our commercial alternative). I
still think the (team of) moderator(s) should have a phone with a
publicly known number.

Steffen


-- 
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/4c48496c.4080...@gmx.de

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Steffen Möller]

Hello,
On 07/23/2010 02:03 AM, Jesús M. Navarro wrote:
 On Thursday 22 July 2010 23:51:10 Don Armstrong wrote:
 [...]
 Testing's primary purpose is as a staging ground for the next release;
 while it'd be nice to try to keep it working as a fully installable
 version all of the time, progress to the next release is more
 important than that.
 
 And that's exactly my point while such valuable people as Russ Allbery wants 
 to challenge that notion.

Not necessarily challenge but extend it. We only get testing tested or
unstable unstabled when people are actually running those and are working
with these. And the testing should not start in testing but in unstable,
otherwise we'd not need unstable in the first place.

The paradox is that the more a package is away from essential, the fewer
accidental users it is likely to have, but this means that we need more users
to have problems with those packages identified. So, with our increase of 
packages,
we need more users to test those new uploads, i.e. more users working with
unstable.

I have not been around when unstable was designed. I do not want to
contradict that it probably was an acceptable concept to have it break
often 10 years ago. But it is not today IMVHO. And from my experience,
it does not break too often, indeed.

I very much like the idea of CUT, possibly somehow merged with snapshot.d.o.
I feel that the blends should help with their respective experiences for
some subsets of Debian. And we could think of asking popcon for the
number of eyeballs a software has seen for the package's acceptance.
I have not thought through what this might mean for the release
management or Don's implicit concerns that it may hamper the release
of the next stable version. Nothing overly obvious strikes me, though.

Steffen (from his stable unstable laptop)


-- 
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/4c48e2b2.2060...@gmx.de

Re: The number of popcon.debian.org-submissions is falling

[Steffen Möller]

On 07/21/2010 09:12 AM, Andreas Tille wrote:
 If you ask me, the decreasing number of popcons is because people are
 bored by a system with old versions of programs and are seeking for
 alternatives and we will see a further decrease until Squeeze will be
 released.  So probably the best idea to increase popcon numbers is to
 fix some RC bugs to get Squeeze in shape.
   
we could argue that those packages that have lost the most over the
last months are the ones that are most responsible for the decline
of submitters. Would be interesting to know ...

Steffen (writing from a 10.10 Ubuntu machine - Dell's fault)


-- 
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/4c46b7ce.7010...@gmx.de

How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Steffen Möller]

This should probably then move to Debian-Project?

On 07/21/2010 11:31 AM, Andreas Tille wrote:
 On Wed, Jul 21, 2010 at 05:34:27PM +0900, Charles Plessy wrote:
   

 I think that what we need is Debian Blends that include official backports.
 This, no other distribution proposes yet.
 
 IMHO this is worth another thread how to make Debian more attractive for
 users ...
   
The computing world have become such complex, that we are all mere users
somewhere. So yes, we should think more about our users.

* I know a few who love lenny with backports, so yet, we should somehow
integrate that with the blends concept. Could there be a flag in
debian/control in some way for anything with a compatible debhelper
version to be auto-backported?

* Metaphorical speaking: we should give Debian a phone number. And I
mean full-time or at least half-time employees. With so many people
unemployed these days, I even feel we have the duty to think about
creating jobs.

Best,

Steffen


-- 
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/4c46dd3b.5080...@gmx.de

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Steffen Möller]

 I wrote:
 * Metaphorical speaking: we should give Debian a phone number. And I
 mean full-time or at least half-time employees. With so many people
 unemployed these days, I even feel we have the duty to think about
 creating jobs.
 
   
On 07/21/2010 03:46 PM, Stephen Powell wrote:
 That's an interesting idea.  But where is the money going to come from?
   
On 07/21/2010 02:06 PM, Paul Wise wrote:
 That is probably part of the DPL's role? Could clarify what you are
 proposing here?
On 07/21/2010 04:30 PM, Lucas Nussbaum wrote:
 This idea is likely to get so much people against it that it's not worth 
 discussing.
   


Dear Paul, dear Stephen, dear Lucas,

I thought that we should see where the discussion about it goes. If we are
becoming serious about using Debian money to hire people, then by some
magic we'd need to find a way to circumvent the past Dunc Tank outrage.
So we would need a way to
 * keeping doing what we do now
 * do not see someone else paid for something you would want to do with
your packages

Solutions to the above that I see
 * whoever is paid should not work on packaging
 * whoever is paid shall listen and try to establish teams of
maintainers to solve issues
 * whoever is paid shall do whatever the person can to help where help
is needed
 * whoever is paid shall involve established Debian consultants as much
as possible

About where the money could come from
 * the phone number would not be free
 * donations
 * we'll see after a year if this works, so we'd need money for two
years or so and
   then see what happens
 * We could start small, maybe by collecting 3-5 students at some
university who share a single mobile, taking notes about their efforts
and a(n unpaid not in his daytime job too much disturbed) DD as their
supervisor. Such a concept might possibly scale rather nicely across
cultures and time zones, i.e. we all want to support our students
somehow. How much is that? 5000 $/€/10yuan/100yen/whatever per anno?

Is this the DPLs job? I see it more as a Dr Watson to the DPL, i.e.
someone you like
talking to with no non-technical power. I am also with Lucas, but I did
not want to
self-censor me too much. If such is not accepted in our community, then
we will
learn this very quickly :)

Steffen


-- 
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/4c470796.9080...@gmx.de

Re: xulrunner 1.9.2 into sid?

[Steffen Möller]

Hello,

On 06/27/2010 04:25 PM, Aaron Toponce wrote:
 Seeing as though upstream Firefox 3.6 released December 1, 2008, and
 upstream Thunderbird 3.1 released just a couple days ago, it might be
 high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and
 Icedove 3.1 will depend on it. However, I hear there will be lots of
 breakage if xulrunner 1.9.2 comes into Sid. If so, what will break?
 Further, what can I do to help?
   
It cannot be that bad, I am running it on my desktop with Maverick.
ii  xulrunner-1.9.2 1.9.2.4+build7+nobinonly-0u XUL + XPCOM
application runner

It is already in experimental
http://packages.debian.org/search?searchon=sourcenameskeywords=xulrunner
maybe you can just install it and report back to the maintainers?

Thanks and regards

Steffen


-- 
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/4c285f84.7030...@gmx.de

Re: lilo removal in squeeze (or, please test grub2)

[Steffen Möller]

Hello,

On 05/23/2010 03:44 PM, Julien BLACHE wrote:
 Darren Salt li...@youmustbejoking.demon.co.uk wrote:

 Hi,
   
 Working fine here on i386, whether booting a stock kernel (testing with
 2.6.33 from experimental) or a custom kernel. I've not checked a stock kernel
 on amd64 for some time now, but I've seen no problems with my custom kernels
 (which are all initrd-free).
 
 No problems to report on amd64 either, with or without an initrd.
   
this Grub thingy is something really tough to explain to migrators.
The worst is that while the boot prompt works, one loses the console
all too easily and does not get it back. And google says one should
edit files here and there to keep the gfxpayload.

Yes, I did all that. But I did not want to do that. And then I lost it
again at some later update.

Since the console is the entry to most newbies, whatever you do,
make it as easy as possible. If that is not possible, then please
leave LILO in.

Thanks

Steffen (who accepted to have lost his Console, no ALT-F1 any more)


-- 
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/4bfbb8bd.8050...@gmx.de

Bug#570109: ITP: libmath-interpolator-perl -- interpolate between lazily-evaluated points

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Möller steffen_moel...@gmx.de

* Package name: libmath-interpolator-perl
  Version : 0.0.3
  Upstream Author : Andrew Main (Zefram) zef...@fysh.org
* URL : http://search.cpan.org/dist/Math-Interpolator/
* License : GPL or Artistic
  Programming Lang: Perl
  Description : interpolate between lazily-evaluated points

 This class supports interpolation of a curve between known points, known as
 knots, with the knots being lazily evaluated. An object of this type
 represents a set of knots on a one-dimensional curve, the knots possibly not
 being predetermined. The methods implemented in this class extract knots,
 forcing evaluation as required. Subclasses implement interpolation by various
 algorithms.
 .
 This code is neutral as to numeric type. The coordinate values used in
 interpolation may be native Perl numbers, Math::BigRat objects, or possibly
 other types. Mixing types within a single interpolation is not recommended.



-- 
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/20100216144804.5113.24306.report...@toshiba.siemens

Bug#568701: ITP: libisfreetype-java -- Java wrapper for FreeType font handling library

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Möller steffen_moel...@gmx.de

* Package name: libisfreetype-java
  Version : 5.2
* URL : 
http://opensource.intarsys.de/home/en/index.php?n=IsFreeType.Download
* License : custom free
  Programming Lang: Java
  Description : Java wrapper for FreeType font handling library

 The PDF rendering of the Open Source efforts of the company intarsys
 was in demand of a good font handling library. This new development was
 motivated by observations that current solutions
  * only have poor support for VM
  * there is no plain Java library around
  * extends the de factor standard C library FreeType
 This library wraps around the functions that were important for
 using isNativeC (another library of the same company) and were ready
 to run on all FreeType supported platforms.
 .
 While this wrapper-library binds and uses only a very small subset
 of the FreeType features available, to the degree that it is needed
 for the jPodRenderer, it should be no problem to use and enhance
 this implementation in other contexts.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#568598: ITP: librt-java -- runtime routines for projects of intarsys

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Möller steffen_moel...@gmx.de

* Package name: librt-java
  Version : 4.7
* URL : 
http://opensource.intarsys.de/home/en/index.php?n=JPodRenderer.DevelopersGuide
* License : GPL-3+
  Programming Lang: Java
  Description : runtime routines for projects of intarsys

The isrt.jar, also isRuntime, the basic runtime library used within all 
intarsys projects.
The latter are contributing to the handling of PDFs and a dependency of later 
versions of PDFsam.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#566014: ITP: nordugrid-arc -- middleware for shared storage and computation

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Möller steffen_moel...@gmx.de

* Package name: nordugrid-arc
  Version : 0.8.1
* URL : http://www.nordugrid.org/
* License : Apache
  Programming Lang: C++
  Description : middleware for shared storage and computation

 The NorduGrid is a computational grid, with a diverse set of
 communities with research emphasis e.g. on high-energy physics,
 astronomy and bioinformatics. It is open to both academic and
 commercial groups on a tit-for-tat basis to share skills, compute
 time and storage.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#565748: ITP: libisnativec-java -- helper routines to access native code from Java

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Möller steffen_moel...@gmx.de

* Package name: libisnativec-java
  Version : 5.2
* URL : 
http://opensource.intarsys.de/home/en/index.php?n=OpenSource.IsCWT
* License : BSD-like
  Programming Lang: Java
  Description : helper routines to access native code from Java

 A solution completely written in Java to access native code.
 Features:
  * Java side declaration, no C compiler
  * Clean design
  * Transparent, easy deployment
  * Platform independent
  * Fast
 The effort relies on a combination of upstream's custom design for
 the call interface, memory abstraction and data structures and the
 basic native binding provided by any third party (currently jna).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#565670: ITP: libjpedal-jbig2-java -- library for accessing large images

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Möller steffen_moel...@gmx.de

* Package name: libjpedal-jbig2-java
* URL : http://www.jpedal.org/support_JBIG.php
* License : LGPL
  Programming Lang: Java
  Description : library for accessing large images

The JPedal JBIG2 Image Decoder is a 100% pure Java image decoder for
the JBIG2 file format. The decoder takes the JBIG2 image processing
technology developed for the JPedal PDF renderer and makes it available
as a generic library for more general usage.

It offers the ability to allow developers to add JBIG2 image rendering
capabilities to their own applications, through a simple and easy to
use API. In its simplest form it allows developers to load in a JBIG2
encoded datastream and convert that into a BufferedImage.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#565695: ITP: libiscwt-java -- abstraction and implementations for rendering PDF

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Möller steffen_moel...@gmx.de

* Package name: libiscwt-java
  Version : 5.2
* URL : 
http://opensource.intarsys.de/home/en/index.php?n=IsCWT.HomePage
* License : BSD
  Programming Lang: Java
  Description : abstraction and implementations for rendering PDF

 To built a flexible PDF rendering one first needed some basics
 functionality to deal with fonts, images and general platform
 abstractions. The result is isCWT. It contains all abstraction and
 implementations needed for rendering PDF that are not related to PDF
 itself.  This library is built and used primarily for jPod Renderer,
 so one is likely to miss some features when using it in another context.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools

[Steffen Möller]

Charles Plessy schrieb:
 Le Tue, Oct 28, 2008 at 09:32:42AM +0200, Teodor a écrit :
   
 I still believe it is best to rename 'plink' to 'puttylink' in
 putty-tools binary package. Anyway, this should be fixed for squeeze
 since in lenny there is no conflict (plink is not included in lenny).
 

 Hi all,

 Upstream documented the renaming on his website, so I think that that is the
 (happy) end of the story :)

   Debian users: PLINK is available as a Debian package, see these notes. 
 Note, the
   executable is named snplink in the Debian plink package.

 http://pngu.mgh.harvard.edu/~purcell/plink/download.shtml
   
To me, the renaming to snplink is an exceptionally unfortunate way to
address the name-conflict we experienced. This way, we render Debian
incompatible with scripts distributed in the community and incompatible
with computational grids, too. I am just writing from a grid conference
and plink was indeed referenced on one slide. I don't want either plink
to be renamed, completely following the points brought up Brian and
definitely prefer a conflict between the two plink packages. Those users
who _really_ need both and _really_ need to work with Debian packages
only, they can have a chroot environment for the bioinformatics-plink.
Besides: there is a SNPLINK already:
http://bioinformatics.oxfordjournals.org/cgi/content/full/21/13/3060

The executable in either package should not be renamed. I don't see a
reasonable way around it. The only problem that I originally understood
from skimming over the thread was that Debian packages would be named
equally and I was too busy to wonder for too long how this could be
allowed by the Debian infrastructure. But embarrassingly, after checking
things manually, I just spotted that putty's plink is not coming as a
package with that name but that it is wrapped up to the package
putty-tools. This is just fine to me. I'll add a Conflicts:
putty-tools to the plink control file, upload plink's new version 1.04
and we are set.

To summarise things up: the renaming of the executable of plink to
snplink renders the plink package inferior to a manual installation of
plink under the proper name. What I'll do now unless I hear some
objections that I am mentally prepared to follow: I'll prepare the new
version, add the conflict to debian/control to close 503367 (won't fix)
and herewith truly apologize for all these emails.

Best,

Steffen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools

[Steffen Möller]

Hello,

Teodor schrieb:
 On Tue, Oct 28, 2008 at 12:54 PM, Steffen Möller [EMAIL PROTECTED] wrote:
   
 Charles Plessy schrieb:
 
 Le Tue, Oct 28, 2008 at 09:32:42AM +0200, Teodor a écrit :
   
 I still believe it is best to rename 'plink' to 'puttylink' in
 putty-tools binary package. Anyway, this should be fixed for squeeze
 since in lenny there is no conflict (plink is not included in lenny).
 

 That was based on the assumption that the project name is well
 established (plink).  I had no idea and I couldn't find on the project
 site what 'p' stands for. A more appropriate and suggestive name for
 the project is this one given by upstream: snplink.
 I have a feeling that upstream will change the project name from plink
 to something more appropriate (like snplink) to avoid the confusion.

   
 Upstream documented the renaming on his website, so I think that that is the
 (happy) end of the story :)
   

 Yes, it is. :)
   
Except that snplink is taken by another program and Debian remains
incompatible for scripts shared in the community. Even if we find
another name, then it seems likely that another later program would have
that name, just having been checked against the real project names. The
iceweasel-icedove solution has the same problem, in principle.
 ...(won't fix)...
 That would be serious bug against 'plink' according to Debian policy.
 Read the whole thread starting at [1] or this specific message [2].


 [1]  http://lists.debian.org/debian-devel/2008/10/msg00633.html
 [2]  http://lists.debian.org/debian-devel/2008/10/msg00644.html
   
I need to thank all your friendly, constructive and informative replies.
As stated before I agree that that putty-tools's plink should not be
renamed (for the same reasons as plink's plink should not be renamed),
and I have now reread and understood what the policy says and following
these lines I share your conclusion that it should be plink's plink that
should be renamed. However, I still think that albeit adhering to the
Debian policy, the decision is inpractical and hence wrong. I personally
see four alternatives:
 a) removing the newly package plink from the archive
 b) add an exception to Debian policy for the case that the two packages
in name-conflict are not in the base distribution and the two
maintainers agree that the conflict in names does not matter enough to
be concerned
 c) add an exception to Debian policy when the two packages are of
different priorities and both are out of base, having optional beating
extra and the two maintainers agree.
 d) have the binary install below /usr/lib rather than /usr/bin and
there is some mechanism to set the path right, which should be executed
prior to the execution of any script that is executing plink.

I personally am happy with any of the four alternatives but obviously
would best like b) or c). With an increasing number of applications in
Debian I am certain that b) or c) will be needed sooner or later, but d)
may be another interesting option for many. What do you think?

Cheers,

Steffen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools

[Steffen Möller]

Hello,

plink has just made it to the archive.

Teodor happened to have nicely explained my objections to rename plink.

Dear Colin, if you don't mind too much, or if you could be bribed with a
few beers, please be so kind to rename the plink binary package.

Many thanks and best regards,

Steffen (who should have checked and asked prior to his upload)

Teodor schrieb:
 On Sat, Oct 25, 2008 at 12:24 PM, Charles Plessy [EMAIL PROTECTED] wrote:
   
 Both programs are intended for command line, and could be used in
 scripts. We may even find users who want to install both at the same
 time. Very annoying…

 Since Plink is younger than Putty, I think that the burden of the
 renaming is for us (the Debian Med packaging team). I plan to rename
 /usr/bin/plink to /usr/bin/Plink, that would be a symbolic link to
 /usr/lib/plink/plink so that with an appropriate PATH, users can rescue
 their scripts.
 

 Since renaming seems to be the only solution, than IMO it is more
 appropriate to rename 'plink' in putty-tools than in the plink
 packages since this is exactly the source/binary package name. This
 has been done already in putty-tools for the 'puttygen' binary.

 Thanks


 
 piti:~# dpkg -L putty-tools
 [snip]
 /usr/bin/pscp
 /usr/bin/psftp
 /usr/bin/plink
 /usr/bin/puttygen
   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]