Re: Help needed for watch file after bitbucket changed download page

[Juri Grabowski]

Hello Andreas,

On 2022-09-29 14:54 4, Andreas Tille wrote:

I confirm this works.  However, uscan does not do the usual link to
orig.tar.gz.  Any idea why this is the case?

I have found this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896705

But did you have signing key from Rob Egan , because I
didn't found it on keyserver or in debian/upstream/signing-key.asc

Best Regards,
Juri Grabowski

Bitbucket changed download page - possibly lots of watch files affected (Was: Help needed for watch file after bitbucket changed download page)

[Andreas Tille]

Hi Nilesh,

Am Thu, Sep 29, 2022 at 03:43:58PM +0530 schrieb Nilesh Patra:
> I don't know how to go about it, but I suspect -devel might be a better list 
> for this since this is a general question and many package maintainers could 
> be using bitbucket sources.

While I considered debian-mentors@l.d.o usually the proper list to find
a solution for problems in watch files I agree that this should be made
public also on debian-devel.  It seems quite some packages are affected:

   
https://codesearch.debian.net/search?q=path%3Adebian%2Fwatch+bitbucket=1

My guess is that most of these watch files might be not working any more.
May be gitmode as proposed by Juri Grabowski[2] is a promising solution
(but as I wrote in my response it does not create the link to orig.tar.gz).

Kind regards

 Andreas.
 
> On 29 September 2022 12:54:47 pm IST, Andreas Tille  wrote:
> >Hi,
> >
> >the watch file for metabat[1] used to work nicely until some point in
> >time when bitbucket replaced `v@ANY_VERSION@` by the commit ID which is
> >not sensibly sorting any more.  Is there any trick how I can get
> >bitbucket pages working again?
> >
> >Kind regards
> >
> > Andreas.
> >
> >[1] https://salsa.debian.org/med-team/metabat/-/blob/master/debian/watch

[2] https://lists.debian.org/debian-mentors/2022/09/msg00153.html 

-- 
http://fam-tille.de

Re: Help needed with a dh_shlibs failure on non amd64 platforms

[Simon McVittie]

On Mon, 04 Jul 2022 at 09:29:54 +0200, Martin Quinson wrote:
> All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the
> package. They are added to the debian/libns3.36/DEBIAN/shlibs

Independent of the dh_shlibdeps failure that was already diagnosed, if
these libraries are public (i.e. other packages in Debian are allowed to
link against them) and the SONAMEs of the libraries are of the form
libns3-*.so.36.1, then the binary package that contains them should
probably be called something like libns3-36.1, rather than libns3.36.

(Either that, or they should be split up into one binary package per
library, named like libns3-bridge36.1 and so on, by mechanically
transforming their SONAMEs according to the convention documented
in Policy - but I can understand why you would prefer not to do that when
there are a large number of libraries with matching versioning.)

Otherwise, when the SONAMEs jump from libns3-*.so.36.1 to libns3-*.so.36.2
in a future version, any dependent packages that require libns3-*.so.36.1
would be broken by upgrading libns3.36 to a version that no longer contains
libns3-*.so.36.1.

> If you wonder, the cmake macro to define and build a library is in 
>   ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake
> I already had to patch it to support Debian:
> https://salsa.debian.org/debian/ns3/-/blob/master/debian/patches/library-soversion.diff
> This patch is ugly for now, but I'm already discussing with upstream so that
> they integrate the spirit of this patch to their code. They are receptive.

If you're giving advice to upstream, it's important to be aware of
whether the libraries are private (only to be used by other binary
packages within the same source package, like samba-libs or
libsystemd-shared) or public (with a -dev package that can validly be
used by other source packages, like libsmbclient or libsystemd0 or any
typical shared library like GTK or Qt). The correct advice to give to an
upstream for private shared libraries is not the same as the correct
advice for public shared libraries.

smcv

Re: Help needed with a dh_shlibs failure on non amd64 platforms

[Samuel Thibault]

Hello,

Martin Quinson, le lun. 04 juil. 2022 09:29:54 +0200, a ecrit:
>   dpkg-shlibdeps -Tdebian/libns3.36.substvars 
> debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1

x86_64-linux-gnu is only valid for amd64.

In

./debian/rules: -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DCMAKE_INSTALL_PREFIX=/usr

you want to use $(DEB_HOST_MULTIARCH) instead of hardcoding x86_64-linux-gnu

Samuel

Help needed with a dh_shlibs failure on non amd64 platforms

[Martin Quinson]

Hello all,

I come to you because I'm puzzled with a bug I have in one of my package, and
I'm seeking for help. Please CC me when answering as I'm not on this list.

The package is ns3, a scientific simulator of computer networks. This package is
huge, I seem to be the only active maintainer, but upstream is very
collaborative.

Upstream just moved from a build system called waf to cmake, which is an nice
move. They introduced a small python script saving the waf interface to their
users that don't like changes, and unfortunately the raw cmake interface is not
usable yet (cmake checks on files created by the script), so I cannot use the
plain classical cmake build in debian/rules. I did my best to mimick the
behavior of `dh --buildsystem=cmake` but I have a strange failure on non-amd64
platforms:
https://buildd.debian.org/status/package.php?p=ns3

The build, tests and install targets go well, until dh_shlibdeps. At that step,
I get a huge bunch of errors like the following:
```
   dh_shlibdeps -a
dpkg-shlibdeps -Tdebian/libns3.36.substvars 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wifi.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wave.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-visualizer.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-virtual-net-device.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-uan.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-traffic-control.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-topology-read.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-tap-bridge.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-stats.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-spectrum.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-sixlowpan.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-propagation.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-point-to-point.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-point-to-point-layout.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-olsr.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-nix-vector-routing.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-network.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-netanim.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-mobility.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-mesh.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-lte.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-lr-wpan.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet-apps.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-flow-monitor.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-fd-net-device.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-energy.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-dsr.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-dsdv.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-csma.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-csma-layout.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-core.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-config-store.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-buildings.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-bridge.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-applications.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-aodv.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-antenna.so.36.1
dpkg-shlibdeps: error: cannot find library libns3-bridge.so.36.1 needed by 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 (ELF format: 
'elf64-littleaarch64' abi: '020100b7'; RPATH: '')
dpkg-shlibdeps: error: cannot find library libns3-traffic-control.so.36.1 
needed by debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 
(ELF format: 'elf64-littleaarch64' abi: '020100b7'; RPATH: '')
```
This specific one is for arm64, but I get exactly the same problem for all
platforms but amd64.
https://buildd.debian.org/status/fetch.php?pkg=ns3=arm64=3.36.1%2Bdfsg-2=1656893780=0

All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the
package. They are added to the debian/libns3.36/DEBIAN/shlibs a few lines above
in the build log, and dh_strip found them further above in the log. What really
puzzles me is that the package builds fine on amd64 and i386. 

The package is uptodate on salsa, in case someone wants to test something
directly on the package. Fear not to do so, this package only takes one hour to
build on my machine :)

If you wonder, the cmake macro to define and build a library is in 
  ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake
I already had to patch it to support Debian:

Re: Help needed: C++ compile error with nix 2.5.1

[Jakub Wilk]

* Thomas Koch , 2022-01-16, 11:23:

https://github.com/NixOS/nix/issues/5923


The first bad commit is:
https://github.com/nlohmann/json/commit/0e694b4060ed55df

(This happens to be also the first bad commit for 
, so I guess it's the same 
issue.)


I don't know what's going on here, but the attached patch seems to fix 
it.


--
Jakub Wilk
diff --git a/src/libstore/realisation.cc b/src/libstore/realisation.cc
index f871e6437..eb3ca0198 100644
--- a/src/libstore/realisation.cc
+++ b/src/libstore/realisation.cc
@@ -78,7 +78,7 @@ Realisation Realisation::fromJSON(
 auto fieldIterator = json.find(fieldName);
 if (fieldIterator == json.end())
 return std::nullopt;
-return *fieldIterator;
+return std::string(*fieldIterator);
 };
 auto getField = [&](std::string fieldName) -> std::string {
 if (auto field = getOptionalField(fieldName))

Help needed: C++ compile error with nix 2.5.1

[Thomas Koch]

For a C++ programmer who cares about nix in Debian:
https://github.com/NixOS/nix/issues/5923

Thank you! Thomas

Re: help needed to resolve nodejs transition #963039

[Adrian Bunk]

On Fri, Jul 03, 2020 at 07:50:55PM +0200, Jérémy Lal wrote:
>...
> One can install nodejs 10 along with libnode64, and build node-iconv
> using libnode-dev 12 which links to libnode72.
> 
> However, running node-iconv tests in the autopkgtests environment requires
> the nodejs version that is linked against the same libnode abi (i hope that
> part is obvious).
> 
> But it's not the case: the tests are run with nodejs 10 from testing,
> against a package
> built with libnode72, so the module loading fails.
> 
> Those failures seem to be preventing transition to testing (which is
> understandable).
> Two questions:
> - how to fix the issue now
> - how to fix the issue for good

Is my understanding correct that a module built with a libnode
different from the one used by the nodejs package installed is
nonfunctional?

In other words, having more than one libnode library package installed
is always wrong?

In this case the correct solution is:
Package: libnode72
Breaks: libnode64

A generic version for future updates is:
Package: libnode72
Provides: libnode
Breaks: libnode

libnode64 did not provide libnode, so the generic version needs a 
special case for it:
Package: libnode72
Provides: libnode
Breaks: libnode64, libnode

Alternatively, you could additionally avoid the troubles of having to go 
through NEW for major new upstream versions by moving libnode into nodejs:
Package: nodejs
Provides: libnode72
Breaks: libnode64

> Thanks in advance for any help.
> 
> Jérémy

cu
Adrian

Re: help needed to resolve nodejs transition #963039

[Jérémy Lal]

Le ven. 3 juil. 2020 à 20:53, Jonas Smedegaard  a écrit :

> Quoting Jonas Smedegaard (2020-07-03 20:45:22)
> > Quoting Jérémy Lal (2020-07-03 19:50:55)
> > > I have a problem with the transition of nodejs:
> > > from version 10 with abi libnode64
> > > to version 12 with abi libnode72
> > >
> > > C(++) addons like node-iconv can be compiled using libnode-dev,
> > > so installing an addon automatically installs the right libnodeXX
> version.
> > > (all addons Build-Depend libnode-dev).
> > >
> > > One can install nodejs 10 along with libnode64, and build node-iconv
> > > using libnode-dev 12 which links to libnode72.
> > >
> > > However, running node-iconv tests in the autopkgtests environment
> requires
> > > the nodejs version that is linked against the same libnode abi (i hope
> that
> > > part is obvious).
> > >
> > > But it's not the case: the tests are run with nodejs 10 from testing,
> > > against a package
> > > built with libnode72, so the module loading fails.
> > >
> > > Those failures seem to be preventing transition to testing (which is
> > > understandable).
> > > Two questions:
> > > - how to fix the issue now
> > > - how to fix the issue for good
> > >
> > > Thanks in advance for any help.
> >
> > Have libnodeNN include a symbols file tracking changes to the ABI, so
> > that any C++ addon depending on a part of the ABI which changes gets
> > tightened package dependency on that specific binary release of the ABI.
>
> No wait, that's complete rubbish what I wrote above: We are talking
> about new major releases of the ABI so a symbols file would simply be
> reset completely - and also, what I was thinking should happen already
> does happen: node-iconv depends on a specific libnodeNN.
>
> Problem is (talking to myself here, you already know it) that we need to
> ensure that node-iconv is only ever _loaded_ by that same node as it is
> linked against.
>
> Only way I can imagine ensuring that is to extend symbols/shlibs
> handling to add Breaks (if that is even possible), or add breaks to the
> libnodeNN package itself so that only one libnodeNN can be present on
> the system at once.
>
> In which situations do we need libnodeNN to be co-installable?
>

Some other program linking against libnodePP.
The only case i know of is the one where libnode-dev provides libv8-dev.
But the absence of cases shouldn't be hushhushed.


>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: help needed to resolve nodejs transition #963039

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-07-03 20:45:22)
> Quoting Jérémy Lal (2020-07-03 19:50:55)
> > I have a problem with the transition of nodejs:
> > from version 10 with abi libnode64
> > to version 12 with abi libnode72
> > 
> > C(++) addons like node-iconv can be compiled using libnode-dev,
> > so installing an addon automatically installs the right libnodeXX version.
> > (all addons Build-Depend libnode-dev).
> > 
> > One can install nodejs 10 along with libnode64, and build node-iconv
> > using libnode-dev 12 which links to libnode72.
> > 
> > However, running node-iconv tests in the autopkgtests environment requires
> > the nodejs version that is linked against the same libnode abi (i hope that
> > part is obvious).
> > 
> > But it's not the case: the tests are run with nodejs 10 from testing,
> > against a package
> > built with libnode72, so the module loading fails.
> > 
> > Those failures seem to be preventing transition to testing (which is
> > understandable).
> > Two questions:
> > - how to fix the issue now
> > - how to fix the issue for good
> > 
> > Thanks in advance for any help.
> 
> Have libnodeNN include a symbols file tracking changes to the ABI, so 
> that any C++ addon depending on a part of the ABI which changes gets 
> tightened package dependency on that specific binary release of the ABI.

No wait, that's complete rubbish what I wrote above: We are talking 
about new major releases of the ABI so a symbols file would simply be 
reset completely - and also, what I was thinking should happen already 
does happen: node-iconv depends on a specific libnodeNN.

Problem is (talking to myself here, you already know it) that we need to 
ensure that node-iconv is only ever _loaded_ by that same node as it is 
linked against.

Only way I can imagine ensuring that is to extend symbols/shlibs 
handling to add Breaks (if that is even possible), or add breaks to the 
libnodeNN package itself so that only one libnodeNN can be present on 
the system at once.

In which situations do we need libnodeNN to be co-installable?


 - Jonas

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

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

signature.asc
Description: signature

Re: help needed to resolve nodejs transition #963039

[Jonas Smedegaard]

Quoting Jérémy Lal (2020-07-03 19:50:55)
> I have a problem with the transition of nodejs:
> from version 10 with abi libnode64
> to version 12 with abi libnode72
> 
> C(++) addons like node-iconv can be compiled using libnode-dev,
> so installing an addon automatically installs the right libnodeXX version.
> (all addons Build-Depend libnode-dev).
> 
> One can install nodejs 10 along with libnode64, and build node-iconv
> using libnode-dev 12 which links to libnode72.
> 
> However, running node-iconv tests in the autopkgtests environment requires
> the nodejs version that is linked against the same libnode abi (i hope that
> part is obvious).
> 
> But it's not the case: the tests are run with nodejs 10 from testing,
> against a package
> built with libnode72, so the module loading fails.
> 
> Those failures seem to be preventing transition to testing (which is
> understandable).
> Two questions:
> - how to fix the issue now
> - how to fix the issue for good
> 
> Thanks in advance for any help.

Have libnodeNN include a symbols file tracking changes to the ABI, so 
that any C++ addon depending on a part of the ABI which changes gets 
tightened package dependency on that specific binary release of the ABI.

 - Jonas

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

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

signature.asc
Description: signature

Re: help needed to resolve nodejs transition #963039

[Paul Gevers]

Hi Jérémy,

On 03-07-2020 19:50, Jérémy Lal wrote:
> Those failures seem to be preventing transition to testing (which is
> understandable).
> Two questions:
> - how to fix the issue now

One option is that the libnode72 add a Breaks on the broken versions of
node-iconv, node-expat, node-* in testing.

