Re: Running pybuild tests with search path for entry_points()

[Sebastiaan Couwenberg]

On 5/11/24 8:47 PM, John Paul Adrian Glaubitz wrote:

export PYTHONPATH = $(CURDIR)


Try setting it to the build_dir path:

 PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3)

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Package marked for autoremoval due to closed bug? [and 1 more messages]

[Sebastiaan Couwenberg]

On 3/21/24 11:47 AM, Ian Jackson wrote:

Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug? [and 1 
more messages]"):

Steve, could you please do this for *all* the time_t transition RC
bugs?


IMO things are currently ON FIRE.


Exaggeration is an art.


If no-one else has put this fire out by 24h from now, I will attempt
to find which are the relevant bugs and downgrade them all.


The time-t usertag of debian-...@lists.debian.org is your friend.

I've downgraded all the closed "NMU diff for 64-bit time_t transition" 
bugreports with serious severity to important and usertagged them as 
requested by elbrus.


There are still 19 serious "NMU diff for 64-bit time_t transition" 
bugreports that aren't closed, 60 serious bugreports that aren't "NMU 
diff for 64-bit time_t transition" ones, and 21 serious bugreports that 
are pending upload. I'll leave dealing with these bugreports to someone 
else.


I personally wouldn't mind seeing armel & armhf in the britney 
OUTOFSYNC_ARCHES to unblock testing migration for the 64 bit 
architectures until they've caught up, but this may be a bit of a dick 
move towards the ARM porters.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Linker fails to find libraries in unstable but succeeds in testing

[Sebastiaan Couwenberg]

On 3/15/24 7:31 AM, Andreas Tille wrote:

g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o 
bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR


It likely works by adding the library path, e.g.:

 g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so 
RcppExports.o bindings.o -L/usr/lib/x86_64-linux-gnu -lv8 
-lv8_libplatform -L/usr/lib/R/lib -lR


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Confusion over t64 migration

[Sebastiaan Couwenberg]

On 2/10/24 13:40, Holger Levsen wrote:

On Sat, Feb 10, 2024 at 12:16:48PM +, Holger Levsen wrote:

I'm also of the opinion that *someone* should do this for all these bugs
but I am too lazy to do it myself.


sebas...@debian.org has thankfully done this, 15min before I wrote the above.


Note that the severity was only downgraded for the "NMU diff for 64-bit 
time_t transition" bugreports, there are still a few serious ones left:



https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=time-t#_0_2_2

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=time-t#_0_2_4

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: lintian.debian.org off ?

[Sebastiaan Couwenberg]

On 9/26/23 16:56, Daniel Gröber wrote:

The old web service had explainations and additional context for the
various lintian tags. UDD doesn't seem to offer that so where can we find
this information now?

lintian-explain-tags(1) is your friend:


https://manpages.debian.org/unstable/lintian/lintian-explain-tags.1.en.html

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Potential MBF: packages failing to build twice in a row

[Sebastiaan Couwenberg]

How would one implement this in the common Salsa CI pipeline?

There is an old issue for this [0], but unless someone provides an MR 
its unlikely to get implemented.


Occasional rebuild campaigns like this don't catch regression in a 
timely manner. Having a build-twice job in the Salsa CI pipeline would 
help to catch regressions quickly, but it doesn't cover all packages. 
Better would be a QA service for all uploads to the archive similar to 
reproducible builds or piuparts to ensure non-policy compliant clean 
targets are caught quickly.


[0] https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/193

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Behavior change for Python packages built with CMake

[Sebastiaan Couwenberg]

On 7/27/23 15:24, Simon McVittie wrote:

On Thu, 27 Jul 2023 at 13:49:33 +0200, Timo Röhling wrote:

recently there have been two independent changes in the Python and
CMake world which conspired to FTBFS a number of packages.

TL;DR: export DEB_PYTHON_INSTALL_LAYOUT=deb_system in d/rules


Is "deb_system" and not "deb" the canonical thing to use here? The GNOME
team has been using "DEB_PYTHON_INSTALL_LAYOUT = deb" to work around
the corresponding issue with Meson-built packages.


It's effectively the same:

 # default to /usr for package builds, /usr/local otherwise
 deb_build = os.environ.get('DEB_PYTHON_INSTALL_LAYOUT', 'posix_local')
 if deb_build in ('deb', 'deb_system'):
 prefix_scheme = 'deb_system'
 else:
 prefix_scheme = 'posix_local'


https://sources.debian.org/src/python3.11/3.11.4-1/Lib/sysconfig.py/?hl=322#L322

The deb_system is suggested for package builds:

  * sysconfig: The 'posix_local' schema name is the default unless the
env var DEB_PYTHON_INSTALL_LAYOUT is set to 'deb' or 'deb_system'.
Use the latter for package buillds.


https://sources.debian.org/src/python3.11/3.11.4-1/debian/changelog/?hl=1056#L1056

The changelog entry is the only documentation I've found for 
DEB_PYTHON_INSTALL_LAYOUT.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Replaces without Breaks or Conflicts harmful? [was: Re: Policy consensus on transition when removing initscripts.]

[Sebastiaan Couwenberg]

On 6/29/23 12:32, Helmut Grohne wrote:

On Thu, Jun 29, 2023 at 08:19:51AM +0200, Sebastiaan Couwenberg wrote:

On 6/28/23 21:49, Helmut Grohne wrote:

Debian GIS Project 
 postgis
 qgis


Why is postgis on this list?

  $ grep -c Replaces debian/control*
  debian/control:0
  debian/control.in:0


Thanks for asking. You identified another source of false positives that
slipped my mind when doing the analysis. The underlying data source did
not use unstable, but every suite from bullseye to experimental
including -security and -backports. As it happens, bookworm's
postgresql-15-postgis-3-scripts has versioned Replaces that are not
matched with Breaks or Conflicts. I don't think we are going to fix that
in bookworm and you've fixed it in unstable. So yeah, this list has more
false positives than originally assumed.


