Re: [RFH] Running Python tests that require the source to be installed
On 10/24/24 1:04 PM, Andrey Rakhmatullin wrote:
On Thu, Oct 24, 2024 at 12:57:42PM +0200, Sebastiaan Couwenberg wrote:
You may need to copy some additional files there, e.g.:
export PYBUILD_BEFORE_TEST=cp -r {dir}/foo {dir}/bar {build_dir}
export PYBUILD_AFTER_TEST=rm -rf {build_dir}/foo {build_dir}/bar
Consider using pybuild.testfiels for this.
Only if that supports subdirectories now.
Last time I tried that, it didn't.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: [RFH] Running Python tests that require the source to be installed
On 10/24/24 12:44 PM, John Paul Adrian Glaubitz wrote:
export PYTHONPATH = $(CURDIR)
Setting PYTHONPATH to the pybuild build_dir likely works better:
export PYTHONPATH=$(shell pybuild --print build_dir -i python3)
You may need to copy some additional files there, e.g.:
export PYBUILD_BEFORE_TEST=cp -r {dir}/foo {dir}/bar {build_dir}
export PYBUILD_AFTER_TEST=rm -rf {build_dir}/foo {build_dir}/bar
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Will i386 released for Trixie and if no can we stop working on it now?
On 10/14/24 3:54 PM, Simon Josefsson wrote: Sebastiaan Couwenberg writes: On 10/14/24 2:42 PM, Charles Plessy wrote: The package names starts with r-cran. Time is better spent on updating the tooling to add architecture-is-64-bit to the build dependencies for those packages, as well as generating RM bug reports for the partial removals on [i386 armel armhf]. Is that the recommended solution for packages that wants to stop supporting 32-bit architectures? I don't think there is a recommended solution. Using architecture-properties is relatively easy, avoiding the need to main architecture lists. Could there be some automatic magic to transitively remove 32-bit binaries of packages where the most recent upload of a package uses 'architecture-is-64-bit'? Someone would need to implement a service which monitors changes to the archive that files RM bugreports for packages that introduce architecture-properties dependencies. So far I've just filed the RM bugreports manually using reportbug, and built dependency trees for packages with many rdeps using `dak rm -a i386,armel,armhf` on coccia to keep track of which bugreports need to block each other. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Will i386 released for Trixie and if no can we stop working on it now?
On 10/14/24 2:42 PM, Charles Plessy wrote: The package names starts with r-cran. Time is better spent on updating the tooling to add architecture-is-64-bit to the build dependencies for those packages, as well as generating RM bug reports for the partial removals on [i386 armel armhf]. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Strange armel build error
On 8/18/24 11:23 AM, Andrey Rakhmatullin wrote: On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote: On 18/08/2024 09:04, Stephen Kitt wrote: On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas wrote: Or just exclude that architecture i. e., list all archs but armel? If you can’t fix the build, you don’t need to exclude the architecture — you can ask for removal of the armel package in testing. That will allow the package to migrate even if armel is missing. This looks to me like a sound solution in this case. After all, opencpn is a full-fledged GUI leaf package without reverse deps and zero users on armel hardware. But then again, how is this done? If by this you mean asking for a removal then reportbug release.debian.org Better file an RM bugreport for unstable against ftp.debian.org, that also gets the package removed from testing once its gone from unstable. And your package no longer blocks transitions of its dependencies for which it gets rebuilt in unstable. See also: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removing-packages https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removals-from-testing Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: DD's, Debian Mentors needs you!
On 7/7/24 11:32 AM, Niels Thykier wrote: The salsa-CI pipeline basically does most of these (3+7 being very clear exceptions, do not remember if 4 is covered by salsa-ci, but adding it would probably easy) and that infrastructure already has "no trust" code execution flows. Salsa CI supports building packages twice, but that jobs is no longer enabled by default: https://salsa.debian.org/salsa-ci-team/pipeline#enable-building-packages-twice-in-a-row Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Running pybuild tests with search path for entry_points()
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]
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
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
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&tag=time-t#_0_2_2 https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org&tag=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 ?
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
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
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.]
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.]
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
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
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
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
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
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
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?
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
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?
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?
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
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?
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?
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?
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?
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
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
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
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
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
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)
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"
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.
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]
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]
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]
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]
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]
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
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}?
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
On 01/14/2017 03:47 PM, Pirate Praveen wrote: > Sebastiaan Couwenberg 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
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
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
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?
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?
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
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
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
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
-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
> 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
Package: wnpp Owner: Bas Couwenberg 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
Package: wnpp Owner: Bas Couwenberg 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 * 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
-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
-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]
Re: [EMAIL PROTECTED] Package
-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]