> - how to fix the issue for good

I think node-iconv and similar packages need to declare a *versioned*
dependency on nodejs. The trick is of course how to figure out the right
version at build time. (Of course that mostly defeats the purpose of
having co-installable libraries libnode*).

Paul



signature.asc
Description: OpenPGP digital signature

help needed to resolve nodejs transition #963039

[Jérémy Lal]

Hi,

I have a problem with the transition of nodejs:
from version 10 with abi libnode64
to version 12 with abi libnode72

C(++) addons like node-iconv can be compiled using libnode-dev,
so installing an addon automatically installs the right libnodeXX version.
(all addons Build-Depend libnode-dev).

One can install nodejs 10 along with libnode64, and build node-iconv
using libnode-dev 12 which links to libnode72.

However, running node-iconv tests in the autopkgtests environment requires
the nodejs version that is linked against the same libnode abi (i hope that
part is obvious).

But it's not the case: the tests are run with nodejs 10 from testing,
against a package
built with libnode72, so the module loading fails.

Those failures seem to be preventing transition to testing (which is
understandable).
Two questions:
- how to fix the issue now
- how to fix the issue for good

Thanks in advance for any help.

Jérémy

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Ulrike Uhlig]

Hi!

On 06.01.20 19:56, Alexander Wirt wrote:
> On Mon, 06 Jan 2020, Ulrike Uhlig wrote:
>>> On 28.12.19 18:16, Alexander Wirt wrote:
>> >From your replies to emails in this thread I was wondering: do you mean
>> that the Salsa team does not need, or does not want, help? Or does not
>> need, or want, help outside of a sprint?
> That basically means: yes we probably need help. But it also means that
> getting help should be done in a coordinated way, like introducing one or two
> team members during a sprint. Getting someone new involved always means
> overhead and should happen when there is time for such overhead. In my
> experience sprints are ideal for it. I also talked to some people about
> getting them involved in salsa, but there will also be a call for help. 
> 
> I / we plan to add at least one global admin and maybe one or two assistants
> that help with "user" support. 
> 
> We just need some time to plan and coordinate those things (around christmas
> is really a bad timing for such discussions)

Sounds like a good plan! :)

 -- ulrike

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 06 Jan 2020, Ulrike Uhlig wrote:

> Hi formorer,
> 
> > On 28.12.19 18:16, Alexander Wirt wrote:
> >> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> >> I am sure there are many ways to help the team and it is not just
> >> about Salsa/Gitlab admin stuff, but also about creating structure in
> >> the team, triaging issues, spreading best practices for users and
> >> helping the most advanced users to grow into admins of Salsa etc.
> >> Right now we don't even have any kind of salsa-related discussion
> >> list on lists.debian.org. Thus I wanted to raise discussion on
> >> debian-devel. In my opinion Salsa is becoming a very central piece of
> >> the Debian infrastructure and it should have more attention on
> >> debian-devel and from the project leader.
> 
> > We are working on it and after my holidays are over I will plan
> > another sprint for improving salsa.
> 
> >From your replies to emails in this thread I was wondering: do you mean
> that the Salsa team does not need, or does not want, help? Or does not
> need, or want, help outside of a sprint?
That basically means: yes we probably need help. But it also means that
getting help should be done in a coordinated way, like introducing one or two
team members during a sprint. Getting someone new involved always means
overhead and should happen when there is time for such overhead. In my
experience sprints are ideal for it. I also talked to some people about
getting them involved in salsa, but there will also be a call for help. 

I / we plan to add at least one global admin and maybe one or two assistants
that help with "user" support. 

We just need some time to plan and coordinate those things (around christmas
is really a bad timing for such discussions)

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Ulrike Uhlig]

Hi formorer,

> On 28.12.19 18:16, Alexander Wirt wrote:
>> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
>> I am sure there are many ways to help the team and it is not just
>> about Salsa/Gitlab admin stuff, but also about creating structure in
>> the team, triaging issues, spreading best practices for users and
>> helping the most advanced users to grow into admins of Salsa etc.
>> Right now we don't even have any kind of salsa-related discussion
>> list on lists.debian.org. Thus I wanted to raise discussion on
>> debian-devel. In my opinion Salsa is becoming a very central piece of
>> the Debian infrastructure and it should have more attention on
>> debian-devel and from the project leader.

> We are working on it and after my holidays are over I will plan
> another sprint for improving salsa.

>From your replies to emails in this thread I was wondering: do you mean
that the Salsa team does not need, or does not want, help? Or does not
need, or want, help outside of a sprint?

 -- ulrike

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 06 Jan 2020, Sam Hartman wrote:

> > "Alexander" == Alexander Wirt  writes:
> 
> Alexander> For everything else: we are working on it. 
> 
> I just want to confirm that part of the things that you are working on
> is documenting the issues.  At a number of points you've talked about
> how people are misunderstanding the issues or are thinking it's simply
> more CPU etc.
> 
> That's all doubtless true.
> But part of being in a community is communicating with that community.
> People would almost certainly be more understanding if they had more
> information.
just for the record, I am doing all of this in my spare time and I prefer to
decide on my own what is in my queue and what the priority is. And yes, I do
prefer to fix things instead of documenting what needs to get fixed. 

And if everyone would behave sane instead of st* flame wars, insulting each
other and so on (it was a listmaster month to forget) my motivation to work
with that specific community would be a lot better. 

And for everyones sake: when announcing CI support we told everyone that the
ressources are limited and everyone should play nice with the CI. 

As often, other people decided to make the CI and the runners a quasi
standard, adding it to their workflows and so on. Now everyone is surprised
if things are as we always told everybody. What a surprise. 

Thanks for listening. 

Alex



signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Sam Hartman]

> "Alexander" == Alexander Wirt  writes:

Alexander> For everything else: we are working on it. 

I just want to confirm that part of the things that you are working on
is documenting the issues.  At a number of points you've talked about
how people are misunderstanding the issues or are thinking it's simply
more CPU etc.

That's all doubtless true.
But part of being in a community is communicating with that community.
People would almost certainly be more understanding if they had more
information.

Yes, that sort of communication does involve time, and yes that time
could be spent fixing things.
There comes a point though where the communication becomes at least as
important as the fix.

I think I've heard several requests for more information here, and I
just want to confirm that too is in your queue.


--Sam

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Wed, 01 Jan 2020, Otto Kekäläinen wrote:

> Hello!
> 
> ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> > On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > > Also, if resources are an issue: I've offered several times to see if I
> > > can get some k8s resources for gitlab runners, but never got a reply.
> > > Not even a no.
> > It is not a problem on the runner side.
> >
> > And as said, we are working on the other problems until we can improve
> > something in that part.
> 
> If it is not a problem on the runner side and you don't need more
> runner resources, what is the reason the runner is capped at 1h?
> MariaDB is a huge beast and building it and running all tests take
> 1,5h for completely valid reasons (also note we have ccache on
> Salsa-CI so re-builds are much faster).
We updated the timeout to three hours. However, if that leads to problems on
salsa side we will have to set it back. So please ensure not to create too
much load / jobs that use that extended limit. 

For everything else: we are working on it. 

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Otto Kekäläinen]

Hello!

ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > Also, if resources are an issue: I've offered several times to see if I
> > can get some k8s resources for gitlab runners, but never got a reply.
> > Not even a no.
> It is not a problem on the runner side.
>
> And as said, we are working on the other problems until we can improve
> something in that part.

If it is not a problem on the runner side and you don't need more
runner resources, what is the reason the runner is capped at 1h?
MariaDB is a huge beast and building it and running all tests take
1,5h for completely valid reasons (also note we have ccache on
Salsa-CI so re-builds are much faster).

Could you be kind at set back the default runner time limit to 2h as
it was some weeks ago?
This is stopping me and our contributors from working on putting
mariadb-10.4 in Debian.

It you don't intend to revert the change back to how it was?

Or could you please at least state the reasons at
https://salsa.debian.org/salsa/support/issues/184 ? So far you have
not commented anything in your own bug tracker at salsa/support..

Thanks again for everybody maintaining and developing Salsa, the CI
and all that comes with them. That has been a huge boost in my
motivation to continue Debian work and makes me much more productive
than ever before.


- Otto

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 30 Dec 2019, Bernd Zeimetz wrote:

> 
> 
> On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> > I don't think that salsa-ci is particularly problematic in terms of
> > "efficiency". With the exception of the LXC usage, there's not much
> > that can be "cut" to save resources.
> 
> Also, if resources are an issue: I've offered several times to see if I
> can get some k8s resources for gitlab runners, but never got a reply.
> Not even a no.
It is not a problem on the runner side. 
 
And as said, we are working on the other problems until we can improve
something in that part. 

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Bernd Zeimetz]

On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> I don't think that salsa-ci is particularly problematic in terms of
> "efficiency". With the exception of the LXC usage, there's not much
> that can be "cut" to save resources.

Also, if resources are an issue: I've offered several times to see if I
can get some k8s resources for gitlab runners, but never got a reply.
Not even a no.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 30 Dec 2019, Raphael Hertzog wrote:

> On Sat, 28 Dec 2019, Alexander Wirt wrote:
> > On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> > 
> > > Hello!
> > > 
> > > I've seen many times before statements like these so I'd like to raise
> > > some discussion around the topic:
> > > 
> > > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > > > The Salsa CA pipeline is recommended.
> > > >
> > > > For this I need to use my veto as Salsa admin.  With the CI people we
> > > > have to work through too much problems first.
> > The salsa ci pipeline itself has some problematic implementation details
> > waldi lined out in the past. Afaik nothing changed, we had several reports
> 
> This is not really true:
> https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all=%E2%9C%93=opened_username=waldi
> 
> Out of 12 issues reported by waldi, 8 have been fixed/closed.
> 
> Among the remaining ones:
> 
> - https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
>   (usage of LXC for autopkgtest)
>   is likely the most problematic one even though you never explained
>   what's the real issue... yeah it's virtualization over virtualization
>   and it downloads a root tarball to do its work, but is this worth than
>   downloading a docker image? It uses more resources than direct execution
>   of autopkgtest but it hasn't broken anything so far?
that second level of virtualisation caused problems where people told us they
are not able to do things in their ci jobs. 

*snip*

> > where people telling us things are not possible on our runners. In the end
> > most of them turned out to be limitations of salsa ci. Salsa ci is also
> > not very efficent, therefore the veto. 
> 
> Claims like "salsa ci is not very efficient" are not actionable. Bugs like
> those above are more useful but you should at least take the time to
> respond to queries of people, otherwise no progress can be made.
> 
> I don't think that salsa-ci is particularly problematic in terms of
> "efficiency". With the exception of the LXC usage, there's not much
> that can be "cut" to save resources.
Thats probably true, but if it is inefficent and may cause problems on our
current architecture / ressources - that can't get fixed easily - a veto is
the only thing we have. 

> > We are working on it and after my holidays are over I will plan another
> > sprint for improving salsa. 
> 
> \o/

Alex - forgive the shortness, I am on vacation


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Raphael Hertzog]

On Sat, 28 Dec 2019, Alexander Wirt wrote:
> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> 
> > Hello!
> > 
> > I've seen many times before statements like these so I'd like to raise
> > some discussion around the topic:
> > 
> > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > > The Salsa CA pipeline is recommended.
> > >
> > > For this I need to use my veto as Salsa admin.  With the CI people we
> > > have to work through too much problems first.
> The salsa ci pipeline itself has some problematic implementation details
> waldi lined out in the past. Afaik nothing changed, we had several reports

This is not really true:
https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all=%E2%9C%93=opened_username=waldi

Out of 12 issues reported by waldi, 8 have been fixed/closed.

Among the remaining ones:

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
  (usage of LXC for autopkgtest)
  is likely the most problematic one even though you never explained
  what's the real issue... yeah it's virtualization over virtualization
  and it downloads a root tarball to do its work, but is this worth than
  downloading a docker image? It uses more resources than direct execution
  of autopkgtest but it hasn't broken anything so far?

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/94
  (docker images accumulating in forks)
  this one should have improved a lot AFAIK as GitLab now supports what's
  required to remove images from the CI environment too and there's
  WIP on that front (it might even be live without anyone updating that
  bug, I'm not sure)

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/116
  This one is not clear to me. What jobs are using "docker-in-docker"
  without any legitimate use ?

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/121
  (split into source and build)
  This one seems like wishlist and has no real impact on resources as long
  as we build for a single architecture...

> where people telling us things are not possible on our runners. In the end
> most of them turned out to be limitations of salsa ci. Salsa ci is also
> not very efficent, therefore the veto. 

Claims like "salsa ci is not very efficient" are not actionable. Bugs like
those above are more useful but you should at least take the time to
respond to queries of people, otherwise no progress can be made.

I don't think that salsa-ci is particularly problematic in terms of
"efficiency". With the exception of the LXC usage, there's not much
that can be "cut" to save resources.

> We are working on it and after my holidays are over I will plan another
> sprint for improving salsa. 

\o/

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Thu, 26 Dec 2019, Otto Kekäläinen wrote:

> Hello!
> 
> I've seen many times before statements like these so I'd like to raise
> some discussion around the topic:
> 
> pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > The Salsa CA pipeline is recommended.
> >
> > For this I need to use my veto as Salsa admin.  With the CI people we
> > have to work through too much problems first.
The salsa ci pipeline itself has some problematic implementation details
waldi lined out in the past. Afaik nothing changed, we had several reports
where people telling us things are not possible on our runners. In the end
most of them turned out to be limitations of salsa ci. Salsa ci is also
not very efficent, therefore the veto. 

> There seems to be a conflict between the Salsa admins and users of
> Salsa: the more Salsa is used, the bigger becomes the maintenance
> burden and the more computing resources Salsa needs. There is however
> no inherent growth feedback loop in the system that would increase
> maintenance commitments as usage commitments grow. In economic terms
> one could say that the Salsa admins don't profit from maintaining
> Salsa and as demand grows there is nothing that grows the supply at
> the moment.
> 
> The reason for Salsa popularity to grow all the time is simply because
> it is such a brilliant service and many Debian Developers and aspiring
> new contributors love to use it. Personally I've had all my packages
> on Salsa since early 2018 and I would never want to go back to the mix
> of Github and Alioth I used before. Using Gitlab-CI is nowadays an
> inherent part of my packaging workflow to test contributions before
> merging them and to do QA before uploads. Any disruptions to Salsa
> basically grinds by packaging work to a halt[1], it is so central for
> me nowadays.
> 
> Since Salsa was officially launched in 2018 there has not been any [2]
> new members to the Salsa admins group [3]. Alexander, Joerg and
> Bastian have done a great job maintaining our Gitlab installation. The
> software suite is a beast and keeping it running well is a major
> effort in itself.
> 
> They need help going forward. The sentiment of restricting vital use
> of Salsa is a sign of them trying to keep things under control. But
> Salsa usage needs to grow, as that is good for Debian as a project.
> For the Debian project I think it would be a priority to find more
> resources to the Salsa admin team. I think that would be the ultimate
> solution to the current conflict.
For more performane salsa would need a proper redesign by moving it from its
monolithic system to a more distributed system. In fact we are already
talking about it for some time. But in fact you - the users - should not
think that everything is as easy as just adding some cpus, disks or workers.
Things are often more complicated and - in the end - everything should be
maintainable by DSA too. 

> Personally I cannot commit to maintain Salsa, unfortunately. If Salsa
> is out of computing resources I can however help find more sponsors
> for public runners. But I have the understanding that Google has
> donated plenty of cloud computing time and the root cause is not in
> lack of computing resources, but in the human scalability aspects of
> Salsa operations.
in fact thats only partially true. 

We are working on it and after my holidays are over I will plan another
sprint for improving salsa. 

Things are not always as easy as it seems.

Alex


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Raphael Hertzog]