Thanks for clarifying your data sources.

FWIW, qgis is fixed in git.


I could improve the numbers, but to me the numbers I've given being a
tight upper bound seems good enough and lintian.debian.org will give us
precise and current numbers once my patch is merged. Does that seem
sensible to you as well?


If you intend to file bugs you should only look at unstable & experimental.

For the sake of argument your list is fine.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Replaces without Breaks or Conflicts harmful? [was: Re: Policy consensus on transition when removing initscripts.]

[Sebastiaan Couwenberg]

On 6/28/23 21:49, Helmut Grohne wrote:

Debian GIS Project 
postgis
qgis


Why is postgis on this list?

 $ grep -c Replaces debian/control*
 debian/control:0
 debian/control.in:0

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: SONAME bumps (transitions) always via experimental

[Sebastiaan Couwenberg]

On 1/5/23 14:13, Simon McVittie wrote:

2. If there is already a version in experimental that is unsuitable for
the next stable release, because there's only one experimental, in the
rare case that upstream bumps the SONAME of the "old" branch, we can't
do as asked. For example:

- libfoo_1.0-1 (libfoo-1.so.0) is in testing/unstable
- libfoo_2.0-1 (libfoo-2.so.0) is in experimental but not yet ready
- maintainer wants to get libfoo 1.5 (libfoo-1.so.1) into testing/unstable

This seems unlikely to happen often, because upstreams usually focus
development of intrusive changes that can break ABI onto one branch at
a time. Presumably if a maintainer finds that they need this, the ftp
team would read a justification in debian/changelog and relax this rule?

If bikesheds ever become available, then they would solve all instances
of the "only one experimental" problem, including this one.


When I've needed experimental for an older version I filed an RM 
bugreport for the package in experimental. Being blocked by two 
ftp-master actions is not ideal, but it works.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: SONAME bumps (transitions) always via experimental

[Sebastiaan Couwenberg]