On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> I am sure there are many ways to help the team and it is not just
> about Salsa/Gitlab admin stuff, but also about creating structure in
> the team, triaging issues, spreading best practices for users and
> helping the most advanced users to grow into admins of Salsa etc.
> Right now we don't even have any kind of salsa-related discussion list
> on lists.debian.org. Thus I wanted to raise discussion on
> debian-devel. In my opinion Salsa is becoming a very central piece of
> the Debian infrastructure and it should have more attention on
> debian-devel and from the project leader.

+1 on everything you said. (And IMO you should have started a new thread
instead of replying to an old one)

I do hope we can find some constructive way to go forward because the current
settings are now too strict and are effectively hindering big packages
(exactly those that need help!) and some other advanced use of the
service.

I would also like to mention that we should have #salsa or #debian-salsa and
drop #alioth on IRC, sure it made sense at the start to continue to use
the same place as where we used to be but now it just makes it harder
to find the correct place to discuss issues with Salsa.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Otto Kekäläinen]

Hello!

I've seen many times before statements like these so I'd like to raise
some discussion around the topic:

pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > The Salsa CA pipeline is recommended.
>
> For this I need to use my veto as Salsa admin.  With the CI people we
> have to work through too much problems first.

There seems to be a conflict between the Salsa admins and users of
Salsa: the more Salsa is used, the bigger becomes the maintenance
burden and the more computing resources Salsa needs. There is however
no inherent growth feedback loop in the system that would increase
maintenance commitments as usage commitments grow. In economic terms
one could say that the Salsa admins don't profit from maintaining
Salsa and as demand grows there is nothing that grows the supply at
the moment.

The reason for Salsa popularity to grow all the time is simply because
it is such a brilliant service and many Debian Developers and aspiring
new contributors love to use it. Personally I've had all my packages
on Salsa since early 2018 and I would never want to go back to the mix
of Github and Alioth I used before. Using Gitlab-CI is nowadays an
inherent part of my packaging workflow to test contributions before
merging them and to do QA before uploads. Any disruptions to Salsa
basically grinds by packaging work to a halt[1], it is so central for
me nowadays.

Since Salsa was officially launched in 2018 there has not been any [2]
new members to the Salsa admins group [3]. Alexander, Joerg and
Bastian have done a great job maintaining our Gitlab installation. The
software suite is a beast and keeping it running well is a major
effort in itself.

They need help going forward. The sentiment of restricting vital use
of Salsa is a sign of them trying to keep things under control. But
Salsa usage needs to grow, as that is good for Debian as a project.
For the Debian project I think it would be a priority to find more
resources to the Salsa admin team. I think that would be the ultimate
solution to the current conflict.

Personally I cannot commit to maintain Salsa, unfortunately. If Salsa
is out of computing resources I can however help find more sponsors
for public runners. But I have the understanding that Google has
donated plenty of cloud computing time and the root cause is not in
lack of computing resources, but in the human scalability aspects of
Salsa operations.

I hope somebody else on the debian-devel list would respond to this
call for help.

I am sure there are many ways to help the team and it is not just
about Salsa/Gitlab admin stuff, but also about creating structure in
the team, triaging issues, spreading best practices for users and
helping the most advanced users to grow into admins of Salsa etc.
Right now we don't even have any kind of salsa-related discussion list
on lists.debian.org. Thus I wanted to raise discussion on
debian-devel. In my opinion Salsa is becoming a very central piece of
the Debian infrastructure and it should have more attention on
debian-devel and from the project leader.

Thanks again for current Salsa admins for the work you've done! Salsa
is amazing and I hope it will get broader attention and help so it
scales to support our packaging work far into the future.

[1] https://salsa.debian.org/salsa/support/issues/184
[2] https://wiki.debian.org/Salsa?action=diff=37=17
[3] https://wiki.debian.org/Salsa#Maintenance

Re: Help needed with a script generating a .deb (Done. Now what?)

[Andrey Rahmatullin]

On Tue, Jul 23, 2019 at 08:31:34PM +0200, dettus wrote:
> Now that I am able to create packages What do I do with them?
Read my link again.
Also, the packaging help list is debian-mentors@.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help needed with a script generating a .deb (Done. Now what?)

[dettus]

Hello.


So, I succeeded!

There are two Warnings left

W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt

If you do not mind, I would like to keep them. Now that I am able to
create packages What do I do with them?


Thomas


On 7/23/19 7:22 PM, Andrey Rahmatullin wrote:

On Tue, Jul 23, 2019 at 07:19:32PM +0200, dettus wrote:

Running it ends with  the following feedback:




dpkg-buildpackage: info: full upload (original source is included)
Now running lintian...
W: dmagnetic: missing-depends-line
W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: spelling-error-in-description allows to allows one to
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
W: dmagnetic: manpage-has-errors-from-man
usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined
W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
Finished running lintian.
Now signing changes and any dsc files...
  signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
gpg: skipped "Thomas Dettbarn ": No secret key
gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No
secret key
debsign: gpg error occurred!  Aborting
debuild: fatal error at line 1045:
running debsign failed
patching file Makefile


Any help with the warnings is appreciated...

You can use lintian-info to read the tag descriptions.

Re: Help needed with a script generating a .deb

[Andrey Rahmatullin]

On Tue, Jul 23, 2019 at 07:19:32PM +0200, dettus wrote:
> Running it ends with  the following feedback:
> 
> 
> 
> 
> dpkg-buildpackage: info: full upload (original source is included)
> Now running lintian...
> W: dmagnetic: missing-depends-line
> W: dmagnetic: description-synopsis-starts-with-article
> W: dmagnetic: spelling-error-in-description allows to allows one to
> W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
> W: dmagnetic: manpage-has-errors-from-man
> usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined
> W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
> Finished running lintian.
> Now signing changes and any dsc files...
>  signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
> gpg: skipped "Thomas Dettbarn ": No secret key
> gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No
> secret key
> debsign: gpg error occurred!  Aborting
> debuild: fatal error at line 1045:
> running debsign failed
> patching file Makefile
> 
> 
> Any help with the warnings is appreciated...
You can use lintian-info to read the tag descriptions.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help needed with a script generating a .deb

[dettus]

Hello all.


Thanks to your input, I think I am getting closer.
For debian, I created a repository at 
https://github.com/dettus/ports_and_packages/tree/master/Debian



In it, you will find a debian/ subdirectory. In which I put the files 
that seem to be required for

debuild, if I am not mistaken?


You will also find a script called "mkpackage.sh". It takes care of 
downloading the source file

from my website, and creating the .dsc file.

Running it ends with  the following feedback:




dpkg-buildpackage: info: full upload (original source is included)
Now running lintian...
W: dmagnetic: missing-depends-line
W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: spelling-error-in-description allows to allows one to
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
W: dmagnetic: manpage-has-errors-from-man 
usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined

W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
Finished running lintian.
Now signing changes and any dsc files...
 signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
gpg: skipped "Thomas Dettbarn ": No secret key
gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No 
secret key

debsign: gpg error occurred!  Aborting
debuild: fatal error at line 1045:
running debsign failed
patching file Makefile


Any help with the warnings is appreciated...



Thomas

On 7/23/19 12:26 PM, Ricardo Mones wrote:

Hi Thomas,

On Tue, Jul 23, 2019 at 11:25:40AM +0200, Thomas Dettbarn wrote:

Hello!

So, I have this awesome project, that I am trying to get into the
package repository of Debian. I already filed an RFP, which can be
found at the WNPP bug tracker, where it is gathering dust.

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

So, I tried my hand at creating a package myself. Since I am a very
lazy person, I try to script my work whenever possible. So why should
there be an exception for the Debian package generation, right? 

[…]

Right, but Debian requirements for those scripts and the environment
where they run are much tighter than yours.

I'd suggest you should start reading https://wiki.debian.org/Packaging
and it's linked pages and perhaps see some examples of current existing
packages in https://salsa.debian.org.

HTH,

Re: Help needed with a script generating a .deb

[Shlomi Fish]

Hi Thomas!

On Tue, 23 Jul 2019 11:25:40 +0200 (CEST)
Thomas Dettbarn  wrote:

> Hello!
> 
> So, I have this awesome project, that I am trying to get into the
> package repository of Debian. I already filed an RFP, which can be
> found at the WNPP bug tracker, where it is gathering dust.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929619
> 
> So, I tried my hand at creating a package myself. Since I am a very
> lazy person, I try to script my work whenever possible. So why should
> there be an exception for the Debian package generation, right? 
> 
> Anyways, the script that is downloading my project, compiles it, and
> creates a .deb file can be found attached to this email, but you can
> also download it at github, at 
> 
> 
> https://github.com/dettus/ports_and_packages/blob/master/Ubuntu/games/dmagnetic/mkpackage.sh
> 

du gives an error, see
https://www.shlomifish.org/Files/files/images/Screenshot_20190723_130648.webp
.

Perhaps use "set -e -x" (or python/etc.). Did you try
https://lintian.debian.org/ yet?


> (Yes, currently I am sitting at a Ubuntu Machine (At work), but I would still
> like to see my project become part of Debian)
> 
> If you could have a look, and tell me what I might have missed, I would very
> VERY much appreciate it.
> 
> Oh, my project is located at http://www.dettus.net/dMagnetic, it is called
> dMagnetic- A Magnetic Scrolls Interpreter, and can be used to play classic
> text adventures such as "The Guild of Thieves" on modern Hardware in any
> terminal window. The graphics are being rendered in ANSI art.
> 
> 
> Thomas Dettbarn



-- 
-
Shlomi Fish   http://www.shlomifish.org/
Funny Anti-Terrorism Story - http://shlom.in/enemy

Doing linear scans over an associative array is like trying to club someone to
death with a loaded Uzi. — Larry Wall

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: Help needed with a script generating a .deb

[Andrey Rahmatullin]

We don't use dpkg-deb -b to create packages.

If you want to create a package that can be uploaded to Debian, start with
https://mentors.debian.net/intro-maintainers

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Help needed with a script generating a .deb

[Thomas Dettbarn]

Hello!

So, I have this awesome project, that I am trying to get into the
package repository of Debian. I already filed an RFP, which can be
found at the WNPP bug tracker, where it is gathering dust.

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

So, I tried my hand at creating a package myself. Since I am a very
lazy person, I try to script my work whenever possible. So why should
there be an exception for the Debian package generation, right? 

Anyways, the script that is downloading my project, compiles it, and
creates a .deb file can be found attached to this email, but you can
also download it at github, at 


https://github.com/dettus/ports_and_packages/blob/master/Ubuntu/games/dmagnetic/mkpackage.sh

(Yes, currently I am sitting at a Ubuntu Machine (At work), but I would still
like to see my project become part of Debian)

If you could have a look, and tell me what I might have missed, I would very
VERY much appreciate it.

Oh, my project is located at http://www.dettus.net/dMagnetic, it is called
dMagnetic- A Magnetic Scrolls Interpreter, and can be used to play classic
text adventures such as "The Guild of Thieves" on modern Hardware in any
terminal window. The graphics are being rendered in ANSI art.


Thomas Dettbarn

dmagnetic_to_deb.sh
Description: application/shellscript

Re: Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

[Alex Mestiashvili]

On Tue, Sep 5, 2017 at 8:44 PM, Jeff Epler  wrote:

> On Tue, Sep 05, 2017 at 01:55:58PM +0200, Alex Mestiashvili wrote:
> > GHash.hh:91:44: error: type/value mismatch at argument 1 in template
> > parameter list for 'template struct std::hash'
> >  while (pos
> Nothing in this line is intended to be a template parameter list, but it
> looks like gcc has decided something is; maybe it's "hash", which the
> compiler treats as std::hash due to e.g., an earlier "using" statement.
>
> If so, consider trying
>while (pos^ parenthesize ^
> so that the "<" can't introduce a template parameter list.
>
> My mental model of the C++ grammar doesn't explain to me why the
> compiler thinks this "<" can introduce a template parameter list, but
> that sure seems to be what the compiler states it is doing.  Usually
> when g++ and I disagree about C++ grammar, g++ is right...
>
> Jeff
>

Great! this solved the problem. Thank you very much!

Alex

Re: Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

[Jeff Epler]

On Tue, Sep 05, 2017 at 01:55:58PM +0200, Alex Mestiashvili wrote:
> GHash.hh:91:44: error: type/value mismatch at argument 1 in template
> parameter list for 'template struct std::hash'
>  while (pos

Re: Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

[Juhani Numminen]

Hi Alex!

Alex Mestiashvili kirjoitti 05.09.2017 klo 14:55:

parameter list for 'template struct std::hash'
  while (pos
I think the problem is we don't want std::hash but GHash::hash and
GHash::GHashEntry::hash.
(Sorry, I haven't looked deeper into how to get the correct 'hash'.)

Cheers,
Juhani

Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

[Alex Mestiashvili]

Any help is greatly appreciated,
here it the gcc's complain:

In file included from gff.h:12:0,
 from gtf_tracking.h:12,
 from bundles.h:22,
 from replicates.h:10,
 from common.cpp:28:
GHash.hh: In member function 'GHash::GHashEntry*
GHash::NextEntry()':
GHash.hh:91:44: error: type/value mismatch at argument 1 in template
parameter list for 'template struct std::hash'
 while (pos

Re: Help needed talking to upstream browser developers about Debian SSO

[Simon Richter]

Hi,

On 15.10.2015 22:04, Olaf Titz wrote:

> Why that way? Reading an argument that the browser is "secure
> infrastructure" and "audited code" makes me shudder (sorry).

There is a standard for security modules, which can be dedicated
hardware, or the fallback "software security module". These have been
audited, and the interface is designed so that it can be implemented
securely.

The interface standard specifies that the security module is responsible
for key generation, because in the case of a hardware module, there is
no way the key could be generated anywhere else; the generated key then
takes up a key slot on the device, a certificate signing request for
that key can be generated from that, and once the certificate is
created, it can be stored to a certificate slot in the security module.

The main problem Mozilla has with this approach is that they never had a
proper user interface for key management, so key slots are invisible to
the user, and the UI presents keys as part of the user's certificates --
so specifically keys cannot be deleted or retained independently.

The current API to interface the security module from HTML/HTTP consists of

1. a nonstandard HTML tag that resolves to a form element,
2. an implicit convention that keys generated during form submission are
retained in the security module, even if inaccessible otherwise
3. a MIME handler that handles incoming certificates by searching the
certificate storage for a matching key, storing the certificate in a
certificate slot, and binding the key slot to the certificate slot.

This is basically a good implementation, as it does not require any
scripting to work, is easy to use and difficult to get wrong, but it is
a crude hack nonetheless, and I can see the desire to get rid of it.

The question is what will replace it.

Exposing the security module interface to JavaScript could work, as it
would allow a more sophisticated UI to be developed outside the secure
core; but that still introduces a new dependency on JavaScript.

Wrapping the security module interface to present an interface similar
to the certificate management dialog would *not* work, because it breaks
smartcards and really any enrollment process where the key material is
hidden from the user interface, as it should be in a well-defined system.

I could certainly see gpg-agent providing a security module at some
point, allowing reuse of OpenPGP keys as X.509 keys or vice versa, and
generally unifying key handling in a single place.

> I'd rather
> prefer a specialized app for that purpose, which is small, self-contained
> and _can_ be audited.

As said, that already exists. This app does not even do any parsing of
the command line or files, but expects to be given input in an easily
verifiable format that can be verified on the fly by a generated parser,
further minimizing potential for errors. Fully functional
implementations of this self-contained module exist on smartcards.

> Not another key-generation-bug or
> insertion-of-malicious-javascript disaster waiting around the corner (for
> the latter reason, nobody should ever do key generation via a web page which
> requires Javascript, anyway!)

That is precisely our concern. The current implementation is a nasty
hack, but it does allow key generation without JavaScript, and
integrates smartcards.

The entire reason we're having this debate is that it would be bad to
lose existing functionality as people may have come to depend on it; on
the other hand, it would be good to have a standard that is not
implementation dependent, and ideally allows better control over key
storage, for example integrating the Windows and MacOS integrated key
stores.

   Simon




signature.asc
Description: OpenPGP digital signature

Re: Help needed talking to upstream browser developers about Debian SSO

[Thijs Kinkhorst]

Hi Enrico,

On Sun, October 11, 2015 20:50, Enrico Zini wrote:
> However, there is discussion in the Chrome[5] and Mozilla[6] communities
> about deprecating client certificate authentication. In those threads,
>

> I don't quite mind if  is removed, as long as there would be a
> replacement that allows the existence and growth of an ecosystem with
> shared identification, based on popular standards and easy to use and
> deploy.

Thanks for the heads-up. Debian is most certainly not the only one to use
client certificates for (Single) Sign On so keeping client certificates
usable is important.

Reading the threads you link, however, those indeed seem to be centered
around removal of the "" tag, not deprecating the entire X.509
client certificate support of browsers. Basically, the point is that
enrolment should be done differently.

While we make use of that tag (e.g. in the TERENA Personal Certificate
Service that some academics may know), the browser developers may have a
point that there are other ways to implement the enrolment step. People
can generate a certificate locally with openssl or other tools, through
HTML5 or JS.

The current  tag is convenient (as it requires 8 bytes to
implement browser based certificate generation), but I'd have to
investigate these other options to see whether they are viable. I can't
conclude right now that they are unreasonable for suggesting that.
Especially for tech-savvy use cases the in-browser generation should not
be essential. So I'm not sure that Debian would have a strong point in
this discussion.

I'm emailing to check if indeed you're referring only to removal of the
 tag, not the entire X.509 client certificate support from
browsers. If the latter discussions are happening, I'd love a link to
those.


Cheers,
Thijs

Re: Help needed talking to upstream browser developers about Debian SSO

[Olaf Titz]

> From what I've gathered, they want to deprecate storing private keys
> without associated certificates, which would be really bad. There is an
> audited infrastructure for key generation and storage, including
> smartcard support, and adding a requirement that keys may only be added
> together with a certificate would lead to a situation where I'd have to
> generate a private key outside the secure infrastructure and keep it
> outside until my certificate is ready, at which point I can finally
> transfer it to the audited code for safekeeping.

Let's look at this use-case the other way around. What is missing is a
simple enrollment application which does noting but
- (optionally) obtain policy parameters from a CA[1]
- generate a private key 
- generating a cert request
- submit that cert request to the CA[2]
- package a received cert along with the private key into a PKCS12 container
Steps [1] and [2] would need a standardized protocol (not HTML forms).

Why that way? Reading an argument that the browser is "secure
infrastructure" and "audited code" makes me shudder (sorry).  I'd rather
prefer a specialized app for that purpose, which is small, self-contained
and _can_ be audited.  Not another key-generation-bug or
insertion-of-malicious-javascript disaster waiting around the corner (for
the latter reason, nobody should ever do key generation via a web page which
requires Javascript, anyway!)

So while not knowing the whole discussion at all, I can very easily see a
security argument for deprecating browser-based key generation.  The
downside is that it does need a new application which (to my knowledge)
isn't there already.  But the building blocks are there (I once wrote a
self-signed-certificate generator, took me at most 20 lines of Java plus
another 100 or so lines for the GUI).

Olaf

Re: Help needed talking to upstream browser developers about Debian SSO

[Simon Richter]

Hi,

On 15.10.2015 18:08, Thijs Kinkhorst wrote:

> While we make use of that tag (e.g. in the TERENA Personal Certificate
> Service that some academics may know), the browser developers may have a
> point that there are other ways to implement the enrolment step. People
> can generate a certificate locally with openssl or other tools, through
> HTML5 or JS.

I've posted a statement to the list, but it got stuck in moderation.
Basically, the main difficulty is that any enrollment process would need
to be simple for users to follow, ideally not require additional
software even on Windows, and not require security compromises.

From what I've gathered, they want to deprecate storing private keys
without associated certificates, which would be really bad. There is an
audited infrastructure for key generation and storage, including
smartcard support, and adding a requirement that keys may only be added
together with a certificate would lead to a situation where I'd have to
generate a private key outside the secure infrastructure and keep it
outside until my certificate is ready, at which point I can finally
transfer it to the audited code for safekeeping.

This would also mean that key generation would have to happen outside
the audited code. This opens a lot of potential to get things wrong
somewhere and compromise system security because of it.

If I can continue to generate a key inside the crypto module and leave
it there until a certificate becomes available to attach it to, I don't
see a huge problem with deprecating the existing API, given that it is
browser specific anyway (although this introduces JavaScript as an
additional dependency into the enrollment process, where we had no need
for a Turing-complete language before).

> Especially for tech-savvy use cases the in-browser generation should not
> be essential. So I'm not sure that Debian would have a strong point in
> this discussion.

Neither Debian's users nor non-packaging contributors are necessarily
tech-savvy -- and I don't think knowledge of the intricacies of OpenSSL
should be a requirement either, so I think this weakens our position much.

> I'm emailing to check if indeed you're referring only to removal of the
>  tag, not the entire X.509 client certificate support from
> browsers. If the latter discussions are happening, I'd love a link to
> those.

I'm not sure there is much discussion going on at all, at least I can't
see it in their public archives.

For your delectation and amusement, I've attached the mail I sent.

   Simon

--- Begin Message ---
Hi,

sorry for warming up this topic, I've just been pointed here.

Am Donnerstag, 30. Juli 2015 01:35:49 UTC+2 schrieb David Keeler:

> Ryan Sleevi recently announced the pre-intention to deprecate and
> eventually remove support for the  element and special-case
> handling of the application/x-x509-*-cert MIME types from the blink
> platform (i.e. Chrome).

[...]

> I therefore propose we follow suit and begin the process of deprecating
> and removing these features. The intention of this post is to begin a
> discussion to determine the feasibility of doing so.

A common setup I build for small companies and organizations uses a
simple local CA and a web page containing a form with a  and a
password. Enrollment works by

1. Phone call or physical presence of applicant, CA administrator
authenticates applicant.
2. Administrator starts enrollment process, one time password in
generated and given to applicant
3. Applicant uses the  and the one time password to send a
signing request to the CA server
4. CA server replies with new client certificate

For simple setups, this is a really easy way to deploy certificates --
really, the hardest part is copying the certificate from Firefox to
Thunderbird if it is to be used for SMTP relay authentication as well.

Removing  obviously breaks this workflow, but I think it can be
replaced with JavaScript -- this adds an extra step for organizations
that do not enable JS by default, but I think that would be manageable.

In any case, however the key store would still need to be able to store
keys that are not associated with a certificate yet, or we're losing key
generation capability completely (well, theoretically we could generate
keys in JS and keep the private key material in DOM storage until the
certificate is ready, but I doubt anyone wants that).

Is there still an API left that allows me to easily deploy client
certificates in such a setting?

   Simon



signature.asc
Description: OpenPGP digital signature
--- End Message ---


signature.asc
Description: OpenPGP digital signature

Help needed talking to upstream browser developers about Debian SSO

[Enrico Zini]

Hello,

I need help to make our SSO use case for client certificates known in
the upstream browser development communities. Here is the story.

At DebConf we deployed a new experimental single signon system based on
ssl client certificates[1], and it works quite nicely. In particular, it
allows anyone to create services that authenticate Debian people, with
just a few web server configuration lines[2]. I am now aware of any
other single sign-on system that has this combination of simplicity,
security and usability.

There are still a few things that could be better, and I was kind of
dreaming that we could build from here[3], just as we recently did a lot
of work to ensure that lots of browsers in Debian could work with client
certificates[4].

However, there is discussion in the Chrome[5] and Mozilla[6] communities
about deprecating client certificate authentication. In those threads,
vocal people in support of Client Certificates argued mostly for WebID
and seem to have managed to completely alienate the Chrome developers.
Other use cases, including ours, were not really represented.

My understanding so far is that client certs seem to be better than
anything else (one enrollment step, and sites that want to use the auth
just add the CA cert and CRL to the web browser configuration).

I don't quite mind if  is removed, as long as there would be a
replacement that allows the existence and growth of an ecosystem with
shared identification, based on popular standards and easy to use and
deploy.

FIDO and crypto APIs are mentioned as alternatives which do not seem to
be there yet. I appreciate that the Chrome people have said that they
intend to wait for an alternative to be viable before removing keygen,
although I would want to be sure that they are aware of our use case.

I dream of a low-maintenance, established technology that allows a
community to set up a central authentication place, and then let a
decentralised network of web services grow around that.

Client Certificates allow to do that today: it is easy to have a central
place authenticating users and enrolling devices, and it is easy to
accept and trust those certificates without having to coordinate with
the issuing site.

I wish that this use case would be explicitly supported. I was happy to
see existing, established standards for it.

Unfortunately I do not have the time and energy to actively participate
in those discussions, so I'm asking for help.

To me, sso.debian.org is a side project that I'm working on to support
the sites I actually care about: nm.debian.org and
contributors.debian.org.

So far I have maintained server-side code and patched client software,
and now the next step would be to carefully negotiate with upstreams to
figure out what can be the future of sso.debian.org. I am losing
motivation, because despite all this work, the things I care about are
really not progressing.

This is a call for help: please help making sure that there are standard
ways for mere mortals to setup and maintain central authentication
services for their community.

I would appreciate being able to just focus on nm.debian.org and
contributors.debian.org knowing that I somehow have my back covered on
the sign-on side.

I see a few things that could be done:

 - participate in those discussions constructively, being a rational
   voice showing why and how we use client certificates in
   sso.debian.org and discussing with the browser communities what could
   be concrete futures for it.

   Talking with Chrome developers seems to require a Google account;
   talking with the Mozilla developers does not:

  https://www.mozilla.org/en-US/about/forums/#dev-security
  https://www.mozilla.org/en-US/about/forums/#dev-platform

 - package and publish django-spkac[7] on a popular platform like GitHub
   and https://www.djangopackages.com/, with a README somehow explaining
   the vision and few steps[8] for deploying Single Sign-On for a
   tech-savvy decentralised ecosystem like ours, and show it as an
   example of our use case.

I want sso.debian.org to grow without me. You may have time, energy,
expertise, further and better ideas: by all means go ahead with them.

Thank you in advance,


Enrico

[1] https://wiki.debian.org/DebianSingleSignOn
[2] 
https://wiki.debian.org/DebianSingleSignOn#Documentation_for_web_application_owners
[3] http://www.enricozini.org/2015/debian/if-you-know-a-browser-developer/
[4] https://wiki.debian.org/DebianSingleSignOn#Browser_support
[5] https://groups.google.com/forum/#!topic/mozilla.dev.security/mr_DoJGOoiA
[6] 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ
[7] http://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/spkac
[8] 
http://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/README-spkac.md
-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Help needed to maintain wordpress

[Raphael Hertzog]

[ Bcc debian-devel to make the offer both to new maintainers and experienced 
ones ]

Hello,

I would like to find someone willing to take over the maintenance of
wordpress in Debian (the most popular software to run a blog).
The package is in a relatively good shape but it needs active maintenance
to keep up with new upstream releases and security updates.

One of the immediate challenge that I won't have the time to tackle is
that the Debian package has been providing translations in wordpress-l10n
for a long time already, but upstream just rolled out a new language
pack mechanism and we probably need to adapt debian/get-upstream-i18n
to use this new mechanism. Some PHP programming skills are required
for this task.

I have also left a debian/TODO with some more changes that we should
implement.

I will gladly sponsor uploads for non-DD.

Cheers,

PS: Giuseppe Iuculano is marked as the main maintainer but at least
for wordpress he's MIA. Giuseppe, do you intend to work again on
wordpress or shall you be removed from the maintainer field ?

PPS: I have just uploaded wordpress 3.7.1 but can't push to git.debian.org
currently since it's down. I have pushed a copy to
https://github.com/rhertzog/wordpress
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20131114103654.ga19...@x230-buxy.home.ouaza.com

help needed: dist-upgrade of quantz.debian.org

[Martin Zobel-Helas]

Hi,

i would like to dist-upgrade quantz.debian.org to wheezy this weekend.

It would be helpful if someone who knows the running cronjobs and
services on quantz.d.o could contact me either by mail or on IRC.

Cheers,
Martin
-- 
 Martin Zobel-Helas zo...@debian.orgDebian System Administrator
 Debian  GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


signature.asc
Description: Digital signature

Help needed to debug a failing bot on i18n.debian.org

[Christian PERRIER]

Hello fellow developers,

The i18n crowd needs your help.

In order to provide translators and teams with valuable material to
work, we have a few automated processes that are running on the
i18n.debian.org machine.

The source code for all this stuff is stored in
git+ssh://git.debian.org/git/debian-l10n/dl10n

One of these processes is failing since September 6th and people who
had a look at this up to now (me and David Prévot) can't debug it.

This process, cronned under the debian-i18n role on i18n.debian.org is
aimed at extracting all translatable material from the archive (either
from unstable, or testing, etc.) and stored it in a way that it can be
processed by other automated tasks (such as the one building i18n
stats pages on http://www.debian.org/intl/l10n).

The script that fails is named cron/gen-material in the git repo. It
uses a configuration file that is stored in etc/dl10n.conf, still in
the repo. It calls a Perl script named dl10n-check (stored in the root
of the git repo)...which is the one
apparently failing with errors like:

Unable to open 
/srv/mirrors/debian//pool/main/3/3depict/3depict_0.0.13-1.debian.tar.gz at 
/home/debian-i18n/dl10n-check line 463
read() on closed filehandle GEN5 at 
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 176.

Of course, the said file *is* there and this file is not even the
first one that is processed by the script. If I tweak the script to
ignore this package, it fails a bit later on another package, and so
on.

In short, it fails on *some* packagesand this is all we have. And
we're beyond our skills.

So, in short, we need fellow developers' help. Preferrably from people
who can access i18n.debian.org and work under the debian-i18n role in
order to test things as they are. In short, Debian developers who
would be granted that role(maybe the latter is not mandatory, dunno).

Is anyone willing to help us?

-- 




signature.asc
Description: Digital signature

Re: Help needed to debug a failing bot on i18n.debian.org

[Cyril Brulebois]

Christian PERRIER bubu...@debian.org (2013-09-30):
 So, in short, we need fellow developers' help. Preferrably from people
 who can access i18n.debian.org and work under the debian-i18n role in
 order to test things as they are. In short, Debian developers who
 would be granted that role(maybe the latter is not mandatory, dunno).
 
 Is anyone willing to help us?

Yes; debian-i18n membership ping.

Can't see the page on alioth due to:
  Permission denied. This project's administrator will have to grant you 
permission to view this page.

so can't request it myself. You should be able to add me from your end
though.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Help needed to debug a failing bot on i18n.debian.org

[Cyril Brulebois]

Cyril Brulebois k...@debian.org (2013-09-30):
 Yes; debian-i18n membership ping.
 
 Can't see the page on alioth due to:
   Permission denied. This project's administrator will have to grant you 
 permission to view this page.
 
 so can't request it myself. You should be able to add me from your end
 though.

Nevermind, that probably should go through rt.d.o (and it did).

Anyway, running the script against unstable, with the first patch
attached for debugging purposes, shows the package before 3depict is
0ad-data, which leads to an exec of xd which allocates a lot of
memory. I suspect memory issue handling is poor, and leads to the nasty
side effect we saw: an unrelated package gets blamed. The second (quick
and dirty) patch seems to work around that, and the script is still
running for now.

I guess fixing error handling and maybe getting some more memory should
be enough to get that part to work reliably.


I think I'll drop -devel@ from any further replies since the call for
help was answered, and people know where to follow the rest, should they
be interested.

Mraw,
KiBi.
From 94ea088fc1de135abe80e19eb11151ae95bba4c3 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois k...@debian.org
Date: Mon, 30 Sep 2013 22:17:39 +
Subject: [PATCH 1/2] dl10n-check: mention parsed $path,$pkg in parse_tarball

---
 dl10n-check |2 ++
 1 file changed, 2 insertions(+)

diff --git a/dl10n-check b/dl10n-check
index 4bad7a1..af38535 100755
--- a/dl10n-check
+++ b/dl10n-check
@@ -414,6 +414,8 @@ sub parse_tarball {
 $data-version($pkg, shift);
 $data-maintainer($pkg, shift);
 $data-upstream($pkg, debian);
+
+print STDERR Going to parse $path / $pkg\n;
  
 # Debian::Pkg::DebSrc-new() seem to have bad time when no / is in there.
 # A broken basename somewhere? FIXME properly
-- 
1.7.10.4

From ceabda4c9a2910a5f1b8768b9dc34db86a810b36 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois k...@debian.org
Date: Mon, 30 Sep 2013 22:19:24 +
Subject: [PATCH 2/2] dl10n-check: exclude 0ad-data, due to possible memory
 shortage and bad error handling

---
 dl10n-check |3 +++
 1 file changed, 3 insertions(+)

diff --git a/dl10n-check b/dl10n-check
index af38535..ae26261 100755
--- a/dl10n-check
+++ b/dl10n-check
@@ -462,6 +462,9 @@ sub parse_tarball {
 return -1 if $match($file);
 return 0;
 };
+# Avoid ENOMEM or similar?
+next
+if $path =~ /0ad-data/;
 my $deb = Debian::Pkg::DebSrc-new($path,
 parse_dft   = $match,
 patch_parse_dft = $match_patch,
-- 
1.7.10.4



signature.asc
Description: Digital signature

Re: Help needed to debug a failing bot on i18n.debian.org

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):
 Cyril Brulebois k...@debian.org (2013-09-30):
  Yes; debian-i18n membership ping.
  
  Can't see the page on alioth due to:
Permission denied. This project's administrator will have to grant you 
  permission to view this page.
  
  so can't request it myself. You should be able to add me from your end
  though.
 
 Nevermind, that probably should go through rt.d.o (and it did).
 
 Anyway, running the script against unstable, with the first patch
 attached for debugging purposes, shows the package before 3depict is
 0ad-data, which leads to an exec of xd which allocates a lot of
 memory. I suspect memory issue handling is poor, and leads to the nasty
 side effect we saw: an unrelated package gets blamed. The second (quick
 and dirty) patch seems to work around that, and the script is still
 running for now.
 
 I guess fixing error handling and maybe getting some more memory should
 be enough to get that part to work reliably.
 
 

top - 05:12:13 up 30 days, 16:06,  2 users,  load average: 0,06, 0,15, 0,19
Tasks: 103 total,   1 running, 102 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,0 us,  1,7 sy,  0,0 ni, 98,3 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   2061292 total,  1950408 used,   110884 free,   286504 buffers
KiB Swap:   524284 total,66436 used,   457848 free,   890868 cached

  PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND   


 2508 clamav20   0  398m 330m 5436 S   0,0 16,4 414:12.81 clamd 


So, it seems that:
- the virtual machine doesn't have that much memory (2GB)
- it doesnt have much swap
- clamd is eating a lot of memory

clamd seems to be running for 17 days, about a week after we started
to have some issues with statistics.

If I had root access to this machine, I would: 
- restart clamd
- add more swap
- eventually add more memory

Anyway, I applied your patch and we'll see what happens



signature.asc
Description: Digital signature

Re: tech-ctte help needed: main dependencies on non-free/contrib

[Ian Jackson]

Eugene V. Lyubimkin writes (Re: tech-ctte help needed: main dependencies on 
non-free/contrib):
 On 2012-07-17 10:35, Russ Allbery wrote:
  Could someone who has the time and the tools available do a check on all
  the dependencies in main for dependencies on non-free/contrib?  This
  information would be very helpful in evaluating tech-ctte bug #681419.  In
  particular: [...]
 
 I wrote a small program to list them, please find the (hopefully
 awk'able and hopefully correct) output in attachment.

Thanks a lot.

To turn this into an answer to Russ's questions:

  * How many total dependencies are there?  (We're only interested in
Depends or Recommends for this purpose, not Suggests.)

79.

  * Are all of those dependencies alternative dependencies of the form:
  
Depends: foo | foo-nonfree
  
or are there other cases?  A list of the other cases would be very
interesting.  (Some may just be bugs, but we may not have thought of
some other possible pattern.)

Reading your Depends as including Recommends, there is also:
Recommends/Depends: virtual-package
where virtual-package is provided both in main and outside, or
Recommends/Depends: something | virtual-package
likewise.  This is what you were proposing to change everything to.

In general the non-free packages don't have names that call them out,
so while your pattern says `foo-nonfree' in fact it's more like
`foo | forkle'.

We also have this:
  gscan2pdf: Recommends: 'cuneiform' [choice 1: cuneiform from non-free]
which looks like a bug, which I have filed.

And this:
  yagf: Depends: 'cuneiform | tesseract-ocr' [choice 1: cuneiform from non-free]
which is also a bug but a less serious one.

So in summary, excepting one clearly buggy package, the pattern you
give, and the pattern you are proposing to make universal, are the
only ones in existence.

  * Are any of these dependencies versioned?  One of the things we're
evaluating is whether it would always be possible to replace those
dependencies with a straight dependency on foo, with foo-nonfree
Providing foo.

No.  Only one of the entries in Eugene's list mentions a version
number and then only in an irrelevant limb of the dependency.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20488.4306.928079.549...@chiark.greenend.org.uk

Re: tech-ctte help needed: main dependencies on non-free/contrib

[Ivo De Decker]

Hi,

On Thu, Jul 19, 2012 at 02:51:14PM +0100, Ian Jackson wrote:
 We also have this:
   gscan2pdf: Recommends: 'cuneiform' [choice 1: cuneiform from non-free]
 which looks like a bug, which I have filed.

There's also these:

capi4hylafax: Recommends: 'isdnactivecards' [choice 1: isdnactivecards from 
contrib]
deutex: Recommends: 'doom-wad' [choice 1: doom-wad-shareware from non-free]
rt4-apache2: Recommends: 'libapache2-mod-fastcgi' [choice 1: 
libapache2-mod-fastcgi from non-free]
task-serbian: Recommends: 'opendict-plugins-lingvosoft' [choice 1: 
opendict-plugins-lingvosoft from contrib]

In all these cases, apt-get installs a package from non-free or contrib when
installing a package from main with non-free or contrib enabled. I have filed
bugs for these packages.

 And this:
   yagf: Depends: 'cuneiform | tesseract-ocr' [choice 1: cuneiform from 
 non-free]
 which is also a bug but a less serious one.

Why is this less serious? When you install yagf (with non-free enabled),
apt-get installs cuneiform, which is non-free.

Cheers,

Ivo


-- 
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/20120719180756.ge3...@ugent.be

Re: Bug#681419: tech-ctte help needed: main dependencies on non-free/contrib

[Ian Jackson]

Ivo De Decker writes (Bug#681419: tech-ctte help needed: main dependencies on 
non-free/contrib):
 There's also these:
 
 capi4hylafax: Recommends: 'isdnactivecards' [choice 1: isdnactivecards from 
 contrib]
 deutex: Recommends: 'doom-wad' [choice 1: doom-wad-shareware from non-free]
 rt4-apache2: Recommends: 'libapache2-mod-fastcgi' [choice 1: 
 libapache2-mod-fastcgi from non-free]
 task-serbian: Recommends: 'opendict-plugins-lingvosoft' [choice 1: 
 opendict-plugins-lingvosoft from contrib]
 
 In all these cases, apt-get installs a package from non-free or contrib when
 installing a package from main with non-free or contrib enabled. I have filed
 bugs for these packages.

Thanks.  I don't know how I missed those.

  And this:
yagf: Depends: 'cuneiform | tesseract-ocr' [choice 1: cuneiform from 
  non-free]
  which is also a bug but a less serious one.
 
 Why is this less serious? When you install yagf (with non-free enabled),
 apt-get installs cuneiform, which is non-free.

It's less serious because the package is installable without non-free
enabled, AFAICT.  (I have only read the output from the script, not
followed up with the Packages files.)

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20488.20570.924333.369...@chiark.greenend.org.uk

Re: tech-ctte help needed: main dependencies on non-free/contrib

[Russ Allbery]

Ivo De Decker ivo.dedec...@ugent.be writes:
 On Thu, Jul 19, 2012 at 02:51:14PM +0100, Ian Jackson wrote:

 And this:
   yagf: Depends: 'cuneiform | tesseract-ocr' [choice 1: cuneiform from 
 non-free]
 which is also a bug but a less serious one.

 Why is this less serious? When you install yagf (with non-free enabled),
 apt-get installs cuneiform, which is non-free.

It's less serious in that it's possible for the software to work without
non-free packages, which comes closer to satisfying the requirement in
Policy.  The trend of opinion in the tech-ctte at the moment, however, is
that it's still a bug if a package in main pulls in a package from
non-free by default when non-free is enabled.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/87629j7gr1@windlord.stanford.edu

tech-ctte help needed: main dependencies on non-free/contrib

[Russ Allbery]

Hello all,

Could someone who has the time and the tools available do a check on all
the dependencies in main for dependencies on non-free/contrib?  This
information would be very helpful in evaluating tech-ctte bug #681419.  In
particular:

* How many total dependencies are there?  (We're only interested in
  Depends or Recommends for this purpose, not Suggests.)

* Are all of those dependencies alternative dependencies of the form:

  Depends: foo | foo-nonfree

  or are there other cases?  A list of the other cases would be very
  interesting.  (Some may just be bugs, but we may not have thought of
  some other possible pattern.)

* Are any of these dependencies versioned?  One of the things we're
  evaluating is whether it would always be possible to replace those
  dependencies with a straight dependency on foo, with foo-nonfree
  Providing foo.

It would also be quite interesting, although much harder to determine,
whether there are any scenarios where such a dependency would result in a
non-free package being installed by default.  If, for example, there's a
dependency on foo | foo-nonfree and some packages conflict with foo but
not with foo-nonfree such that a dependency resolver may pull in
foo-nonfree in preference.

Thanks!

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/87zk6y9tq0@windlord.stanford.edu

Re: tech-ctte help needed: main dependencies on non-free/contrib

[Niels Thykier]

On 2012-07-17 19:35, Russ Allbery wrote:
 Hello all,
 
 [...]
 
 It would also be quite interesting, although much harder to determine,
 whether there are any scenarios where such a dependency would result in a
 non-free package being installed by default.  If, for example, there's a
 dependency on foo | foo-nonfree and some packages conflict with foo but
 not with foo-nonfree such that a dependency resolver may pull in
 foo-nonfree in preference.
 
 Thanks!
 


Hi,

I suspect installability checking of all packages should find them if
they are there.  One run with non-free+contrib and one without - the
newly uninstallable between the two runs should be set you are looking
for.  It does not catch issues like foo-nonfree | foo, but they would
be caught by your other query.

~Niels


-- 
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/5005a8eb.6020...@thykier.net

Re: tech-ctte help needed: main dependencies on non-free/contrib

[Ian Jackson]

Niels Thykier writes (Re: tech-ctte help needed: main dependencies on 
non-free/contrib):
 I suspect installability checking of all packages should find them if
 they are there.  One run with non-free+contrib and one without - the
 newly uninstallable between the two runs should be set you are looking
 for.  It does not catch issues like foo-nonfree | foo, but they would
 be caught by your other query.

Unless all the package managers always prefer to avoid installing from
non-free unless there is no other way to satisfy the user's request,
this is not a sufficient test.

In practice I think if we had installability bugs of the form you
suggest, in testing, people would notice.  Since those packages would
not be installable in testing at all.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20485.43851.604329.604...@chiark.greenend.org.uk

Re: tech-ctte help needed: main dependencies on non-free/contrib

[Jakub Wilk]

* Niels Thykier ni...@thykier.net, 2012-07-17, 20:03:
It would also be quite interesting, although much harder to determine, 
whether there are any scenarios where such a dependency would result 
in a non-free package being installed by default. If, for example, 
there's a dependency on foo | foo-nonfree and some packages conflict 
with foo but not with foo-nonfree such that a dependency resolver may 
pull in foo-nonfree in preference.

[...]
I suspect installability checking of all packages should find them if 
they are there.  One run with non-free+contrib and one without - the 
newly uninstallable between the two runs should be set you are 
looking for.


I played with dose-debcheck a bit. It turns out that (at least for i386) 
every currently uninstallable package in main is also uninstallable 
within main+contrib+non-free.


It does not catch issues like foo-nonfree | foo, but they would be 
caught by your other query.


That's right.

--
Jakub Wilk


--
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/20120717181448.ga6...@jwilk.net

Re: tech-ctte help needed: main dependencies on non-free/contrib

[Eugene V. Lyubimkin]

Hi,

On 2012-07-17 10:35, Russ Allbery wrote:
 Could someone who has the time and the tools available do a check on all
 the dependencies in main for dependencies on non-free/contrib?  This
 information would be very helpful in evaluating tech-ctte bug #681419.  In
 particular: [...]

I wrote a small program to list them, please find the (hopefully
awk'able and hopefully correct) output in attachment.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer
avahi-ui-utils: Recommends: 'vnc-viewer' [choice 3: tightvnc-java from contrib]
avahi-ui-utils: Recommends: 'vnc-viewer' [choice 4: vnc-java from contrib]
capi4hylafax: Recommends: 'isdnactivecards' [choice 1: isdnactivecards from 
contrib]
cl-sql: Recommends: 'cl-sql-backend' [choice 8: cl-sql-oracle from contrib]
cl-sql-uffi: Recommends: 'cl-sql-backend' [choice 8: cl-sql-oracle from contrib]
clam-networkeditor: Depends: 'libgl1-mesa-glx | libgl1 | fglrx-glx' [choice 3: 
fglrx-glx from non-free]
conky: Depends: 'conky-std | conky-cli | conky-all' [choice 3: conky-all from 
contrib]
deluge-common: Depends: 'geoip-database' [choice 2: geoip-database-contrib from 
contrib]
deutex: Recommends: 'doom-wad' [choice 1: doom-wad-shareware from non-free]
dsc-statistics-collector: Depends: 'geoip-database' [choice 2: 
geoip-database-contrib from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 12: 
festvox-don from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 13: 
festvox-en1 from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 14: 
festvox-us1 from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 15: 
festvox-us2 from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 16: 
festvox-us3 from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 17: 
festvox-rablpc16k from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 18: 
festvox-rablpc8k from contrib]
freeciv-client-sdl: Depends: 'fonts-ipafont-gothic | fonts-japanese-gothic | 
ttf-sazanami-gothic' [choice 5: fonts-ipafont-nonfree-jisx0208 from non-free]
fuse-emulator-common: Depends: 'opense-basic | spectrum-roms' [choice 2: 
spectrum-roms from non-free]
gdm3: Depends: 'gnome-session | x-session-manager | x-window-manager | 
x-terminal-emulator' [choice 54: amiwm from non-free]
gjiten: Recommends: 'fonts-ipafont-mincho | fonts-japanese-mincho' [choice 4: 
fonts-ipafont-nonfree-jisx0208 from non-free]
glchess: Depends: 'gnuchess | sjeng | crafty | phalanx | glaurung | stockfish | 
hoichess | bbchess | fruit | toga2 | fairymax' [choice 3: crafty from non-free]
globs: Depends: 'libgl1-mesa-glx | libgl1 | fglrx-glx' [choice 3: fglrx-glx 
from non-free]
gscan2pdf: Recommends: 'cuneiform' [choice 1: cuneiform from non-free]
kanatest: Recommends: 'ttf-kochi-mincho | ttf-kochi-gothic' [choice 2: 
ttf-kochi-mincho-naga10 from non-free]
kanatest: Recommends: 'ttf-kochi-mincho | ttf-kochi-gothic' [choice 4: 
ttf-kochi-gothic-naga10 from non-free]
kanjipad: Recommends: 'ttf-kochi-gothic | ttf-kochi-mincho' [choice 2: 
ttf-kochi-gothic-naga10 from non-free]
kanjipad: Recommends: 'ttf-kochi-gothic | ttf-kochi-mincho' [choice 4: 
ttf-kochi-mincho-naga10 from non-free]
kdm: Recommends: 'kde-workspace | x-session-manager | x-window-manager' [choice 
55: amiwm from non-free]
kiten: Depends: 'fonts-vlgothic | fonts-japanese-gothic' [choice 5: 
fonts-ipafont-nonfree-jisx0208 from non-free]
ldm-server: Recommends: 'gnome-session | x-session-manager | x-window-manager' 
[choice 54: amiwm from non-free]
libclam-qtmonitors1.4: Depends: 'libgl1-mesa-glx | libgl1 | fglrx-glx' [choice 
3: fglrx-glx from non-free]
libdeal.ii-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libdolfin1.0-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libelmer-dev: Depends: 'libsuitesparse-dev' [choice 2: libsuitesparse-metis-dev 
from contrib]
libgeoip1: Recommends: 'geoip-database' [choice 2: geoip-database-contrib from 
contrib]
libglw1-mesa-dev: Depends: 'lesstif2-dev | libmotif-dev' [choice 2: 
libmotif-dev from non-free]
liblpsolve55-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libpetsc3.2-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libphp-jpgraph: Depends: 'ttf-liberation | ttf-mscorefonts-installer' [choice 
3: ttf-mscorefonts-installer from contrib]
libreoffice: Recommends: 'ttf-liberation | ttf-mscorefonts-installer' [choice 
3: ttf-mscorefonts-installer from contrib]
librheolef-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libstarpufft-1.0: Depends: 'libstarpu-1.0' [choice 2: libstarpu-contrib-1.0 
from contrib]
libstarpumpi-1.0: Depends: 'libstarpu-1.0' [choice 2: libstarpu-contrib-1.0 
from contrib]

Porter help needed: CCSEapps

[Alastair McKinstry]

Hi,

I have a package CCSEapps that needs a quick look at by porters.

/
// TODO -- add more machine descriptions.
//
#if !(defined(__alpha)|| \
  defined(_CRAY1) || \
  defined(_CRAYT3E)   || \
  defined(__sgi)  || \
  defined(__sun)  || \
  defined(__i486__)   || \
  defined(i386)   || \
  defined(__i386__)   || \
  defined(__ia64__)   || \
  defined(__x86_64__) || \
  defined(__hpux) || \
  defined(_MSC_VER)   || \
  defined(_AIX))
#error We do not yet support FAB I/O on this machine
#endif


basically its only one file:  CCSEApps/BoxLib/FPC.cpp
containing a bunch of stuff like:

const
IntDescriptor
FPC::NativeLongDescriptor ()
{
#if defined(__alpha) || defined(__i486__) || defined(WIN32) ||
defined(i386) || defined(__i386__) || defined(__ia64__) ||
defined(__x86_64__)
static const IntDescriptor nld(sizeof(long),
IntDescriptor::ReverseOrder);
#endif

#ifdef _CRAY1
static const IntDescriptor nld(sizeof(long),
IntDescriptor::NormalOrder);
#endif

#if defined(__sgi) || \
defined(__sun) || \
defined(_AIX)  || \
defined(_CRAYT3E)  || \
defined(__hpux)
static const IntDescriptor  nld(sizeof(long),
IntDescriptor::NormalOrder);
#endif

return nld;
}

ie. whether the arch is little / big endian, supports IEEE arithmetic, etc.
Can anyone help?

Regards
Alastair


-- 
Alastair McKinstry  , alast...@sceal.ie , mckins...@debian.org
http://blog.sceal.ie

Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.

Re: Porter help needed: CCSEapps

[John D. Hendrickson and Sara Darnell]

Is that Overture / U.S. tax funded stuff?  Object-Oriented Tools for Solving PDEs in Complex 
Geometries ?


Is it better than Maxima or Octave with PDE's or graphing?  Does one need to CAD a whole simulation 
in Overture specific format to get a dynamic sol'n (paid for / sought)?



--
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/4edceed3.4080...@cox.net

Re: Porter help needed: CCSEapps

[Cyril Brulebois]

Alastair McKinstry mckins...@debian.org (05/12/2011):
 ie. whether the arch is little / big endian, supports IEEE arithmetic,
 etc. Can anyone help?

http://wiki.debian.org/ArchitectureSpecificsMemo might help, for a start.

Mraw,
KiBi.


signature.asc
Description: Digital signature

OSS Research Help Needed Please - drawing for tablet computer ($500.00 gift card) for participation.

[Lila Holt]

Hello!

We are asking you for some help from the Open Source communities.

As researchers at the University of Tennessee we are interested in
discovering more about learning and interactions of members of the open
source forums.   This research is conducted through the University of
Tennessee and is in no way associated with any forum organization.  To
further our research we would like input from forum members.  The responses
are very important to us so we can better understand what tools help forum
members learn and have a productive experience in participation.

There are two ways you can help:

1.   Take a survey about the tools you use in the forum.

We are requesting approximately 15 minutes of your time to participate in
our survey.
Survey link:  http://survey.utk.edu/mrIWeb/mrIWeb.dll?I.Project=FORUMLEARN



*As a thank you, upon exiting the survey you will be given an opportunity to
submit information to be entered in a drawing for a tablet computer ($500.00
Gift Card).*



2.  Have a one on one interview talking about the forums, how you learn,
and tools used.  *As a thank you for your interview you will be sent a
$25.00 gift card. * Email lh...@utk.edu for more information.





You may do either or both of the above.  Please be assured that your answers
will be confidential.  No individual’s answers will ever be identified in
any report. Should you have any questions about the project or our interest
in using the results, we encourage you to contact Lila Holt, at
lh...@utk.edu) or Vandana Singh at vand...@utk.edu.




Contact information you provide for the drawing is completely separate from
your survey answers and there will be no way to identify participants in the
actual survey responses. Nor will contact information be used for any other
purpose. The odds of being selected will depend on the number of respondents
to this survey.

Help needed please help

[Marin George Sorin]

Hy can you please help me get rid of red screen ...please i asked so many
ppl and no 1 knows how to help me...it`s about GRUB4DOS 0.4.4 i can give you
every detail please answer me

Re: Help needed please help

[Paul Wise]

On Sat, Feb 5, 2011 at 8:18 PM, Marin George Sorin
tupac.ho...@gmail.com wrote:

 Hy can you please help me get rid of red screen ...please i asked so many
 ppl and no 1 knows how to help me...it`s about GRUB4DOS 0.4.4 i can give you
 every detail please answer me

You have contacted the email list for Debian development.

Please redirect your query to one of our support channels:

http://www.debian.org/support
http://lists.debian.org/debian-user/
http://forums.debian.net/
http://ask.debian.net/
irc://irc.oftc.net/debian

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=F0CkW6fiu0PW5mkm+JeMa=6puzcy5k_r+r...@mail.gmail.com

Help needed: upgrade/replace and dpkg-divert

[Norbert Preining]

Hi all,

I am stuck in TeX Live/luaTeX package upgrades with the following problem:

Up to unstable luatex ships with two diversions for /usr/bin/texdoc
and /usr/share/man/man1/texdoc.1. The diversion have been created with
dpkg-divert --add --package luatex --rename \
  --divert /usr/bin/texdoc.notluatex /usr/bin/texdoc
(and similar for man page). In the luatex package we shipped
texdoc - texdoclua
in /usr/bin.

The current/unstable postrm called:
dpkg-divert --remove --package luatex --rename \
  --divert /usr/bin/texdoc.notluatex /usr/bin/texdoc

Now TL2009 and luatex from experimental come into play: There texdoc
has moved back into texlive-base package, and we want to remove these
diversions, luatex package will not ship anything else but the luatex
binary (and it's man page). 

How can I manage that?

I have added
texlive-base replaces luatex ( EXPERIMENTAL_VERSION)

and then tried the following things:

First try: put removal code into luatex.preinst *without* --rename
in the dpkg-divert --remove ... call

Effect: The diversion was removed, but the new texdoc not reinstantiated.


Second try: add the --rename

Effect: dpkg-divert dies:
-
...
Unpacking replacement texlive-base ...
Replacing files in old package luatex ...
...
Preparing to replace luatex 0.40.6-1+b1 (using .../luatex_0.46.0-2_amd64.deb)
...
Removing `diversion of /usr/bin/texdoc to /usr/bin/texdoc.notluatex by luatex'
dpkg-divert: rename involves overwriting `/usr/bin/texdoc' with
  different file `/usr/bin/texdoc.notluatex', not allowed
Removing `diversion of /usr/share/man/man1/texdoc.1.gz to
/usr/share/man/man1/texdoc.notluatex.1.gz by luatex'
Unpacking replacement luatex ...
-

That gave me:
$ ls -l /usr/bin/texdoc* gives:
lrwxrwxrwx 1 root root  9 Nov 29 17:20 /usr/bin/texdoc - texdoclua
lrwxrwxrwx 1 root root 48 Nov 29 17:21 /usr/bin/texdoc.notluatex -
../share/texmf-texlive/scripts/texdoc/texdoc.tlu

and dpkg -S /usr/bin/texdoc:
diversion by luatex from: /usr/bin/texdoc
diversion by luatex to: /usr/bin/texdoc.notluatex
texlive-base: /usr/bin/texdoc

Of course that happened because luatex still has the
texdoc - texdoclua
link when the preinst is running, so the dpkg-divert was unhappy.



Third try: move the same removal code into the *postinst* of the new
luatex, but the same happened:
-

Unpacking replacement texlive-base ...
Replacing files in old package luatex ...
...
Removing `diversion of /usr/bin/texdoc to /usr/bin/texdoc.notluatex by luatex'
dpkg-divert: rename involves overwriting `/usr/bin/texdoc' with
  different file `/usr/bin/texdoc.notluatex', not allowed



$ dpkg -S /usr/bin/texdoc
diversion by luatex from: /usr/bin/texdoc
diversion by luatex to: /usr/bin/texdoc.notluatex
texlive-base: /usr/bin/texdoc

$ ls -l /usr/bin/texdoc*
lrwxrwxrwx 1 root root  9 Nov 29 17:41 /usr/bin/texdoc - texdoclua
lrwxrwxrwx 1 root root 48 Nov 29 17:42 /usr/bin/texdoc.notluatex -
../share/texmf-texlive/scripts/texdoc/texdoc.tlu

But the new package texlua does NOT ship a link texdoc - texdoclua.

==0

So to sum up what we want to do:
Old status:
 - texlive-base shipped /u/b/texdoc as shell script
 - luatex diverted /u/b/texdoc by renaming to /u/b/texdoc.notluatex
 - luatex ships a link /u/b/texdoc - /u/b/texdoclua

New status should be:
 - texlive-base ships /u/b/texdoc - ../../share/texmf-dist/.../texdoc.tlu
 - no diversion in luatex
 - luatex does no ship any texdoc files

Can anyone help me here?

Best wishes

Norbert

---
Dr. Norbert PreiningAssociate Professor
JAIST Japan Advanced Institute of Science and Technology   prein...@jaist.ac.jp
Vienna University of Technology   prein...@logic.at
Debian Developer (Debian TeX Task Force)prein...@debian.org
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
SLIGO (n.)
An unnamed and exotic sexual act which people like to believe that
famous films stars get up to in private. 'To commit sligo.'
--- Douglas Adams, The Meaning of Liff


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

Preparing lecture about Debian. Help needed.

[Alexander GQ Gerasiov]

Hi there.

I'd like to ask you guys for some help.

Here in Moscow State University there is a course Software
maintenance in Linux Distribution. It is dedicated to general question
of software packaging. As example they use rpm-based community
repository Sisyphus (related to AltLinux distribution).

I'm going to lecture there (2 hours) about Debian project, deb
packages, repositories, release cycle etc. So that would be something
like debian developer's reference + debian new maintainers' guide in
pictures :)

If you have some materials (mostly I need presentation) which could help
me in preparing, please mail.

-- 
Best regards,
 Alexander GQ Gerasiov

 Contacts:
 e-mail:g...@cs.msu.su Jabber:  g...@jabber.ru
 Homepage:  http://gq.net.ru ICQ: 7272757
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1


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

Re: Preparing lecture about Debian. Help needed.

[Kevin Mark]

On Wed, Oct 28, 2009 at 03:00:12PM +0300, Alexander GQ Gerasiov wrote:
 Hi there.
 
 I'd like to ask you guys for some help.
 
 Here in Moscow State University there is a course Software
 maintenance in Linux Distribution. It is dedicated to general question
 of software packaging. As example they use rpm-based community
 repository Sisyphus (related to AltLinux distribution).
 
 I'm going to lecture there (2 hours) about Debian project, deb
 packages, repositories, release cycle etc. So that would be something
 like debian developer's reference + debian new maintainers' guide in
 pictures :)
 
 If you have some materials (mostly I need presentation) which could help
 me in preparing, please mail.
 
My diagram might be useful at
http://mysite.verizon.net/kevin.mark/newdebian2.png 
it is not 100% accurate or up-to-date but shows how packagers are made, how
they are autobuilt, how they move to the different repositories and other bits. 
I expect there to be material on the wiki (wiki.debian.org) about past 
presentations.
-- 
|  .''`.  == Debian GNU/Linux == | http://kevix.myopenid.com  |
| : :' : The Universal OS| mysite.verizon.net/kevin.mark/ |
| `. `'   http://www.debian.org/ | http://counter.li.org [#238656]|
|___`-Unless I ask to be CCd, assume I am subscribed _|


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

Re : Re: Preparing lecture about Debian. Help needed.

[anthony berger]

Re: Preparing lecture about Debian. Help needed.

[Douglas Guptill]

On Wed, Oct 28, 2009 at 09:31:37AM -0400, Kevin Mark wrote:
 On Wed, Oct 28, 2009 at 03:00:12PM +0300, Alexander GQ Gerasiov wrote:
  Hi there.
  
  I'd like to ask you guys for some help.
  
  Here in Moscow State University there is a course Software
  maintenance in Linux Distribution. It is dedicated to general question
  of software packaging. As example they use rpm-based community
  repository Sisyphus (related to AltLinux distribution).
  
  I'm going to lecture there (2 hours) about Debian project, deb
  packages, repositories, release cycle etc. So that would be something
  like debian developer's reference + debian new maintainers' guide in
  pictures :)
  
  If you have some materials (mostly I need presentation) which could help
  me in preparing, please mail.
  
 My diagram might be useful at
 http://mysite.verizon.net/kevin.mark/newdebian2.png 

Wow!

Now I don't feel so bad about my inability to grasp the big picture
of how the Debian process works.  Your diagram will be a big help.

Thanks,
Douglas.


signature.asc
Description: Digital signature

Re: Preparing lecture about Debian. Help needed.

[Simon Paillard]

On Wed, Oct 28, 2009 at 09:31:37AM -0400, Kevin Mark wrote:
 On Wed, Oct 28, 2009 at 03:00:12PM +0300, Alexander GQ Gerasiov wrote:
[..]
  I'm going to lecture there (2 hours) about Debian project, deb
  packages, repositories, release cycle etc. So that would be something
  like debian developer's reference + debian new maintainers' guide in
  pictures :)
  
  If you have some materials (mostly I need presentation) which could help
  me in preparing, please mail.

 My diagram might be useful at
 http://mysite.verizon.net/kevin.mark/newdebian2.png 
 it is not 100% accurate or up-to-date but shows how packagers are made, how
 they are autobuilt, how they move to the different repositories and other 
 bits. 

 I expect there to be material on the wiki (wiki.debian.org) about past 
 presentations.

Actually our plain old and good website lists some interesting materials, see
http://www.debian.org/events/ and specifically
http://www.debian.org/events/talks

I don't see a better place for adding to link to your diagram.

-- 
Simon Paillard


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

Re: Help needed on mipsel #541706: gpe-expenses_0.1.7-2+b1(mipsel/unstable)

[Philipp Kern]

On 2009-08-19, Andreas Moog debian-de...@warperbbs.de wrote:
 Another way to fix this is to have the scripts use /bin/bash as shell
 (as Daniel Leidert suggested, this is a problem with dash as /bin/sh).

I guess I need to point out that dash as default will propagate to the
buildds when chroots are redone.  (Which does not happen all that often,
but it's possible that some are switching in the next weeks when they're
switched to the new[0] version of sbuild.)

That's somehow due to the transition strategy so that existing installations
are not touched.

Kind regards,
Philipp Kern

[0] Actually an older version of the sbuild in unstable, I tried rebasing
against the current version and got stuck with an unusable buildd
binary.


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

Re: Help needed on mipsel #541706: gpe-expenses_0.1.7-2+b1(mipsel/unstable)

[Daniel Leidert]

Am Dienstag, den 18.08.2009, 18:09 +0100 schrieb Neil Williams:
 On Sat, 15 Aug 2009 20:21:47 +0200
 Martin Zobel-Helas zo...@ftbfs.de wrote:
 
  Package: gpe-expenses
  Version: 0.1.7-2+b1
  Severity: serious
  
  There was an error while trying to autobuild your package:
  
   Automatic build of gpe-expenses_0.1.7-2+b1 on rem by sbuild/mipsel 99.999
 
 There doesn't appear to be a mipsel machine that I can access as a
 developer to test this bug and as it was a binNMU with only one arch
 failing, I'm at a loss to see how to fix it unless someone can
 reproduce it and help with the debugging. (mips is fine).
 
 morales.debian.org is listed as down: bios issues on
 http://db.debian.org/machines.cgi and the other machines are locked
 down and/or restricted.
 
   make[3]: Entering directory `/build/buildd/gpe-expenses-0.1.7/po-lib'
   cd .. \
CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \
/bin/sh ./config.status
   config.status: creating po/Makefile.in
   config.status: executing depfiles commands
   shift: 2368: can't shift that many
   make[3]: *** [stamp-it] Error 2
  
  A full build log can be found at:
  http://buildd.debian.org/build.php?arch=mipselpkg=gpe-expensesver=0.1.7-2+b1
 
 Help?

Preamble: Not sure if this is related. If you carefully check this log I
see one main difference to successful builds. In all successful builds,
libtool and other utilities are called via /bin/sh, whereas in this log,
libtool is called via /bin/bash and the failing command is
calling /bin/sh. Just a guess: Did the shell changed on this machine
(from /bin/bash to ??) and that's causing thew problem with shift?

Really, this is just a wild guess.

Regards, Daniel


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

Re: Help needed on mipsel #541706: gpe-expenses_0.1.7-2+b1(mipsel/unstable)

[Andreas Moog]

Neil Williams wrote:
[...]
 make[3]: Entering directory `/build/buildd/gpe-expenses-0.1.7/po-lib'
 cd .. \
CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \
/bin/sh ./config.status
 config.status: creating po/Makefile.in
 config.status: executing depfiles commands
 shift: 2368: can't shift that many
 make[3]: *** [stamp-it] Error 2
 A full build log can be found at:
 http://buildd.debian.org/build.php?arch=mipselpkg=gpe-expensesver=0.1.7-2+b1
 
 Help?

The Ubuntu Bug Report https://bugs.edge.launchpad.net/bugs/415536 deals
with the same issue. There is a debdiff attached which regenerates the
autoconf files and fixes the FTBFS.

Another way to fix this is to have the scripts use /bin/bash as shell
(as Daniel Leidert suggested, this is a problem with dash as /bin/sh).

Regards, Andreas Moog

-- 
Andreas Moog
Berliner Str. 29
36205 Sontra
Germany
Tel.:+49(0)56 53 91 24 3

PGP-Encrypted mail preferred.




signature.asc
Description: OpenPGP digital signature

Help needed on mipsel #541706: gpe-expenses_0.1.7-2+b1(mipsel/unstable)

[Neil Williams]

On Sat, 15 Aug 2009 20:21:47 +0200
Martin Zobel-Helas zo...@ftbfs.de wrote:

 Package: gpe-expenses
 Version: 0.1.7-2+b1
 Severity: serious
 
 There was an error while trying to autobuild your package:
 
  Automatic build of gpe-expenses_0.1.7-2+b1 on rem by sbuild/mipsel 99.999

There doesn't appear to be a mipsel machine that I can access as a
developer to test this bug and as it was a binNMU with only one arch
failing, I'm at a loss to see how to fix it unless someone can
reproduce it and help with the debugging. (mips is fine).

morales.debian.org is listed as down: bios issues on
http://db.debian.org/machines.cgi and the other machines are locked
down and/or restricted.

  make[3]: Entering directory `/build/buildd/gpe-expenses-0.1.7/po-lib'
  cd .. \
 CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \
 /bin/sh ./config.status
  config.status: creating po/Makefile.in
  config.status: executing depfiles commands
  shift: 2368: can't shift that many
  make[3]: *** [stamp-it] Error 2
 
 A full build log can be found at:
 http://buildd.debian.org/build.php?arch=mipselpkg=gpe-expensesver=0.1.7-2+b1

Help?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpApaYReRp3X.pgp
Description: PGP signature

Help needed with /etc/X11/config/cf

[alexe100]

Hi,
It is my first time i instaled debian. I am enjoying it very much.
I am trying to compile jk6 using sour

make[3]: *** No rule to make target `/etc/X11/config/cf/Imake.tmpl',  
needed by `xmkmf'.  Stop.


I think this error is due to this

IRULESRC=/etc/X11/config/cf which exists in the jdl Makefile.

My system is :

Linux debian 2.6.26-2-686 #1 SMP Mon May 11 19:00:59 UTC 2009 i686 GNU/Linux

and it doesnt has the:
/etc/X11/config/cf




Please, how to fix this problem?

Many thanks

Alex Co









Descubra as Soluções de Financiamento Cetelem.
Saiba mais em: http://www.iol.pt/correio/rodape.php?dst=0901272


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

Re: Help needed with /etc/X11/config/cf

[Julien Cristau]

Hi,

Please consider posting this kind of questions to debian-user@ instead
of -devel, where this is off-topic.

Anyway, as for your problem:

On Tue, Jun  2, 2009 at 23:56:15 +0100, alexe...@iol.pt wrote:

 Hi,
 It is my first time i instaled debian. I am enjoying it very much.
 I am trying to compile jk6 using sour

 make[3]: *** No rule to make target `/etc/X11/config/cf/Imake.tmpl',  
 needed by `xmkmf'.  Stop.

 I think this error is due to this

 IRULESRC=/etc/X11/config/cf which exists in the jdl Makefile.

 My system is :

 Linux debian 2.6.26-2-686 #1 SMP Mon May 11 19:00:59 UTC 2009 i686 GNU/Linux

 and it doesnt has the:
 /etc/X11/config/cf

Replace it with /usr/lib/X11/config, which is where we install the imake
files (and make sure you installed the xutils-dev package).

Have fun,
Julien


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

Re: Help needed with the GPG Key Signing Coordination page

[Patrick Schoenfeld]

Hi,

On Mon, Jan 05, 2009 at 09:56:23PM +0100, Ralf Treinen wrote:
 It is not a big time investment. The most time-consuming work consists in
 regular cleanups (removing bogus entries and key signing requests that have 
 been satisfied). Maybe once per year, taking several hours of work (since
 you will have to exchange emails with requesters and dd's). Besides that,
 there are from time to time people calling in for help since they cannot
 find a dd to sign their key. This doesn't happen very often, maybe 3 to 5
 times a year at most. It such a case you have to consult the debian db and 
 find
 a dd sufficinetly close to the requester. Not much work either, but in
 general it takes exchanging emails over a period of some days or weeks.

in this case I'd be happy to help out.

Best Regards,
Patrick


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

Re: Help needed with the GPG Key Signing Coordination page

[David Watson]

* Luk Claes (l...@debian.org) wrote:
 Hi
 
 Ralf Treinen and I are looking for help with the GPG Key Signing
 Coordination page.
 
 The GPG key signing coordination page at http://nm.debian.org/gpg.php
 is primarily aimed at prospective contributors to find existing Debian
 developers who can sign their key for the ID part of the NM maintainer
 process.
 
 Ralf Treinen and I have been taking care of this page the last years but
 I want to focus on other tasks so we're now looking for one or two
 additional people to help out.  The tasks to be performed are described
 at
 http://svn.debian.org/wsvn/nm/trunk/doc/gpg-coord/README?op=filerev=0sc=0
 
 Cheers
 
 Luk

I'd be happy to help out.

-- 
David Watson - Debian GNU/Linux Developer
da...@planetwatson.co.uk, dwat...@debian.org

Web: http://planetwatson.co.uk/blog
IM(Jabber): dwat...@planetwatson.co.uk


signature.asc
Description: Digital signature

Help needed with the GPG Key Signing Coordination page

[Luk Claes]

Hi

Ralf Treinen and I are looking for help with the GPG Key Signing
Coordination page.

The GPG key signing coordination page at http://nm.debian.org/gpg.php
is primarily aimed at prospective contributors to find existing Debian
developers who can sign their key for the ID part of the NM maintainer
process.

Ralf Treinen and I have been taking care of this page the last years but
I want to focus on other tasks so we're now looking for one or two
additional people to help out.  The tasks to be performed are described
at
http://svn.debian.org/wsvn/nm/trunk/doc/gpg-coord/README?op=filerev=0sc=0

Cheers

Luk


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

Re: Help needed with the GPG Key Signing Coordination page

[Ralf Treinen]

Hi,

On Thu, Jan 08, 2009 at 08:51:42PM +0100, Patrick Schoenfeld wrote:

 I'm quiet interested in helping out a bit, but for now undecided.
 
  Ralf Treinen and I have been taking care of this page the last years but
  I want to focus on other tasks so we're now looking for one or two
  additional people to help out.  The tasks to be performed are described
  at
  http://svn.debian.org/wsvn/nm/trunk/doc/gpg-coord/README?op=filerev=0sc=0
 
 Could you tell how much time / week (or whatever scale is sensible) the
 GPG Key Signing Coordination page consumes from helpers...
 approximately?

It is not a big time investment. The most time-consuming work consists in
regular cleanups (removing bogus entries and key signing requests that have 
been satisfied). Maybe once per year, taking several hours of work (since
you will have to exchange emails with requesters and dd's). Besides that,
there are from time to time people calling in for help since they cannot
find a dd to sign their key. This doesn't happen very often, maybe 3 to 5
times a year at most. It such a case you have to consult the debian db and find
a dd sufficinetly close to the requester. Not much work either, but in
general it takes exchanging emails over a period of some days or weeks.

Even if it is not a huge amount of work it would be useful to have a second
person on the job.

-Ralf.


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

Re: Help needed with the GPG Key Signing Coordination page

[Patrick Schoenfeld]

Hi,

On Mon, Jan 05, 2009 at 08:40:03PM +0100, Luk Claes wrote:
 Ralf Treinen and I are looking for help with the GPG Key Signing
 Coordination page.

I'm quiet interested in helping out a bit, but for now undecided.

 Ralf Treinen and I have been taking care of this page the last years but
 I want to focus on other tasks so we're now looking for one or two
 additional people to help out.  The tasks to be performed are described
 at
 http://svn.debian.org/wsvn/nm/trunk/doc/gpg-coord/README?op=filerev=0sc=0

Could you tell how much time / week (or whatever scale is sensible) the
GPG Key Signing Coordination page consumes from helpers...
approximately?

BTW.

 - Reset passwords
 
 From time to time people will forget their password and ask for a new
 one. The gpg_reset_passwd script can be used to easily reset their password
 and send them a new one.

I don't know how often this is the case, but wouldn't it be possible to
automate it? In the way other sites do it, for example.

Regards,
Patrick


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

[libmagick9] Help needed defoma

[Bastien ROUCARIES]

Tags: help

Hi,

Imagemagick does use a static list of police. This could lead to problem and 
user have already send bug report.
Could be possible to help us implementing a defoma script for imagemagick?

Regards

Bastien


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

Re: [Pkg-fonts-devel] [libmagick9] Help needed defoma

[Paul Wise]

On Wed, Dec 24, 2008 at 12:06 AM, Bastien ROUCARIES
roucaries.bastien+deb...@gmail.com wrote:

 Imagemagick does use a static list of police. This could lead to problem and 
 user have already send bug report.
 Could be possible to help us implementing a defoma script for imagemagick?

It would be far far better to implement fontconfig support for
imagemagick, since defoma is Debian specific and is not available in
the RPM/Slack/etc world. It is one of my personal goals for sqeeze to
be able to add fontconfig support to all the packages that use defoma
and remove it from Debian.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Help needed for #377468

[Bastien ROUCARIES]

Hi!

I would like to ask for some help for the bug #377468, if possible,
please. Particularly from a mozilla-plugin wizard.

The problem is that djvulibre in upstream is not linked against a particular 
libXt 
in order to adapt against different libXt version depending of the browser used.
The question raised by the upsteam is the case of the browser itself already 
uses libXt, and links to
a different version of the library than the plugin. 

This bug is easily demonstrable using the command [1]:
$ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so  

But this behavior is quite fragile and could break [2] and I personally think 
that on debian browser and plugin 
will use the same version of library.

Does my assertion is always valid? Can I enforce linking against libXt at build 
time? 

BTW should we contact other plugin developper about bug like this and should we 
document this issue?

Regards

Bastien
-- 

ROUCARIÈS Bastien
   roucaries.bastien+deb...@gmail.com
---
DO NOT WRITE TO roucaries.bastien+blackh...@gmail.com OR BE BLACKLISTED


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

Re: Help needed for #377468

[Thomas Viehmann]

Bastien ROUCARIES wrote:
 I would like to ask for some help for the bug #377468, if possible,
 please. Particularly from a mozilla-plugin wizard.

 The problem is that djvulibre in upstream is not linked against a particular 
 libXt 
 in order to adapt against different libXt version depending of the browser 
 used.
 The question raised by the upsteam is the case of the browser itself already 
 uses libXt, and links to
 a different version of the library than the plugin. 

 This bug is easily demonstrable using the command [1]:
 $ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so  

 But this behavior is quite fragile and could break [2] and I personally think 
 that on debian browser and plugin 
 will use the same version of library.

 Does my assertion is always valid? Can I enforce linking against libXt at 
 build time? 

 BTW should we contact other plugin developper about bug like this and should 
 we document this issue?

Just having made this choice w.r.t. to nsdejavu and pthread for properly
fixing #504740, I'd recommend adding the libs to NSDEJAVU_LIBS for the
reasons Steve explained (the pro becomes even more obvious when you
factor in symbol versioning that some libraries may have).

Personally, I'd also recommend to go with Steve's opinion on these
matters when you don't have one of your own, but that's mostly based on
the profound expertise in this area that he demonstrated in Debian over
and over again and not an argument in itself.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Help needed for #377468

[Thomas Viehmann]

[dropped even more CCs]

roucaries bastien wrote:
 It seems other plugins have the same problem. Should I open bug report?
Well, that depends a bit:
a) some of the symbols in your list (NS_*) might be from stuff that can
   reasonably be expected to always linked into things loading the
   plugins. (I don't know, but it should be checked before filing bugs,
   also see c) ),
b) otherwise it seems to be a bug,
c) for things that don't break within the set of packages Debian ships,
   I think fixing them for Lenny is not that important. For stuff that
   breaks, well, it might be worth fixing if it's easily fixable, but
   I'd ask for input of the release team before filing.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Help needed for #377468

[roucaries bastien]

On Sat, Dec 20, 2008 at 4:22 PM, Thomas Viehmann t...@beamnet.de wrote:
 Bastien ROUCARIES wrote:
 I would like to ask for some help for the bug #377468, if possible,
 please. Particularly from a mozilla-plugin wizard.

 Just having made this choice w.r.t. to nsdejavu and pthread for properly
 fixing #504740, I'd recommend adding the libs to NSDEJAVU_LIBS for the
 reasons Steve explained (the pro becomes even more obvious when you
 factor in symbol versioning that some libraries may have).

 Personally, I'd also recommend to go with Steve's opinion on these
 matters when you don't have one of your own, but that's mostly based on
 the profound expertise in this area that he demonstrated in Debian over
 and over again and not an argument in itself.

Ok but I will do for my package.

It seems other plugins have the same problem. Should I open bug report?

$ldd -d -r /usr/lib/mozilla/plugins/* 21 | grep undefined
undefined symbol:
__gxx_personality_v0
(/usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so)
undefined symbol:
gdk_window_invalidate_rect  
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_set_operator  (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_cairo_create(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringSetData   (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_destroy   (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_widget_get_type (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_StringContainerFinish
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol: NS_Alloc  
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringCopy  (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringContainerInit (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_paint (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_restore   (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_GetMemoryManager (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_StringContainerInit  (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_draw_rectangle  (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_GetComponentManager  (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_widget_get_screen   (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringContainerFinish   
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_StringGetData(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_translate (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_draw_drawable   (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringGetData   (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_object_get_type (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_button_get_type (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_window_begin_paint_rect 
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_widget_send_expose  (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_cairo_rectangle (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_button_get_image(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_cairo_set_source_pixmap 
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_pixmap_new  (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringGetMutableData
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_settings_get_for_screen 
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol: cairo_clip
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_GetServiceManager(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_UTF16ToCString   (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringContainerInit2
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol: NS_Free   
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol: cairo_save
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_window_end_paint(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_paint_with_alpha  (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_window_process_updates  
(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_window_invalidate_rect  
(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined 

Re: Help needed for #377468

[Alexander Sack]

On Sat, Dec 20, 2008 at 03:50:21PM +0100, Bastien ROUCARIES wrote:
 Hi!
 
 I would like to ask for some help for the bug #377468, if possible,
 please. Particularly from a mozilla-plugin wizard.
 
 The problem is that djvulibre in upstream is not linked against a particular 
 libXt 
 in order to adapt against different libXt version depending of the browser 
 used.
 The question raised by the upsteam is the case of the browser itself already 
 uses libXt, and links to
 a different version of the library than the plugin. 
 

I think it should link against libXt in any case.

AFAIK libXt properly tracks library version, so linking against it
should actually do the right thing. Of course your plugin might only
use a super stable subset of the symbols in libXt, but even then i
think not linking against the system lib causes troubles.

 - Alexander


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

help needed for free pascal (fpc) / lazarus

[Torsten Werner]

Hi,

please have a look at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413805. The package
lazarus requires the sources of free pascal because it parses them.
The obvious solution is to create a binary package fpc-source shipping
the sources and add a Depends or Recommends to lazarus. This is
similar to other packages like emacs lisp, java, and erlang.  Jörg
Jaspert rejected that upload and suggested to ask debian-devel. Does
anyone suggest any other solution? Please Cc: me in your answers
because I am not subscribed to debian-devel.

Thanks,
Torsten

-- 
blog: http://twerner.blogspot.com/
homepage: http://www.twerner42.de/

Re: help needed for free pascal (fpc) / lazarus

[Andreas Tille]

On Sat, 8 Dec 2007, Torsten Werner wrote:


please have a look at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413805. The package
lazarus requires the sources of free pascal because it parses them.
The obvious solution is to create a binary package fpc-source shipping
the sources and add a Depends or Recommends to lazarus. This is
similar to other packages like emacs lisp, java, and erlang.


I completely fail to see any reason to reject a solution that fixes
a serious bug (well #413805 is tagged wishlist but this is definitely
wrong - it should be serious because lazarus just does not work
without fpc-sources).

Kind regards

 Andreas.

--
http://fam-tille.de


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

Help needed for bug #441794 on postgis

[Fabio Tranchitella]

Hi fellow developers,

I need some help to figure out how to fix an issue with the postgis
package, a PostgreSQL extension for handling spatial data.

The bug report is #441794, and here there is a quick summary: the package
provides a shared object (liblwgeom) which is used by postgresql for the
postgis-specific functions. With the last upload (a new upstream release)
the soname changed and the database became unusable because those functions
referred to the old soname.

I know that I could change the package name to reflect the soname, but I'm
wondering if there is a better way to handle it. Note that this issue will
pop up again when upgrading from etch to lenny.

Thanks in advance,

-- 
Fabio Tranchitella [EMAIL PROTECTED].''`.
Proud Debian GNU/Linux developer, admin and user.: :'  :
 `. `'`
   http://people.debian.org/~kobold/   `-
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


signature.asc
Description: Digital signature

Re: Help needed for bug #441794 on postgis

[Francesco P. Lovergine]

On Tue, Nov 13, 2007 at 09:12:59AM +0100, Fabio Tranchitella wrote:
 Hi fellow developers,
 
 I need some help to figure out how to fix an issue with the postgis
 package, a PostgreSQL extension for handling spatial data.
 
 The bug report is #441794, and here there is a quick summary: the package
 provides a shared object (liblwgeom) which is used by postgresql for the
 postgis-specific functions. With the last upload (a new upstream release)
 the soname changed and the database became unusable because those functions
 referred to the old soname.
 
 I know that I could change the package name to reflect the soname, but I'm
 wondering if there is a better way to handle it. Note that this issue will
 pop up again when upgrading from etch to lenny.
 
 Thanks in advance,
 

I would suggest a manual soft-upgrade at every major upstream release.
This SHOULD be done by admin, I would avoid any automatic upgrade for
safety.
Release notes do not talk about a soft-upgrade requirement in 1.2-1.3, 
but it could be possible that it has been oversight roughly :-/
There are good possibility of needing a hard-upgrade (manual dump/restore) at 
the
time of etch-lenny transition due to geometry changes, too.


-- 
Francesco P. Lovergine


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

Re: Help needed for bug #441794 on postgis

[Martijn van Oosterhout]

On Nov 13, 2007 9:12 AM, Fabio Tranchitella [EMAIL PROTECTED] wrote:
 The bug report is #441794, and here there is a quick summary: the package
 provides a shared object (liblwgeom) which is used by postgresql for the
 postgis-specific functions. With the last upload (a new upstream release)
 the soname changed and the database became unusable because those functions
 referred to the old soname.

Does the API actually change? Otherwise you might have to allow them
to be parallel installable...

Have a nice day,
-- 
Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/


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

Re: Help needed to fix watch file (Was: Bug#449736: wordnet: debian/watch fails to report upstream's version)

[Cyril Brulebois]

Andreas Tille [EMAIL PROTECTED] (07/11/2007):
 The source tarball is provided as

 http://wordnet.princeton.edu/3.0/WordNet-3.0.tar.gz

Since it is linked from http://wordnet.princeton.edu/obtain/…

 Any idea whether the watch file is wrong or is it possible that the
 upstream server just does not work correctly?

… what about the following?

8
http://wordnet.princeton.edu/obtain/ .*WordNet-(.*).tar.gz
8

Cheers,

-- 
Cyril Brulebois


signature.asc
Description: Digital signature

Help needed to fix watch file (Was: Bug#449736: wordnet: debian/watch fails to report upstream's version)

[Andreas Tille]

On Wed, 7 Nov 2007, Raphael Geissert wrote:


The debian/watch file of your package on the unstable distribution fails to 
report upstream's version.
Uscan's message follows:


uscan warning: In /tmp/wordnet_watchBHUkns,
 no matching hrefs for watch line
 http://wordnet.princeton.edu/(.*)/WordNet-(.*).tar.gz



The source tarball is provided as

http://wordnet.princeton.edu/3.0/WordNet-3.0.tar.gz
http://wordnet.princeton.edu/3.0/WordNet-3.0.tar.bz2 (alternatively)

Any idea whether the watch file is wrong or is it possible that
the upstream server just does not work correctly?

Kind regards and thanks for this fixing watch file effort

Andreas.

--
http://fam-tille.de


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

ppp: co-maintainer and urgent help needed

[Marco d'Itri]

I will not be able to spend much time on the ppp package before the
release, so I am requesting help in triaging and fixing as many bugs
as possible (the list is long, but let's only consider the ones opened
this year) and uploading a new package ASAP.
There is nothing actually *terrible* in the package, but it could use
some work.

Applications for co-maintainership are also encouraged.

-- 
ciao,
Marco


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

Re: master mail problems -- help needed

[Wouter Verhelst]

On Sat, Nov 26, 2005 at 04:39:46PM +0100, Jeroen van Wolffelaar wrote:
 When an exim mailserver is really bogged down under mail load, attempts
 can be made even less often.

It's ben pointed out to me that my mail through master is also bouncing
at times. I also have an IPv6 MX, so it could be related. However,
another datapoint (and relevant to the above):

top - 07:38:12 up 293 days, 15:52,  8 users,  load average: 5.92, 5.39, 5.12
Tasks: 288 total,   6 running, 280 sleeping,   1 stopped,   1 zombie
Cpu(s):  29.9% user,  18.9% system,   0.5% nice,  50.7% idle
Mem:   2069780k total,  1981968k used,87812k free,   268648k buffers
Swap:  284k total,35744k used,  1964340k free,  1132708k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
   
18353 clamav16   0 19560  18m 9672 R 33.9  0.9  12:20.88 clamd  
   
18120 clamav16   0 19560  18m 9672 R 30.9  0.9  55:56.78 clamd  
   
18360 clamav16   0 19560  18m 9672 R 30.9  0.9   2:33.51 clamd  
   
31657 clamav15   0 19560  18m 9672 R 30.9  0.9   8:39.73 clamd  
   
 8251 clamav15   0 19560  18m 9672 R 14.7  0.9   0:02.64 clamd  
   
14004 wouter16   0  1416 1416 1060 R 10.3  0.1   0:00.15 top
   
13930 Debian-e  10   0  3184 3176 2820 S  4.4  0.2   0:00.06 exim4  
   
14010 root  11   0  3184 3176 3036 S  4.4  0.2   0:00.05 exim4  
   
 4562 root   9   0 31148  30m 8564 S  1.5  1.5 279:23.32 named  
   
18357 clamav 9   0 19560  18m 9672 S  1.5  0.9  27:43.19 clamd  
   
12311 www-data   9   0  4936 4160 3968 S  1.5  0.2   0:00.02 apache 
   
12826 www-data   9   0 000 Z  1.5  0.0   0:00.02 apache defunct   
   
14030 root  16   0  3164 3156 3036 S  1.5  0.2   0:00.01 exim4  
   
14031 Debian-e  16   0  3232 3224 3052 D  1.5  0.2   0:00.01 exim4  
   
1 root   8   0   472  440  420 S  0.0  0.0 243:01.96 init   
   
2 root   9   0 000 S  0.0  0.0   0:01.57 keventd
   
3 root  19  19 000 S  0.0  0.0   0:13.91 ksoftirqd_CPU0 
   
4 root  19  19 000 S  0.0  0.0   0:14.97 ksoftirqd_CPU1 
   
5 root   9   0 000 S  0.0  0.0   3029:45 kswapd 
   
6 root   9   0 000 S  0.0  0.0  60:08.08 bdflush
   

That's on master. I've been watching it for about 5 minutes, and never
saw the load drop below 3.80-ish.

Could it be that master is simply imploding on the amount of mail
received?

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: master mail problems -- help needed

[Romain Francoise]

Wouter Verhelst [EMAIL PROTECTED] writes:

 That's on master. I've been watching it for about 5 minutes, and never
 saw the load drop below 3.80-ish.

 Could it be that master is simply imploding on the amount of mail
 received?

It's always been like that (if not worse).

-- 
  ,''`.
 : :' :Romain Francoise [EMAIL PROTECTED]
 `. `' http://people.debian.org/~rfrancoise/
   `-


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

Re: master mail problems -- help needed

[Wouter Verhelst]

On Thu, Dec 08, 2005 at 03:00:58PM +0100, Romain Francoise wrote:
 Wouter Verhelst [EMAIL PROTECTED] writes:
  That's on master. I've been watching it for about 5 minutes, and never
  saw the load drop below 3.80-ish.
 
  Could it be that master is simply imploding on the amount of mail
  received?
 
 It's always been like that (if not worse).

Not that I recall. But then, I'm not really all that familiar with
master, so let's assume it's indeed something else.

The fact that my primary MX is only available through IPv6, and that
this is the case for other people who're having problems too might then
be a better chance at being the problem.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: master mail problems -- help needed

[Lionel Elie Mamane]

On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote:

 The fact that my primary MX is only available through IPv6, and that
 this is the case for other people who're having problems too might
 then be a better chance at being the problem.

My primary MX is IPv6-only, too. I don't have detected a problem yet :)

-- 
Lionel


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