On 1/5/23 12:26, Paul Gevers wrote:
Are there objections against this workflow? (Or voices from people who 


This has been a best practice for quite a while, high time to make it 
hard requirement.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: dh_auto_test fails and I do not understand why

[Sebastiaan Couwenberg]

On 12/15/22 10:34, Andrius Merkys wrote:
However, I have no idea why '-o 0 -g 0' options are used. They do not 
seem to be used before.


Recent changes in debhelper, see:


https://salsa.debian.org/debian/debhelper/-/commit/ca66cf4bc74fe31b3d5c8131788e7fdd8731

https://salsa.debian.org/debian/debhelper/-/commit/e41b7d15c4b005def732cb9f82ed14171499689d

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Debhelper issue on various architectures

[Sebastiaan Couwenberg]

On 11/21/22 17:56, Peter Wienemann wrote:

Any hints pointing towards the underlying issue are appreciated.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024520

Retrying the build by giving back the package fixes the issue.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Transition: pkg-config to pkgconf: next steps

[Sebastiaan Couwenberg]

On 10/20/22 12:25, Andrej Shadura wrote:

The version of pkgconf package providing the pkg-config binary package has been 
sitting in experimental for some time. I think I have tested the upgrade 
process quite extensively, but it would still be great if someone else could 
have a look. In any case, my plan is to upload it to unstable in about two 
weeks time. I will then commence another round of rebuilds; meanwhile I will be 
working on fixing issues I’ve already run into:


I cannot reproduce the issue with icinga2, it built successfully on my 
system with pkg-config (>= 1.8.0) from experimental.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Transition: pkg-config to pkgconf: next steps

[Sebastiaan Couwenberg]

On 10/20/22 12:25, Andrej Shadura wrote:

I’ve been rebuilding packages with pkgconf for the past couple of weeks, and it 
looks very good so far:

http://pkgconf-migration.debian.net/


The "Failures only" page is empty.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: FTBS bugs -- MBF?

[Sebastiaan Couwenberg]

On 10/2/22 04:23, Adam Borowski wrote:

This leaves one big set: packages that fail the clean step due to
undeclared B-Depends.  According to the Policy:

# "clean"
#Only the "Build-Depends" and "Build-Conflicts" fields must be
#satisfied when this target is invoked.

... which makes sense as you might be interested in only an arch:all or
arch:any build, and we have no clean-indep/clean-arch targets.


Shouldn't Build-Depends-Indep be considered as part of Build-Depends?

Packages that only build Architecture: all binary packages tend to use 
Build-Depends-Indep.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: libgeos++-dev intentionally broken

[Sebastiaan Couwenberg]

On 9/12/22 14:01, Enrico Zini wrote:

The Debian libgeos++-dev package has intentionally stopped[2] shipping
some include files that are needed to build programs with the C++ API,
stating:


Upstream removed the .inl files in 3.11.0:

 https://github.com/libgeos/geos/blob/3.11.0/NEWS.md?plain=1#L22

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Is there a mip64el machine available for debugging?

[Sebastiaan Couwenberg]

On 8/22/22 07:15, Steve Robbins wrote:

Oh. I did use Eller -- but the architecture is listed as mipsel.  I need 
mips64el


eller has mips64el chroots too, just like there are i386 chroots on the 
amd64 porterbox:


 sebastic@eller:~$ schroot -l | grep mips64el
 chroot:bookworm-backports_mips64el-dchroot
 chroot:bookworm_mips64el-dchroot
 chroot:bullseye-backports_mips64el-dchroot
 chroot:bullseye_mips64el-dchroot
 chroot:buster-backports_mips64el-dchroot
 chroot:buster_mips64el-dchroot
 chroot:experimental_mips64el-dchroot
 chroot:sid_mips64el-dchroot
 source:bookworm-backports_mips64el-dchroot
 source:bookworm_mips64el-dchroot
 source:bullseye-backports_mips64el-dchroot
 source:bullseye_mips64el-dchroot
 source:buster-backports_mips64el-dchroot
 source:buster_mips64el-dchroot
 source:experimental_mips64el-dchroot
 source:sid_mips64el-dchroot

https://dsa.debian.org/doc/schroot/

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Is there a mip64el machine available for debugging?

[Sebastiaan Couwenberg]

On 8/22/22 05:36, Steven Robbins wrote:

The list at https://db.debian.org/machines.cgi suggests all available machines
are "buildd" and restricted.


eller.debian.org is the mipsel/mips64el porterbox.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: access forbiden salsa.debian.org

[Sebastiaan Couwenberg]

On 3/1/22 12:48, a a wrote:

Today a tried to access contents of debian instaler git repository on
salsa.debian.org and the server responded with 403 error. Next i tried
other content located on said server with the same resposne. Was there a
change in access policy or something is wrong with the server itself.


See: 
https://lists.debian.org/debian-infrastructure-announce/2022/02/msg0.html


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: No mips64el porterbox?

[Sebastiaan Couwenberg]

On 3/1/22 10:54, Julien Puydt wrote:

Le mardi 01 mars 2022 à 10:34 +0100, Sebastiaan Couwenberg a écrit :

On 3/1/22 10:28, Julien Puydt wrote:

Is there really no mips64el porterbox, or is it only a transitory
situation?


eller.debian.org has mips64el chroots.



How do I use one of those and not a mipsel one? I'm using
https://dsa.debian.org/doc/schroot/ as usual, and it looks like I'm
getting a mipsel and not mips64el...


Specify the mips64el chroot when creating it:

 schroot -b -c sid_mips64el-dchroot -n $sessionid

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: No mips64el porterbox?

[Sebastiaan Couwenberg]

On 3/1/22 10:28, Julien Puydt wrote:

Is there really no mips64el porterbox, or is it only a transitory
situation?


eller.debian.org has mips64el chroots.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Unplanned freeze?

[Sebastiaan Couwenberg]

On 1/28/22 07:53, Ole Streicher wrote:

Hi,

I just observed that many of my packages that are currently in unstable
are not migrating because of

| Not touching package due to block request by elbrus (Follow the freeze
| policy when applying for an unblock)

where the "freeze policy" is linked to the bookworm Freeze Timeline (?).

f.e. https://tracker.debian.org/pkg/photutils

However, I couldn't find an announcement of a freeze in d.d.a. What is
the cause of this?


Cause is binutils bug #1004272.

From https://release.debian.org/britney/hints/elbrus:

 # 20220125
 # 1004272
 block-all source

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Lintian status reporting on packages overview broken?

[Sebastiaan Couwenberg]

On 6/18/20 10:15 AM, mer...@debian.org wrote:
> In addition to that, "Watch" column displays dashes ("-") only.

That's due to #932296

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Problems while searching for a new upstream version

[Sebastiaan Couwenberg]

On 4/8/20 8:54 AM, Mechtilde Stehmann wrote:
> How can I solve it?

Run uscan on your own system to check for new upstream releases.

This is a known issue due to the high number of packages that are
checked by the QA servers, see: #955268.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Re: trends.debian.net updated

[Sebastiaan Couwenberg]

On 4/4/20 9:28 AM, Lucas Nussbaum wrote:
> On 04/04/20 at 08:09 +0200, Paul Gevers wrote:
>>> I keep wondering if we should make an effort to remove from testing
>>> packages whose packaging 'style' is clearly outdated, such as packages
>>> not updated since 2004 ('beav' is an example)...
>>
>> Is there something wrong with those packages? If so, what is it exactly?
>> You can file RC bugs for real issues obviously.
> 
> Well, no, there doesn't seem to be any serious user-visible issues.
> 
> That's why I keep wondering whether it makes sense to just keep all this
> technical debt around.

In my opinion it makes sense to remove packages like these that are
effectively unmaintained. Their removal from testing may trigger actual
users to take over active maintenance. And if no one steps up we can get
rid of dead weight.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Re: Fwd: bind9_9.11.17+dfsg-1_amd64.changes REJECTED

[Sebastiaan Couwenberg]

On 3/21/20 1:29 PM, Ondřej Surý wrote:
> This seems like a regression to me, but before I fill a bug with lintian, is 
> there anything I can do to my packages to fix this?
It's fixed in lintian (2.58.0), see:

 https://bugs.debian.org/954146

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Salsa "Emails on push" send only mails for tags

[Sebastiaan Couwenberg]

On 2/24/20 4:40 PM, Andreas Tille wrote:
> On Mon, Feb 24, 2020 at 04:07:37PM +0100, Sebastiaan Couwenberg wrote:
>> On 2/24/20 4:04 PM, Andreas Tille wrote:
>>> This worked since we moved to Salsa but since some weeks only
>>> "Tag push" is triggering any mails.  Did I missed something
>>> that the behavious on push events had changed or is this a bug
>>> on Salsa which I should report?
>>
>> You need to reconfigure the service. I used the REST API to set the
>> configuration again after which the emails for commits worked again.
> 
> Would you mind sharing the code you used?

https://salsa.debian.org/debian-gis-team/scripts/blob/master/salsa-configure-repositories.pl

Edit line 506 to:

 if(!$data->{active} || 1) {

Hack out any features you don't want to configure, the script defaults
to configure everything as expected for repos of the Debian GIS team. So
set the group, email, and IRC channel accordingly:

 ./salsa-configure-repositories.pl \
   -n 0 \
   -G  \
   -e  \
   -i 

> Is that rest of configuration needed for every single repository or
> per team?

Yes, every repo needs to be configured.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Salsa "Emails on push" send only mails for tags

[Sebastiaan Couwenberg]

On 2/24/20 4:04 PM, Andreas Tille wrote:
> This worked since we moved to Salsa but since some weeks only
> "Tag push" is triggering any mails.  Did I missed something
> that the behavious on push events had changed or is this a bug
> on Salsa which I should report?

You need to reconfigure the service. I used the REST API to set the
configuration again after which the emails for commits worked again.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

NEW processing time (Was: https://tracker.debian.org/pkg/dballe)

[Sebastiaan Couwenberg]

On 12/29/19 3:53 PM, Theodore Y. Ts'o wrote:
> On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote:
>> some time ago I uploaded a new version of dballe, which went through NEW
>> because of a change in binary package names (SONAME bump, IIRC). It took
>> two weeks to go through NEW and I turned my energy towards other things
>> since then.
> 
> Wow, two weeks?  I uploaded a new version of f2fs-tools back in July,
> with the same issue (SONAME bump), and it's still not gotten through
> NEW.
> 
> I had assumed everyone was waiting 5-6+ months to get through NEW

It seems to differ depending on the package. Every month the qgis
package has to go through NEW due to SONAME bumps as well, and this is
usually processed within a week or two. Possibly because the changes
since the last time it was in NEW is limited.

In March netcdf will be in NEW for a year, a number of subsequent
upstream releases have accumulated there. I suspect this may be another
case where the package got stuck an needs an intervention to get it
acceptable again.

Asking for explicit review of a package via email or IRC tends to work
reasonably well.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Sebastiaan Couwenberg]

On 4/13/19 10:20 AM, Lucas Nussbaum wrote:
> Additionally (and much more controversially I guess :-) ) I also added
> an analysis of "package smells"[3], such as "not using dh", "not using a
> recent debhelper compat level", "not using a 3.0 source format", etc. I
> understand that in some cases there might be good reasons to keep those
> "smells", but I find it valuable to have them presented in a more
> actionable way to fix the cases that should be fixed. So there's a list
> of smells, sorted by maintainer/uploader [4].

You should check if those issues present in unstable are not already
fixed in experimental.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Re: Q: Packaging wiki documentation.

[Sebastiaan Couwenberg]

On 08/16/2018 07:45 AM, Paul Wise wrote:
> On Thu, Aug 16, 2018 at 4:32 AM, Alec Leamas wrote:
>> But where is that old packaging repo?

 https://salsa.debian.org/debian-gis-team/opencpn

You should talk to the OSGeoLive people, who kept the opencpn package in
their Ubuntu based distribution.

You are also very welcome to maintain the opencpn package within the
Debian GIS team. See our team policy on how to join:

 https://debian-gis-team.pages.debian.net/policy/

> If the GIS team haven't migrated it to git and salsa, it will be
> somewhere in the old giant SVN repo (680MB):
> 
> https://alioth-archive.debian.org/svn/pkg-grass.tar.xz

There too, but requires digging.

Kind Regards,

Bas

Re: Bug filing for autopkgtest regressions? [Was: Re: appears to break multiple autopkgtests]

[Sebastiaan Couwenberg]

On 06/29/2018 01:41 AM, Ian Jackson wrote:
> Paul Gevers writes ("Re: Bug filing for autopkgtest regressions? [Was: Re: 
> appears to break multiple autopkgtests]"):
>> On 28-06-18 20:50, Sebastiaan Couwenberg wrote:
>>> Please don't file bugs until the triggering package is a single package.
>>> Case in point, the upload of gdal (2.3.1+dfsg-1) triggered the
>>> autopkgtest of r-cran-mi/1.0-6 which failed because r-base-core was also
>>> updated to 3.5.0-5. The latter is the actual cause of the regression,
>>> not gdal which triggered the autopkgtest. I would be annoyed if a bug
>>> was filed against gdal in this case, and having to reassign it.
> 
> I find this response perplexing (although I confess I don't quite
> follow all the package relationships here, nor the bug referred to).
> 
> Sebastian, are you not more worried about the possibility that
> r-base-core would migrate, causing lossage, than that you would
> receive a bug mail requiring a simple BTS control action to reassign ?

I don't have the energy to care about packages outside of my control.

R people should take care of these packages by noticing regressions in
their packages.

>>> How will you deal with cases such as these other packages than the
>>> trigger are the cause?
>>
>> This is exactly the response why I haven't done this before. I can't
>> deal with that (apart from the investment of "some effort").
> 
> Quite.  In the general case it is not easy to determine the cause.
> People in charge of CI systems should not be expected to do that kind
> of investigation.  Ideally they would be expected not to do any triage
> at all.  That task needs to be distributed amongst the whole project.
> 
> CI failure triage and investigation needs to be done by the
> maintainer(s) of involved package(s), who probably have some idea (or
> some way to guess or find out) what on earth is going on.

This. And don't shift the burden to the maintainer of a package which
just happened to trigger autopkgtests, the maintainers of the package
whose tests fail are primarily responsible.

>> So there is exactly this risk. On the other hand, the risk is that a
>> (severe, who knows?) regression migrates because no bug is filed. I
>> agree with Chris' response and I think most maintainers would rather
>> want it and reassign, than not getting it. How to judge if
>> Sebastiaans response is that of the minority or the majority? (And
>> what does that mean for the outcome anyways?)
> 
> If we cannot resolve this some other way we have, really, three ways
> to decide:
> 
>  1. You just go ahead.
> 
>  2. You ask the DPL or owneer@bugs or the TC or someone for a formal
>  decision.  Then, if the DPL or the TC say to go ahead, you add
>  something to your emails along the lines of "This message was sent
>  after consultation with { whoever }.  if you think that { mails of
>  this kind should not be sent | bugs of this kind should not be
>  filed }, please take it up with { owner@bugs | DPL TC }.
> 
>  3. You do not send the mails.
> 
> Note that not making a decison is equivalent to (3).

Kind Regards,

Bas

Re: Bug filing for autopkgtest regressions? [Was: Re: appears to break multiple autopkgtests]

[Sebastiaan Couwenberg]

On 06/28/2018 07:50 PM, Paul Gevers wrote:
> If one (me) can't determine the likely principle package that needs
> fixing after some effort [1], one bug (per upload of the triggering
> package) can be filed against the trigging package with the other
> packages in X-Debbugs-CC and in Affects at normal severity. This bug can
> contain similar text as we agreed upon earlier [2] (I'll write a
> proposal if this idea is not rejected).

Please don't file bugs until the triggering package is a single package.
Case in point, the upload of gdal (2.3.1+dfsg-1) triggered the
autopkgtest of r-cran-mi/1.0-6 which failed because r-base-core was also
updated to 3.5.0-5. The latter is the actual cause of the regression,
not gdal which triggered the autopkgtest. I would be annoyed if a bug
was filed against gdal in this case, and having to reassign it.

How will you deal with cases such as these other packages than the
trigger are the cause?

Kind Regards,

Bas



signature.asc
Description: OpenPGP digital signature

Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]

[Sebastiaan Couwenberg]

On 05/25/2018 12:09 PM, Mattia Rizzolo wrote:
> On Thu, May 24, 2018 at 09:02:04PM +0200, Sebastiaan Couwenberg wrote:
>> On 05/24/2018 08:53 PM, Raphael Hertzog wrote:
>>> On Thu, 24 May 2018, Sebastiaan Couwenberg wrote:
>>>> None of the other QA tools mail the maintainer without them asking for
>>>> it, autopkgtest shouldn't either.
>>>
>>> With the exception of piuparts, none of them affect testing migration.
>>
>> What makes autopkgtest such a beautiful and unique snowflake that it
>> should be treated differently from piuparts?
> 
> If you have added an autopkgtest to your package, you probably have an
> interest on it being run and pass, otherwise why did you bother in the
> first place?

DDPO, tracker.d.o, and the testing excuses already show the autopkgtest
information I'm interested in.

Unlike some maintainers I track the state of my packages daily and closely.

Kind Regards,

Bas



signature.asc
Description: OpenPGP digital signature

Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]

[Sebastiaan Couwenberg]

On 05/24/2018 08:53 PM, Raphael Hertzog wrote:
> On Thu, 24 May 2018, Sebastiaan Couwenberg wrote:
>> None of the other QA tools mail the maintainer without them asking for
>> it, autopkgtest shouldn't either.
> 
> With the exception of piuparts, none of them affect testing migration.

What makes autopkgtest such a beautiful and unique snowflake that it
should be treated differently from piuparts?

> Conversely, the autoremoval mails and the testing migration mails are sent
> to package maintainers by default.

Those are not from QA tools, and don't contain false positives.

Kind Regards,

Bas

Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]

[Sebastiaan Couwenberg]

On 05/24/2018 08:28 PM, Raphael Hertzog wrote:
> Hi Paul,
> 
> On Wed, 23 May 2018, Paul Gevers wrote:
>> I have had a complaint about my e-mail, boiling down to it should be
>> opt-in. I am not fully convinced (as I fear too many package maintainers
>> will miss the fact their autopkgtest delays another package, but I want
>> to start sending the e-mails to
>> dispatch+$package_cont...@tracker.debian.org. How does that sound? Are
>> there other/better options?
> 
> As pointed out by other, this is certainly not better. I have to agree
> with you that this should not be opt-in.

None of the other QA tools mail the maintainer without them asking for
it, autopkgtest shouldn't either.

Kind Regards,

Bas

Re: Non-free RFCs in stretch

[Sebastiaan Couwenberg]

On 03/04/2017 10:13 AM, Simon Josefsson wrote:
> I have searched for non-free licensed IETF RFCs in the archive and found
> the files below in the stretch suite.  Compare earlier work here [1].

Instead of trying to get standards documents out of Debian, I'd rather
see effort invested in working on solutions to get Debian able to
include them.

Standards are important to our industry, yet Debian is not able to
include their works because modification is not allowed without going
through the standards body. I don't think that is entirely unacceptable,
although I acknowledge that certain standards bodies can be difficult or
unpleasant to work with.

I'd like to see a compromise in the DFSG like #4 for standards to allow
their inclusion in Debian when their license at least allows
modification when changing the name or namespace for schemas and the like.

With a DFSG compromise for standards we have better position to
negotiate with the standards bodies to use compatible terms for their
standards works. Instead of our current position that their works are
not acceptable for Debian.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Re: What is exactly the "canonical URI" for Vcs-{Git,Browser}?

[Sebastiaan Couwenberg]

On 01/20/2017 11:56 AM, Boyuan Yang wrote:
> # This one seems acceptable, too
> Vcs-Browser: https://anonscm.debian.org/cgit/pkg-foo/bar.git
> 
> # This one is also acceptable
> Vcs-Git: https://anonscm.debian.org/git/pkg-foo/bar.git

These are the ones you should use, because both use encryption for the
connection and contrary to git+ssh URLs, and account on Alioth is not
required to checkout.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Re: soft freeze

[Sebastiaan Couwenberg]

On 01/14/2017 03:47 PM, Pirate Praveen wrote:
> Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote:
>> No new source packages are allowed into stretch, new upstream
>> versions of packages which are in testing are still allowed.
> 
> Is this applicable to new dependencies required for updating an
> existing package as well? For example, diaspora 0.6.0.0 is
> already in testing, I'd like to update it to 0.6.2.0, but the new
> upstream release depends on two packages not in testing
> (useragent and secure_headers). Would this be allowed?

No, because the source packages for the two dependencies are not already
in testing.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Re: soft freeze

[Sebastiaan Couwenberg]

On 01/14/2017 03:31 PM, Ralf Treinen wrote:
> Hi, I was under the impression that during the soft freeze (i.e, now) new
> usptream versions of packages that are already in testing are blocked
> from migrating. However, I can't find anything to this effect in the 
> announcements by the release team. Can please someone in the know
> confirm, or correct?

No new source packages are allowed into stretch, new upstream versions
of packages which are in testing are still allowed.

"
 We have passed the 5th of January, which means that no new source
 packages will enter stretch as announced in [1].  This also applies to
 packages that have been (or will be) removed from stretch.
"

https://lists.debian.org/debian-devel-announce/2017/01/msg2.html

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Road to Stretch: let's stop increasing major version number in critical libraries at this point

[Sebastiaan Couwenberg]

On 11/05/2016 04:07 PM, Adrian Bunk wrote:
> On Sat, Nov 05, 2016 at 11:14:02AM +0100, Thomas Goirand wrote:
>> ...
>> Finally, with the above examples as illustration (and please, these
>> aren't attacks in any way...), I guess what I'm trying to say here is:
>>
>> While disruptive changes are necessary evils so we upgrade everything to
>> the latest version, I would like the Stretch freeze to be as short as
>> possible. Therefore, I'd prefer if my DD friends were holding on
>> upgrading to (non bugfix only) new upstream releases of libraries.
> 
> as announced many months ago, the transiontion freeze is today (sic).
> 
> This is exactly to ensure that no new disruptive library changes can
> be started after today.

If only all maintainers would coordinate their transitions, too many
unfortunately don't. And those are unlikely read Thomas' plea either, so
disruptive library changes caused by uncoordinated transitions are
unfortunately still likely to happen.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: More 5 november in the release schedule

[Sebastiaan Couwenberg]

On 11/05/2016 01:39 PM, Geert Stappers wrote:
> Today is november fifth, day of the soft freeze in the Debian release 
> schedule.

The soft freeze was moved to January 5th, today is the day of the
transition freeze:

"
 Key release dates

 [2016-Nov-05] Transition freeze
 [2016-Dec-05] Mandatory 10-day migrations
 [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
   migrations)
 [2017-Feb-05] Full freeze

 As always, Debian 9 "Stretch" will be released "when it's ready".
"

https://release.debian.org/

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Re: Doxygen has 3 RC bugs preventing packages to build - is droping documentation a sensible option?

[Sebastiaan Couwenberg]

On 10/28/2016 02:40 PM, Andreas Tille wrote:
> On Fri, Oct 28, 2016 at 01:18:37PM +0100, James Cowgill wrote:
>>
>> I just tried building the version of cimg in its git repo and it worked
>> fine...
>>
>> It looks like the % and & handling was fixed in doxygen 1.8.12 which is
>> in unstable. I expect there is a bug somewhere involving URL fragments,
>> but it no longer affects cimg.
> 
> A, thanks for pointing this out.  From this point of view I could
> probably even close #836168 and use a versioned Build-Depends for cimg.
> However, I'm wondering the following:  If doxygen is RC buggy (#818379,
> #818787) and the needed version will not make it to testing (no idea why
> doxygen 1.8.11 remained in testing despite the RC bugs) cimg can not be
> build in testing ... and may be the to be released stable.  This sounds
> wrong to me.

doxygen was not autoremoved from testing due to the large number of
packages relying on it, it is among the key packages excluded from
testing autoremoval, see:

 https://udd.debian.org/cgi-bin/key_packages.cgi

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Why is 'yosys' still marked for autoremoval?

[Sebastiaan Couwenberg]

On 10/01/2016 07:47 PM, Ruben Undheim wrote:
> Can anyone tell me why 'yosys' is marked for autoremoval from testing because
> of a bug which has already been fixed?
> 
> See here:
>   https://tracker.debian.org/pkg/yosys
> 
> The bug #835678 was fixed in (and is marked as such) in 0.6-7 which is
> currently in testing.
> 
> Have I been able to hit some kind of buggy corner case in the packaging
> infrastructure or am I missing something?

The bug data in UDD is having some issues with the affected
distributions, there is a bugreport for that:

 https://bugs.debian.org/839385

The bugreport for yosys is like #836993 for qgis, in UDD the bugreport
is still marked as affects_testing & affects_unstable:

 udd=> SELECT bugs.*,
  bugs_found_in.version AS found,
  bugs_fixed_in.version AS fixed
 FROM bugs,
  bugs_found_in,
  bugs_fixed_in
WHERE bugs_found_in.id = bugs.id
  AND bugs_fixed_in.id = bugs.id
  AND bugs.id = 835678;
 -[ RECORD 1 ]+
 id   | 835678
 package  | src:yosys
 source   | yosys
 arrival  | 2016-08-28 10:39:22
 status   | done
 severity | serious
 submitter| Lucas Nussbaum 
 submitter_name   | Lucas Nussbaum
 submitter_email  | lu...@debian.org
 owner|
 owner_name   |
 owner_email  |
 done | Ruben Undheim 
 done_name| Ruben Undheim
 done_email   | ruben.undh...@gmail.com
 title| yosys: FTBFS: latex errors
 last_modified| 2016-09-22 17:57:12
 forwarded|
 affects_oldstable| f
 affects_stable   | f
 affects_testing  | t
 affects_unstable | t
 affects_experimental | f
 affected_packages|
 affected_sources |
 found| yosys/0.6-6
 fixed| yosys/0.6-7

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Use and abuse of the unreproducible tag

[Sebastiaan Couwenberg]

Dear Santiago,

Thanks for publicly shaming me, makes me feel much better about your
bugreports.

On 09/13/2016 01:49 PM, Santiago Vila wrote:
> You can't reproduce it, or you don't want to reproduce it?

I added the tag because I couldn't reproduce the issue in unstable where
we build our packages. It's great that it's reproducible in testing, but
we don't upload to testing. I consider the tag appropriate, if there is
consensus in the project that it's not feel free to remove the tags again.

I will not participate further in this discussion on -devel, so please
do not CC me.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Better Lintian checks

[Sebastiaan Couwenberg]

On 25-01-16 19:47, Bastien Roucaries wrote:
> I expect more problems  detected in  the next few days

I guess the autorejects for Multi-Arch: no are among those problems.
The use of Multi-Arch: no was suggested by

 https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html

The reject message refers to #768353 which was fixed in November 2014,
but the fix is most likely not available in stable yet, and hence still
an issue on the Debian infrastructure?

If "Multi-Arch: no support in Debian is broken" is still true, the
suggested fix for old-style-config-script-multiarch-path is not an
actual solution.

Should the autoreject be removed, or should lintian suggest a different fix?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: debian queue demon keeps spawning emails for clblas/2.6-2 upload

[Sebastiaan Couwenberg]

On 19-08-15 10:37, Ghislain Vaillant wrote:
 Just to report that d-sicience-maintainers [1] keeps receiving email
 about an upload (clblas/2.6-2) which has been accepted already.

Removing the left over .changes file should fix this, you can use `dcut`
for this:

 dcut rm -f clblas_2.6-2_amd64.changes

 Can anyone who has access have a look and kill whatever process is
 responsible for this.

It seems someone has already removed the the changes file.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Bug#780001: ITP: node-isarray -- JavaScript Array#isArray for older browsers

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/08/2015 12:43 AM, Guus Sliepen wrote:
 On Sun, Mar 08, 2015 at 12:08:56AM +0100, Bas Couwenberg wrote:
 
 * Package name: node-isarray
 
 isarray provides Arrray#isArray for older browsers.
 
 node-isarray is required for node-readable-stream (#761442) which
 in turn is required for node-decompress-zip (#779498).
 
 The node-isarray package will be maintained in the JavaScript
 team.
 
 This package provides only one function, and that function contains
 only one line of code. Can this function not be included in 
 node-readable-stream itself or in some base node package?

It may be possible to patch it into another package, but in the
Node.js ecosystem it's a separate module for which a separate package
makes sense.

isarray is also required for has-binary-data, has-binary 
socket.io-parser, so merging it into the nodejs package seems most
appropriate if we go that route.

Kind Regards,

Bas

- -- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJU+5EnAAoJEGdQ8QrojUrxxnMP/2+wsi0PreR+4Yga1eV6TWaj
zG9K5c94HXThTgQXmBvsq692NUcwgWBEHIYrG+ju/meiUrikfYMqPIpQJ4TuMVwy
WnneFwdfx14R1YmHrcH6pPa0kY0bi4y7JdmALcaS9Q3psV5MAZ94f32s8McmFrJg
G3m6M+cfSi+buUUU19Wo6Ue3PJfNX6ZT5muu3wsgVIoH54ZGrkqjIDCQQoECHpzP
uvVfGwO9e02Q+H8wpmL6viaSH/589/c3QfdntRsHwZ2grVj8B6zlkPrNJsHj4faC
lb1Sx76F0LIZrTL0gP2c12ZYFbBWgB4By/jeig0LGhznTYROvafVOrU5mYTyjpvP
KHOVi0J9WMPm/vtTez2mopgtoPmNVzlrSEZd4kdloCJtL3EsyCTU+ydwZdiHpjGQ
UPoIbmxPt5P9/gPPWQMyjtslKDBQpLDaUUCbUY5N5xRSDH68dF3ApurfEOEFqhq3
RQN1caPnfGG7rTHxfmjpzU5DYNSeH5EqHSl9hgR3+MFfYpZxcScX0imvoGJN2rVT
1Z7NhnACG3xrcfbimbHjQTBCN3BOYlS906AehHm8sVncih4NflIIoYjva8uItLyY
7c4K5V5v8TFVAJZ/0NY1f8pw7a1HFr2SvTRsrwLW6SbWU12+13ePkWZccB0YMvNJ
WSDhTOPNDvSxNT3dNnHp
=YK8B
-END PGP SIGNATURE-


-- 
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/54fb9127.8080...@xs4all.nl

Re: GUI Configuration tool for main Debian window managers

[Sebastiaan Couwenberg]

 There was webmin/usermin for a long time in debian, until it was kicked
 off.
 The repo masters claimed, bacaus of bad coding. They named ist
 Spaghetti
 code or similar.

That's not how I remember it. Jaldhar H. Vyas had the package removed
because he was not longer able to maintain it, not because webmin was bad
but because noone stepped up to help maintain it. See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343897
http://www.braincells.com/debian/index.cgi/search?text=webmin

Kind Regards,

Bas


-- 
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/13b604adf020efbedea34f35b1836ca7.squir...@webmail.xs4all.nl

Bug#723700: ITP: tinyows -- lightweight and fast WFS-T server

[Sebastiaan Couwenberg]

Package: wnpp
Owner: Bas Couwenberg sebas...@xs4all.nl
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-...@lists.debian.org

* Package name: tinyows
  Version : 1.1.0-3
  Upstream Author : Barbara Philippot, Olivier Courtin and the MapServer
team.
* URL : http://www.mapserver.org/tinyows/
* License : MIT/X11
  Programming Lang: C
  Description : lightweight and fast WFS-T server

TinyOWS is a lightweight and fast implementation of the OGC WFS-T
specification. Web Feature Service (WFS) allows querying and retrieval
of features. The transactional profile (WFS-T) allows inserting, updating
or deleting such features.

From a technical point of view WFS-T is a Web Service API in front
of a spatial database. TinyOWS is deeply tied to PostgreSQL/PostGIS
because of this.

TinyOWS implements strictly OGC standards and pass successfully all
WFS OGC CITE tests (and even beta ones).

TinyOWS is part of MapServer Suite, but provided as a distinct module
(i.e you could use it in conjunction with MapServer and MapCache, or
as a standalone app). But both MapServer and TinyOWS could use the same
configuration file, if you want to (or native TinyOWS XML config file).


-- 
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/523a3fde.1060...@xs4all.nl

Bug#721730: ITP: libpg-hstore-perl -- Perl module for working with PostgreSQLs HSTORE data type

[Sebastiaan Couwenberg]

Package: wnpp
Owner: Bas Couwenberg sebas...@xs4all.nl
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libpg-hstore-perl
  Version : 1.03
  Upstream Author : Galimov Albert a...@cpan.org
* URL : http://search.cpan.org/dist/Pg-hstore/
* License : Beerware
  Programming Lang: Perl
  Description : Perl module for working with PostgreSQLs HSTORE data
type

Decodes and encodes PostgreSQLs HSTORE data type into/from Perl hash refs.

This module was previously known as DBD::Pg::hstore, but has been
renamed to Pg::hstore because it's not DBD specific.

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)


-- 
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/5225fa94.3040...@xs4all.nl

Re: [EMAIL PROTECTED] Package Submission

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Zachary Palmer wrote:
 I'm rather new at this, so I don't know exactly how I should proceed.  
 What is the process  for screening my package?
 Is this the appropriate mailing list to discuss the matter?

The debian-mentors list is probably a better place to discuss this
package. The mentors project also has their own repository to which you
can upload your package so others can test it.

Have a look at:
http://mentors.debian.net/cgi-bin/welcome
http://mentors.debian.net/cgi-bin/maintainer-intro


- --
GnuPG: 0x77A975AD

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGge4bRWRRA3epda0RAqm3AKCVd6YIZ38kjjga/sccSosgNglgWACfd+WO
mKEKJq82fYAXBvUKcal8mzk=
=LqSR
-END PGP SIGNATURE-


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

Re: [EMAIL PROTECTED] Package

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Charles Plessy wrote:
   Distribution of this software is prohibited. It may only be 
   obtained by downloading from Stanford's web site
   (http://folding.stanford.edu and pages linked therein).
 
 I guess that in that case, there would be a link from the Stanford site to
 packages.debian.org for instance.

There is a FreeBSD packages which installs the [EMAIL PROTECTED] client by 
downloading
the FAH504-Linux.exe binary from the Stanford website. The Gentoo ebuild
works very similar and has been around for a long time.

All these installers have been silently approved by the project as they
don't violate the EULA.

Nick Lewycky wrote a Debian package to install the [EMAIL PROTECTED] client on 
Debian,
fahclient-installer, see:
http://bugs.debian.org/261257
http://lists.debian.org/debian-mentors/2004/07/msg00338.html

That specific code is no longer available online AFAIK, but I still have
a copy which I used to add support for multiple CPUs. I never finished
this, due to lack of time, but I can give you the code if you (Zachary
Palmer) like.

 Do they frequently upgrade ? How long can an old client connect ? In that
 case, packaging would be commiting yourself to follow the upgrades
 closely. I do not think that it would help our users if the Debian package
 would periodically provide a binary which is not allowed to connect.

[EMAIL PROTECTED] doesn't update its client regularly. The release cycle is 
possibly
slower than Debian Stable. There has been talk of v6 for several years
now, and I think that version just recently went into alpha testing if
it made it that far (I'm no longer a beta tester with early access to
project info, so I can't verify that).

The v4 [EMAIL PROTECTED] client still works eventhough v5 has been out for a 
long
time. Its usefulness is somewhat reduced because there are no more
deadlineless WUs handed out by the project, but it still works. I don't
think this is a real problem.

 Maybe the Debian-Med packaging team could provide you a safety net by
 co-maintaining the package and hosting the /debian dir in our SVN repo, so
 that you can take holidays without coming back with an obsolete package
 and angry users. However, would the package not be actively followed by a
 dedicated person, it would be better removed (or not packaged at that
 point)

I'm also willing to help co-maintain a Debian package for [EMAIL PROTECTED] I'm
currently the upstream maintainer of qd since Dick Howell passed away,
which Claudio Moratti packaged as part of kfolding. Maybe he's
interested too?

 Lastly, I am not sure that closed-sourceness is the best strategy against
 cheating. I guess that the expertise area of [EMAIL PROTECTED] is structural
 biology, wheras the expertise of cheaters is... well... cheating.

Guaranteeing the integrity of the research is indeed the primary reason
to keep the [EMAIL PROTECTED] client and cores closed-source. Even though they 
are
build with GPL components like Gromacs. But [EMAIL PROTECTED] has been
granted a non-commercial, non-GPL license for Gromacs, so [they] are not
required to release [the] source.
http://folding.stanford.edu/gromacs.html

Regards,

Bas

- --
GnuPG: 0x77A975AD

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGfOS1RWRRA3epda0RAh/SAJ9IbAPuNRXg7khljzERTPAPdOCxcACfVSRe
cZe2zKnqrG+ZJACv4Qt3rII=
=Rs4C
-END PGP SIGNATURE-


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

Re: [EMAIL PROTECTED] Package

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Magnus Holmgren wrote:
 Sebastiaan Couwenberg wrote:
 Has there been any talk about moving to the BOINC infrastructure?

There used to be work on a BOINC [EMAIL PROTECTED] client, but this work has 
stopped
due to personnel turnover.

See:
http://fahwiki.net/index.php/Alternative_FAH_Platforms#BOINC
http://folding.stanford.edu/FAQ-highperformance.html

 But the only way to be sure that the individual users don't cheat would
 be to require Treacherous Computing. Instead, BOINC-powered projects
 rely on handing out several copies of each work unit and checking that
 the reported results match. Perhaps [EMAIL PROTECTED] does this as well.

[EMAIL PROTECTED] doesn't duplicate work, each WU is only assigned once by 
default. If
a WU has not been returned when the Preferred Deadline is reached, then
the WU is assigned to another client.

Some newer WUs are duplicate work in a sense, they verify the results of
the new SMP client  core on single CPU/core machines.

Each assigned WU is verified at upload, the information used in this
verification is stored in the queue.dat (which you can dump with qd).

See:
http://linuxminded.xs4all.nl/software/qd-tools/documentation/queue.dat-layout/queue-assignment-info-present.html

Regards,

Bas

- --
GnuPG: 0x77A975AD

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGfQybRWRRA3epda0RAnrJAJ9SehxyhwAlOK6uyCsWbuzqmFqPeACfXLjZ
wP/yVr89HEKcthIt6nXNiBU=
=m7cV
-END PGP SIGNATURE-


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