Bug#1067426: [Pkg-electronics-devel] Bug#1067426: Package sponsorship request Qucs-S

[Felix Salfelder]

On Fri, Mar 22, 2024 at 03:47:12PM +0100, Tobias Frost via 
Pkg-electronics-devel wrote:
> I've had a brief view at the debian/ directory on your repository,
> and there will be a bit work required to make your package suitable
> for inclusion into Debian, for example you'll need a debian/copyright
> file. I didn't look into further details, but I suggest to upload your
> package to mentors.debian.net, as this has already some QA built in and
> will help you to identify problems with your package, for example from
> the linitian tool.

Hi there.

Ruben has done significant work on a Qucs package in 2019, which might
serve as a starting point [0].

I picked it up after the upstream repo split [1,2]. The former has been
released since (version 0.0.20). The latter isn't suitable for Debian
due to the Qt3 dependency. Needless to say, none of this has been
uploaded. But there's little need to start from scratch.

Best wishes
felix

[0] https://salsa.debian.org/science-team/qucs
[1] https://salsa.debian.org/felixs-guest/qucsator
[2] https://salsa.debian.org/felixs-guest/qucs

Bug#1062184: [Pkg-electronics-devel] Bug#1062184: gnucap: NMU diff for 64-bit time_t transition

[Felix Salfelder]

On Wed, Jan 31, 2024 at 03:36:36PM +, Lukas Märdian wrote:
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> gnucap as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).

Dear Lukas.

Thanks for your work.

I'm very certain that we do not use time_t anywhere. Certainly not
explicitly, and there is no time_t mentioned in any library interface,
leave alone header file.

Hence I believe this is a false positive. To remain on the safe side,
i'm happy to investigate the assessment if needed. Feel free to provide
any log files or evidence from the analysis.

Best wishes
felix

Bug#1036739: ITP: gnucap-modelgen-verilog -- Verilog-AMS behavioural modelling for Gnucap

[Felix Salfelder]

Package: wnpp
Severity: wishlist
Owner: Felix Salfelder 
X-Debbugs-Cc: debian-de...@lists.debian.org, fe...@salfelder.org

* Package name: gnucap-modelgen-verilog
  Version : 20230520-dev
  Upstream Contact: gnucap-devel 
* URL : http://www.gnucap.org/
* License : GPL
  Programming Lang: C++, Verilog-AMS
  Description : Verilog-AMS behavioural modelling for Gnucap

This package provides support for Verilog-AMS behavioural models in
Gnucap as well as supplementary plugins.
  Verilog-AMS is a standardised hardware description language suitable for
analog and mixed signal system modelling.
  Gnucap is a general purpose circuit simulator. It performs nonlinear
dc and transient analyses, Fourier analysis, and ac analysis
linearized at an operating point. It is fully interactive and
command driven. It can also be run in batch mode or as a server.

> usefulness/relevance

This package supplements ADMS, the automatic device model synthesizer.
Unlike ADMS, modelgen-verilog uses a programming language for the model
generation instead of XML template driven text substitution. ADMS is
limited to the analog/SPICE subsection of Verilog-AMS, while
modelgen-verilog is designed to support mixed features and post-spice
architectures.

> maintenance

I will maintain this packgage as a pkg-electronics team member.

Bug#714836: qucsator release

[Felix Salfelder]

Dear all.

We have released qucsator-0.0.20 [1]. It has been part of qucs, but it
is also being used without qucs. It will also work in combination with
any statically linked (qt3, non-debian) build of qucs or some of its
forks. I think it will be good to have qucsator in Debian. Please
consider packageing it e.g. within the electronics team [2].

The qucs qt5 implementation is progressing, and it will still support
qucsator as a simulator backend.

cheers
felix

[1] 
https://sourceforge.net/projects/qucs/files/qucs/0.0.20/qucsator-0.0.20.tar.gz
[2] https://salsa.debian.org/electronics-team

Bug#968454: restinio: refers to missing format.h, http_parser.h

[Felix Salfelder]

On Sat, Aug 15, 2020 at 01:12:11PM -0400, Alexandre Viau wrote:
> Could it be that librestinio-dev is missing libfmt-dev and
> libhttp-parser-dev dependencies?

You are right. fixed in "deps" branch [1].  I am not sure if there are
other missing deps of this kind.

thanks!
felix

[1] 
https://salsa.debian.org/debian/restinio/-/commit/e3bd7a19449ad6c8f7118396a183a97cea660740


signature.asc
Description: PGP signature

Bug#950198: restinio

[Felix Salfelder]

On Fri, May 15, 2020 at 11:30:03AM +0200, Petter Reinholdtsen wrote:
> [Alexandre Viau]
> > The next step would now be to update OpenDHT, which should be quick
> > once restinio passes new.
> 
> The restinio package was just accepted into unstable.

I am half way through opendht [1]. My package lacks testing (just
imported new upstream 2.1.1). I will continue as time permits, but feel
free to help.

cheers
felix

[1] https://salsa.debian.org/felixs-guest/opendht

Bug#950198: restinio

[Felix Salfelder]

On Mon, Apr 27, 2020 at 01:22:29PM +0200, Sébastien Delafond wrote:
> It was perfectly clear the first time, and this is where we can agree to
> disagree.

Dear Sébastien.

Yes, lets agree.

> Starting on this project I had a couple of goals.

Towards the original goal (getting Jami into Debian), I have reworded
the cmake patch description and improved the package based on your
proposed changes.

- cleanup rules, add the MULTIARCH bit
- more on d/copyright
- cmake dependency
- d/watch

> As I don't intend to maintain restinio in the long run, I don't feel the
> need to argue this any further, and will happily defer to Alexandre's
> opinion.

I acknowledge that running the tests is of importance to you. I will
certainly take that into consideration.

To proceed, we need restinio in NEW. If you (or anybody else follwing
this conversation) wishes to help, please review and/or sponsor [1].

Looking at Alexandre's Jami package, I infer that small(er) tarballs are
in his interest. I do not actually know, and if it helps, I am not going
to decide how the 0.6.6 package will look like.

best regards
felix

[1] https://salsa.debian.org/felixs-guest/restinio/-/tree/master-0.6.4

Bug#950198: restinio

[Felix Salfelder]

Thanks Sébastien for your analysis.

On Mon, Apr 27, 2020 at 12:10:35PM +0200, Sébastien Delafond wrote:
> Before you go ahead on any of this, please let's wait for Alexandre's
> input.

I agree.

> I am unsure where your gut feeling comes from: the smaller package is OK
> to simply use as an include in a development project. OTOH when building
> the Debian package, we're definitely interested in running the
> upstream-provided unit tests during a regular build.

My gut feeling.. let me try and explain.

First of all, there is no technical requirement for release tarballs of
different sizes. The friction is most obvious in the copyright file.

But also distributing stuff that is packaged elsewhere is against the
packaging guidelines [1] in a similar context (repacking).

"""
6.7.8.2.2  [the package]
should not contain any file that does not come from the upstream
author(s).
"""

Then, I do not believe that source files "come from upstream" authors
just because they inadvertendly bundle third party work into some kind
of "convenience" tarball.

Beyond belief, the package (as I did it) is in fact based on the
upstream git repo, so this is where "upstream" comes from. And I am in
good society doing it that way [2].

"""
There is absolutely no technical reason to not use the upstream git
repository as the basis for the git repository used in Debian packaging.
I would never package software maintained in a git repository upstream
and not do so.
"""

I hope it is more clear now, how I prefer to use the small tarball over
running the tests, as a matter of principle. The tests can be added
later, once it will be practical, e.g. with a patch, and maybe some
other dependencies packaged.

regards
felix

[1] 
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html
[2] http://joeyh.name/blog/entry/upstream_git_repositories/

Bug#950198: restinio

[Felix Salfelder]

Please apologise the flood, I missed something obvious.

On Mon, Apr 27, 2020 at 11:02:23AM +0200, Felix Salfelder wrote:
> The freshly imported tarball (0.6.6) contains an embedded dev/asio
> directory, which does not exist in the upstream repository, nor was it
> in the 0.6.4 tarball. I understand that this copy is unnecessary. But
> some test is compiled with -I${top_srcdir}/dev/asio/include.

The source of this is, upstream is offering multiple tarballs, one with
third party packages included. This also explains some of Sébastiens
additions to the copyright file.

As of version 0.6.4, none of the additional headers were required for
either for building opendht or jami. I have imported the smaller
tarball and rebased Sébastiens commits. It's in my master branch now
[1].

I'm afraid the package does no longer build, and I am unsure how to
proceed. My gut feeling is that the small tarball is the correct one,
(although I can see the other one listed in d/watch), and that the tests
should be compiled against installed packages, if at all.

thanks
felix

[1] https://salsa.debian.org/felixs-guest/restinio/master

Bug#950198: restinio

[Felix Salfelder]

On Mon, Apr 27, 2020 at 09:07:36AM +0200, Sébastien Delafond wrote:
> I've pushed my version of restinio's packaging to
> [..]
> Let me know if you want me to upload what I've got now to NEW.

amazing. thank you.

> So we don't forget, here are a couple of items we'll want to fix later
> on:
>
>   - salsa-ci
> 
>   - open an issue upstream to integrate my two cmake patches for the
> scenario "build a release without shipping binaries, yet
> insist on running the tests during our build"

I will see what I can do about these.

Something else that might need work.

The freshly imported tarball (0.6.6) contains an embedded dev/asio
directory, which does not exist in the upstream repository, nor was it
in the 0.6.4 tarball. I understand that this copy is unnecessary. But
some test is compiled with -I${top_srcdir}/dev/asio/include.

The embedded asio does not coincide with libasio-dev in sid, 1:1.12.2-1.
Imo (and I am certainly clueless here) this may lead to questionable
test results. Technically, We may need to depend on a specific
libasio-dev.

cheers
felix

Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform

[Felix Salfelder]

On Sat, Apr 04, 2020 at 04:25:05PM -0400, Alexandre Viau wrote:
> If you feel like you have a working package, would you please link me
> to a git repository on salsa that I can review?

Dear Alexandre.

It's working afaict. Not fully complete -- minor details i would hope.
See my namespace on salsa [1], please move it to a more appropriate
place, if it makes sense to you.

> As a reviewer, I don't find mentors.d.o very useful but feel free to
> use it if you think its appropriate for you.

I only meant put the package on display there, I prefer plain git for
anything else.

cheers
felix

[1] https://salsa.debian.org/felixs-guest/restinio/

Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform

[Felix Salfelder]

> restinio [..]

some progress [1].

thanks
felix

[1] https://mentors.debian.net/package/restinio

Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform

[Felix Salfelder]

On Mon, Mar 23, 2020 at 11:27:25AM -0400, Alexandre Viau wrote:
> No, it won't. Why would it be a bottleneck?

Well. If it's not, that is only better.

> We need to package restinio. This is the first step. Nothing else.

I pushed the package to mentors (using dput). I was expecting it to show
up [1] at some point. Either way, feel free to grab it from salsa.

It's ready to upload as I can get right now.

cheers
felix

[1] https://mentors.debian.net/packages/index

Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform

[Felix Salfelder]

Dear Alexandre.

> It looks like you are trying to do many things at once.
>
> Instead of trying to fix everything in one go, I would suggest that we
> pick one problem and move from there.

Thanks for your feedback.

I tried to update my Jami installation, when connections to newer Jami
clients broke down, unfortunately. The fresh version is working for me.

> How about we start by packaging restinio in Debian? I'd gladly sponsor
> such an upload.

I can see an upper bound to the efforts required to update Jami. The
restinio package is not my primary interest. But will try to allocate
some time for it [1].

Afaiu, the bottleneck will be opendht. opendht is already packaged, but
too old. The required version is unreleased (2.0.0rc2). What does it
take to have a release candidate in Debian?

best regards
felix

[1] https://salsa.debian.org/felixs-guest/restinio

Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform

[Felix Salfelder]

On Wed, Jan 29, 2020 at 08:36:07PM -0500, Alexandre Viau wrote:
> I would love to update Jami[1] (https://jami.net) in Debian.

I have prepared some preliminary packages [0,1,2,3]. It seems to run
without a lot of patching, but pjp. I'm afraid there is more work to
do...

cheers/hth
felix

[0] https://salsa.debian.org/felixs-guest/restinio(0.6.4)
[1] https://salsa.debian.org/felixs-guest/opendht (2.0.0rc2)
[2] https://salsa.debian.org/felixs-guest/http-parser (2.9.3)
[3] https://salsa.debian.org/felixs-guest/ring(20200316)


signature.asc
Description: PGP signature

Bug#924822: adms is marked for autoremoval from testing

[Felix Salfelder]

On Mon, Mar 25, 2019 at 04:39:08AM +, Debian testing autoremoval watch 
wrote:
> adms 2.3.6-1 is marked for autoremoval from testing on 2019-04-15
> 
> It is affected by these RC bugs:
> 924822: adms: FTBFS: admstpathYacc.y:14604: error: unterminated
> argument list invoking macro "adms_message_error"

possibly related to the perl/yaml upgrade in testing.

could not reproduce the reported issue. but found a similar issue. there
is a typo in admsXml/Makefile.am & FTBFS for me.

-verilogYacc.h: verilogYacc.c
+verilogaYacc.h: verilogaYacc.c

with this [1] it appears to work.

hth
felix

[1] 
https://salsa.debian.org/science-team/adms/commit/4852d662a19017eac73a6b518cedc5eff80a9ea6

Bug#920449: ITP: gnucap-custom -- gnucap-custom provides a basis for customisation of the GNU circuit analysis package

[Felix Salfelder]

Package: wnpp
Severity: wishlist
Owner: Felix Salfelder 

* Package name: gnucap-custom
  Version : 0.0.1
  Upstream Author : Felix Salfelder 
* URL : https://gitlab.com/gnucap/gnucap-custom
* License : GPLv3+
  Programming Lang: C++
  Description : A basis for Gnucap customisation

Gnucap-custom provides a customisable executable for Gnucap, the GNU
circuit analysis package. It includes plugins improving readline
support, input processing, module loading and some tweaks. The package
provides the makefiles and loader used by gnucap-adms, which aids
compiling behavioural models.

I intend to maintain the package inside the pkg-electronics packageing
team.

Bug#919255: [Pkg-electronics-devel] Bug#918533: gnucap-python: diff for NMU version 0.0.2-1.1

[Felix Salfelder]

On Sun, Jan 20, 2019 at 07:33:44PM +0100, Mattia Rizzolo wrote:
> Then if you don't mind I'd still keep my NMU as it is and let it enter
> unstable.  The only thing is that you'd find yourself to integrate it
> into your own tree.

no worries. will merge it.

thanks
felix

Bug#918533: [Pkg-electronics-devel] Bug#918533: gnucap-python: diff for NMU version 0.0.2-1.1

[Felix Salfelder]

On Sun, Jan 20, 2019 at 04:34:28PM +0100, Mattia Rizzolo wrote:
> If it's only about sponsoring I'm happy to help, but I don't really want
> to play with symbols at this time…

my preferred solution will be to accept the dpkg-shlibdeps warnings, as
described in the manual. it will be more tricky to silence them.

> With this and onther package being the only last blockers for the
> removal of python3.6 I'm somewhat pressured to continue, unless you can
> give me a shorter ETA.  Also, I'm happy to rework my work.

I essetially agree with your changes. the ETA is subject to
review & sponsoring.

> On that note, looking at the git repository I see that:
>   * you didn't do anything to d/rules, that still mention 3.6 and 3.7

I used a symlink to make tests work across python versions. currently
the tests are not active, due to numerical noise. I had planned to clean
up d/rules after reworking the tests upstream, when re-enabling the
tests.

>   * you are build-depending on python3-dev, instead of python3-all-dev,
> is that wanted?  As I went for the letter in my NMU.

looks reasonable. i simply did not know about it.

> Also, while working on gnucap-python, I had the feeling that those
> out2.7 and out3.6 directories were pre-built stuff that shouldn't be in

out* contains the expected output for testing, which varies across
python versions. it actually shouldn't, and it does not between 3.7 and
3.6. perhaps out2 and out3 will be sufficient. work in progress,
possibly ready in 0.0.3.

thanks
felix

Bug#918533: [Pkg-electronics-devel] Bug#918533: gnucap-python: diff for NMU version 0.0.2-1.1

[Felix Salfelder]

On Sun, Jan 20, 2019 at 01:55:18PM +0100, Mattia Rizzolo wrote:
> I've prepared an NMU for gnucap-python (versioned as 0.0.2-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Dear Mattia.

thanks for your commitment. I have prepared 0.0.2-2 in the
pkg-electronics team repo, looking for a sponsor. we are now discussing
issues with toolchains [2], ETA unknown. Please proceed as you wish.

regards
felix

[1] https://salsa.debian.org/electronics-team/Gnucap/gnucap-python.git
[2] 
https://alioth-lists.debian.net/pipermail/pkg-electronics-devel/2019-January/thread.html#5887

Bug#914355: [Pkg-electronics-devel] Bug#914355: gnucap-python: FTBFS (dh_auto_configure fails)

[Felix Salfelder]

On Thu, Nov 22, 2018 at 04:35:20PM +, Santiago Vila wrote:
> Package: src:gnucap-python
> Version: 0.0.0-1
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package but it failed:

Thank you.

there's a new package for the 0.0.1 release [1]. the build issue caused
by incomplete python dependencies is fixed. this was one reason for
914355.

i checked with cowbuilder for amd64 and i386. on i386, only the tests
fail due to numerical noise. please advise if that can wait until 0.0.2,
ETA unknown. (i don't think there is a use case for gnucap on i386..)

regards
felix

[1] https://salsa.debian.org/electronics-team/Gnucap/gnucap-python

Bug#911965: kicad: Add libngspice to dependancy list

[Felix Salfelder]

On Sat, Oct 27, 2018 at 11:09:47AM +0200, Carsten Schoenert wrote:
> That's all correct, but right now upstream is opening libngspice.so,
> *not* libngspice.so.0!

which i suggested to fix. in the package and (also) upstream.

> Upstream
> stated they had problems to get this working correctly (while this
> feature was added in 2016) and they did the fallback to use dlopen
> globally here.

To me, it looked more like they had good reasons not to link. and i can't
see anything wrong with calling dlopen in that situation. I did not know
anybody is even trying to change it. YMMV.

> Because of this I won't invest more time here, there is no real gain on
> doing this.

fair enough.

> > also, the package name libngspice0-dev seems to be wrong. that should
> > have produced a lintian warning...?
> 
> No and it never did.
> [..]
> $ grep Package:
> /var/lib/apt/lists/*_debian_dists_testing_main_binary-amd64_Packages |
> grep "\-dev$"

My memory was corrupted on this, thanks for the clarification!

best
felix

Bug#911965: kicad: Add libngspice to dependancy list

[Felix Salfelder]

On Sat, Oct 27, 2018 at 10:01:29AM +0200, Carsten Schoenert wrote:
> > Probably the approach used in gnucap-python will work here as well:
> > - find the SONAME in ./configure, tweak the dlopen call, see [1],
> > - tweak d/rules: link a dummy executable, inject shlibdeps [2].
> 
> The dlopen call is currently searching for libngspice.so instead of
> libngspice.so.0 so your suggestion would not solve all problems.

Hi Carsten.

I suggested to dlopen libngspice.so.0. the point is, that you need to
resolve it during configure time.

$ readelf -d /usr/lib/x86_64-linux-gnu/libngspice.so |grep SONAME
 0x000e (SONAME) Library soname: [libngspice.so.0]

also, the package name libngspice0-dev seems to be wrong. that should
have produced a lintian warning...?

cheers
felix

Bug#911965: [Pkg-electronics-devel] Bug#911965: kicad: Add libngspice to dependancy list

[Felix Salfelder]

On Fri, Oct 26, 2018 at 08:22:45PM +0200, Carsten Schoenert wrote:
> partially correct.
> KiCad in Debian now supports ngspice based simulations provided by the
> library libngspice.so.0.0.0 from the package libngspice0.
> 
> The question is why the packaging doesn't detect this dependency
> automatically ... I will have a look.

Dear Carsten.

It seems to me that kicad does not link against ngspice, but rather
dlopens the shared library on demand.

While the reasons are probably different, this approach is very similar
to how gnucap-python uses libgnucap. The issue is related to the
SONAME and file name used in lib${simulator}0 vs lib${simulator}-dev.

Probably the approach used in gnucap-python will work here as well:
- find the SONAME in ./configure, tweak the dlopen call, see [1],
- tweak d/rules: link a dummy executable, inject shlibdeps [2].

I am curious if there is a better way..

hth
felix

[1] 
https://salsa.debian.org/electronics-team/Gnucap/gnucap-python/blob/master/configure.ac
[2] 
https://salsa.debian.org/electronics-team/Gnucap/gnucap-python/blob/master/debian/rules

Bug#834247: marked as done (ngspice is configured with --with-editline, --with-readline would work better)

[Felix Salfelder]

On Sun, Oct 14, 2018 at 03:49:49PM +0200, Carsten Schoenert wrote:
> now I understand what you mean!

Apologies for being vague in my first post. Some of the legal issues
mentioned in the report have in fact been solved. Thanks to everyone
involved!

> And (unfortunately) you are right! I wasn't aware about the license of
> readline [..]

It was mere coincidence. I read something about readline and its license
a few days before the "ngspice" + "readline" subject appeared in my
mailbox.

> I reverted this part back to use libedit so we are not falling into this
> legal trap. An upload will follow shortly.

thank you
felix

# don't know if if works like that, fingers crossed
found 834247 28-1

Bug#834247: marked as done (ngspice is configured with --with-editline, --with-readline would work better)

[Felix Salfelder]

On Sun, Oct 14, 2018 at 08:17:58AM +0200, Carsten Schoenert wrote:
> I don't know if something has changed here, I only know the current
> cirumstances and there I don't see reasons not to use readline.

Hi Carsten,

thank you for your email.

I am not a lawyer, so I'm probably getting it wrong. My data points are

- "This is in contrast to a developer choosing to use a GPL licensed
   library to create a new application, in which case the *entire*
   combined resulting application is required to be licensed under the
   GPL when distributed, to comply with section 5 of the GPL." [1]

- "The software modules that link with the library may be under various
   GPL compatible licenses, but the work as a whole must be licensed
   under the GPL." [2]

- "Files: *
   Copyright: various people
   License: BSD-3-clause" [3]

I understand that ngspice is now DFSG free. I cannot however see whether
or not the "work as a whole" (which is probably the package you
uploaded?) is licensed under the GPL. I don't know whether this is
possible or whether it makes any difference. Maybe it's trivial (today),
but it appears to be a necessity.

(It reminds me of gnutls vs openssl, both DFSG (iirc?), but still a can of
worms. That one seemed to have been the other way round, though.)

> BTW: Any reason why this thing comes now to topic and not after this bug
> report was created?

No. But the issue was mentioned in the original bug report.

thanks
felix

[1] 
https://en.wikipedia.org/wiki/GNU_Readline#Implications_of_GNU_Readline's_GPL_license
[2] https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
[3] d/copyright

Bug#834247: marked as done (ngspice is configured with --with-editline, --with-readline would work better)

[Felix Salfelder]

Dear Carsten.

It seems, now ngspice is configured --with-readline, reverting a change in
ngspice 24-1.

  * Change readline dependency to libedit-dev

I couldn't find an explanation for why this is possible now, there's only the
old paragraph from 2003

"""
Added Andrew Veliath patch for readline support. Using
readline with ngspice IS A VIOLATION OF GPL LICENSE, you
have been warned. The final decision is up to you. The
patch has been applied in the perspective of changing
readline library with libedit. Libedit aims to be a
replacement of readline and is covered by BSD license.
Libedit is available at the URL: libedit.sourceforge.net.
"""

in ngspice/ChangeLog.

Could you please explain what has changed since then? Apologies, if i am
missing something obvious.

best regards
felix

Bug#908150: ITP: gnucap-python -- Python bindings for the GNU circuit analysis package

[Felix Salfelder]

Package: wnpp
Severity: wishlist
Owner: Felix Salfelder 

* Package name: gnucap-python
  Version : 0.0.0
  Upstream Authors: Felix Salfelder ,
Henrik Johansson (-2009?)
* URL : 
http://gnucap.org/dokuwiki/doku.php/gnucap:user:gnucap_python
* License : GPLv3
  Programming Lang: C++, Python, Swig
  Description : Python bindings and command plugin for the GNU
circuit analysis package

This package implements Python bindings for the Gnucap library. It
provides a Gnucap command plugin that runs Python scripts and loads
extensions written in the Python language.
.
Gnucap is a general purpose circuit simulator. It performs nonlinear
dc and transient analyses, Fourier analysis, and ac analysis
linearized at an operating point. It is fully interactive and
command driven. It can also be run in batch mode or as a server.

> [..] also include as much relevant information as possible.
>  - why is this package useful/relevant?
>is it a dependency for another package? do you use it?

This package provides glue between a circuit simulator (Gnucap) and a
general purpose command interpreter (Python). I use it for teaching,
plotting and optimisation.

>  - if there are other packages, how does it compare?

There are other cicuit simulators, but they are all limited in their own
ways, essentially ngspice. None of them provides python bindings.

> - How do you plan to maintain it? [..] do you need a sponsor?

Will be team-maintained within the electronics team. Ruben Undheim (DD)
has offered sponsorship.

> Reasons why a new package might get rejected nevertheless
> Especially if the archive already contains analogous packages,
> following reasons might be presented
>The software is very immature (version 0.1-alpha or something like that).

This is the first release with a low version number, not 100% complete
but usable. The implementation aligns to Gnucap architecture, which is
has evolved within the last 30 years, aiming at high quality and
stability.  Further development of this package will mostly add things,
not change much of it.

> It's a simple script or very small program, and should be merged
> (either upstream or downstream) with another package.

Gnucap will always be modular. There are no plans to merge any of the
parts, especially not those with third party dependencies (such as
Python).

thanks

Bug#878364: [Pkg-electronics-devel] Bug#878364: gnucap FTCBFS: fails to find gnucap-modelgen

[Felix Salfelder]

On Fri, Oct 13, 2017 at 10:17:42AM +0200, Helmut Grohne wrote:
> gnucap cross builds successfully. Please consider applying the attached
> patch.

Thanks.

I have imported your patch, it's in the master.2009 branch.

in master, theres some other work in progress, targetting the 20171003
release...

cheers
felix

[1] alioth:/git/pkg-electronics/gnucap

Bug#830681: trilinos-all-dev: Updating binutils breaks trilinos

[Felix Salfelder]

On Mon, Jul 18, 2016 at 11:18:30AM +, Nico Schlömer wrote:
> [binutils] just turn it off
>
> @Felix Agreed?

sure, makes sense! let's postpone the static link bfd thing.

thank you
felix

Bug#830681: trilinos-all-dev: Updating binutils breaks trilinos

[Felix Salfelder]

On Sun, Jul 10, 2016 at 12:07:11PM +0200, Massimiliano Leoni wrote:
> The latest update of binutils to version 2.26.1-1 makes it imopssible to
> compile against trilinos. The linker complains
> 
> /usr/bin/ld: warning: libbfd-2.26-system.so, needed by
> 
> /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libtrilinos_teuchoscore.so,
> not found (try using -rpath or -rpath-link)

interesting. the trilinos-teuchos12 package depends on
binutils (>= 2.26), binutils (<< 2.27)

if that's correct, we shouldn't link libtrilinos_teuchoscore.so to a
particular revision of libbfd-2.26-system.so. how would that be
possible?

otoh, if libbfd-2.26.1-system.so
- is meant to replace libbfd-2.26-system.so, shouldn't there be a
  symlink?
- is NOT meant to provide libbfd-2.26-system.so, then why are these not
  coinstallable?

I'm not trying to argue that this is a bug in binutils, i just don't
understand. my idea would be to change the binutils dependency to
(=2.26), but that feels a bit silly (isn't that dependency automatic?).

cheers
felix

Bug#820903: mutt: sending mail requires live access to open mailbox (regression?)

[Felix Salfelder]

Package: mutt
Version: 1.5.24-1+b1
Severity: important

Dear Maintainer,

i am having a problem with recent mutt, which is related to network
connectivity.

- open mailbox (ssh tunnel to imapd)
- hit "reply"
- type, type ...
- network socket gets lost (i suspect a broken NAT implementation i a
router i did never use before)
- type, type ...
- send

with Mutt 1.5.21 (2010-09-15), the mail is sent via ssh $host sendmail,
through a new connection (independent to the imap tunnel). then mutt
crashes (segfault).

Mutt 1.5.24 (2015-08-30), just hangs, for (10 minutes, maybe 30). then
comes back, not having sent the mail.

i suspect that mutt tries to add "X-Status: A" to the mail i am replying
to. then depending on the mutt version, the lost connection to the
mailbox inhibits this in different ways... only after the update to
1.5.24, this annoys me.

arguably, this is not a bug, maybe even a fixed bug. however it makes
replies very cumbersome...

thanks a lot.
felix

-- Package-specific info:
Mutt 1.5.24 (2015-08-30)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.2.0-1-amd64 (x86_64)
ncurses: ncurses 6.0.20150810 (compiled with 6.0)
libidn: 1.28 (compiled with 1.32)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 -
 -with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160114 (Debian 5.3.1-6) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch
features/trash-folder.patch
features/purge-message.patch
features/imap_fast_trash.patch
features/sensible_browser_position.patch
features/compressed-folders.patch
features/compressed-folders.debian.patch
debian-specific/Muttrc.patch
debian-specific/Md.etc_mailname_gethostbyname.patch
debian-specific/use_usr_bin_editor.patch
debian-specific/correct_docdir_in_man_page.patch

Bug#802307: [Pkg-electronics-devel] Bug#802307: gnucap: No works

[Felix Salfelder]

On Mon, Oct 19, 2015 at 11:37:58AM +0200, miguel wrote:
> V1 1 0 DC 10V
> ^ ? what's this?

you are not running in spice ("batch") mode, while instanciating a spice
component. this will not work as you expect. try the -b switch to "run"
the spice deck.

gnucap without the switches is ran in interactive mode. try something
like
$ gnucap
gnucap>spice
gnucap-spice>V1 1 0 DC 10V
gnucap-spice>.list
...

> v 20130925 2
> C 4 4 0 0 0 title-B.sym
> C 44000 47700 1 90 0 resistor-1.sym
> [..]

there's some work in progress to read/write geda netlists. gnetlist (and
spice-sdb) is generally unneeded (and confusing). watch out for the
"gnucap-geda" extensions.

have fun
felix

PS: please consider the gnucap-user mailing list for questions on usage.

Bug#704782: trilinos: new package for Trilinos 11.x

[Felix Salfelder]

On Thu, Sep 17, 2015 at 05:09:42PM +0200, Graham Inggs wrote:
> I could set up a new git under debian-science.

Hi Graham.

there's a git repo already [1]. afair, the packaging branch is not
properly sync'ed with upstream. the files alone should be working on top
of some release tarball. Nico might know which one.

cheers
felix

[1] http://anonscm.debian.org/cgit/debian-science/packages/trilinos.git/

Bug#746581: mplayer2: mplayer -ao jack hangs at EOF

[Felix Salfelder]

Package: mplayer2
Version: 2.0-728-g2c378c7-1
Severity: normal

Dear Maintainer,

the jack audio output option seems to be broken in mplayer. playback works
correctly. at EOF, mplayer enters an endless loop, not producing further audio
output. my jackd2 package is from testing (1.9.9.5+20140404git3d7c67dc~dfsg-1).
the alsa output is not affected.

i suspect an upstream bug. it looks close to
http://lists.mplayerhq.hu/pipermail/mplayer-users/2006-June/061182.html,
which has been fixed in 2006.

$ mplayer -ao alsa file.mp3
[..] (works fine)
$ jackd -dalsa  # (from jackd2=1.9.9.5+20140404git3d7c67dc~dfsg-1)
$ mplayer -ao jack file.mp3
MPlayer2 2.0-728-g2c378c7-1 (C) 2000-2012 MPlayer Team
Cannot open file '/home/felix/.mplayer/input.conf': No such file or directory
Failed to open /home/felix/.mplayer/input.conf.

Playing file.mp3.
Detected file format: MP2/3 (MPEG audio layer 2/3) (libavformat)
[mp3 @ 0x7f8817859e20]max_analyze_duration reached
[mp3 @ 0x7f8817859e20]Estimating duration from bitrate, this may be inaccurate
[lavf] stream 0: audio (mp3), -aid 0
Clip info:
 comment:░░░
 genre: Other
Load subtitles in tmp/
Selected audio codec: MPEG 1.0/2.0/2.5 layers I, II, III [mpg123]
AUDIO: 22050 Hz, 2 ch, s16le, 32.0 kbit/4.54% (ratio: 4000-88200)
AO: [jack] 48000Hz 2ch floatle (4 bytes per sample)
Video: no video
Starting playback...
A:  -0.1 (unknown) of 6.3 (06.3) ??,?%░
A:   0.1 (00.0) of 6.3 (06.3)  1.3%░
A:   0.3 (00.2) of 6.3 (06.3)  1.3%░
[..]
A:   4.4 (04.3) of 6.3 (06.3)  1.3%░
A:   4.5 (04.5) of 6.3 (06.3)  1.3%░
A:   4.7 (04.7) of 6.3 (06.3)  1.3%░
A:   4.9 (04.8) of 6.3 (06.3)  1.3%░
A:   4.9 (04.8) of 6.3 (06.3)  1.3%░
A:   4.9 (04.9) of 6.3 (06.3)  1.3%░
A:   4.9 (04.9) of 6.3 (06.3)  1.3%░
A:   5.0 (04.9) of 6.3 (06.3)  1.3%░  == EOF
A:   5.0 (04.9) of 6.3 (06.3)  1.3%░
A:   5.0 (04.9) of 6.3 (06.3)  1.3%░
A:   5.0 (05.0) of 6.3 (06.3)  1.3%░
A:   5.0 (05.0) of 6.3 (06.3)  1.3%░
A:   5.1 (05.0) of 6.3 (06.3)  1.3%░
A:   5.1 (05.0) of 6.3 (06.3)  1.3%░
A:   5.1 (05.0) of 6.3 (06.3)  1.3%░
A:   5.1 (05.1) of 6.3 (06.3)  1.3%░
A:   5.1 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.1) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
A:   5.2 (05.2) of 6.3 (06.3)  1.3%░
[..]

thank you
felix

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armel
i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mplayer2 depends on:
ii  liba52-0.7.4  0.7.4-17
ii  libasound21.0.27.2-3
ii  libass4   0.10.1-3
ii  libavcodec-extra-55   6:10-2
ic  libavcodec55  6:10-2
ii  libavformat55 6:10-2
ii  libavresample16:10-2
ii  libavutil53   6:10-2
ii  libbluray11:0.5.0-2
ii  libbs2b0  3.1.0+dfsg-2
ii  libc6 2.18-4
ii  libcaca0  0.99.beta18-1.1
ii  libcdio-cdda1 0.83-4.1
ii  libcdio-paranoia1 0.83-4.1
ii  libcdio13 0.83-4.1
ii  libdca0   0.0.5-6
ii  libdirectfb-1.2-9 1.2.10.0-5
ii  libdv41.0.0-6
ii  libdvdread4   4.2.1-2
ii  libenca0  1.15-2
ii  libfaad2  2.7-8
ii  libgif4   4.1.6-11
ii  libgl1-mesa-glx [libgl1]  9.2.2-1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.9.5+20140404git3d7c67dc~dfsg-1
ii  libjpeg8  

Bug#686777: libopus-custom, temporary workaround and suggestion.

[Felix Salfelder]

Hi there.

so, this still seems to be an open problem. lets find some sort of workaround.
or at the very least deduplicate the effort of getting a locally working
jack-opus...

as it seems to be better to not pullute the shared libraries with custom
variants (no way back etc.), i think (until upstream has a better
solution), libopus-dev should just provide an additional static library
including the custom stuff. i.e. build the library twice.

here [1] is a working package (in the custom branch). with the contained
library libopus-custom.a, you can then build an opus enabled jack e.g.
from the opus branch in [2]. without further work, this will lead to
wrong/ambiguous opus symbols in shared objects using the custom libopus.
so its not ready for a release.

$ readelf -s /usr/lib/x86_64-linux-gnu/libjackserver.so.0 |grep opus
   391: 000a0d00 5 FUNCGLOBAL DEFAULT   11 
opus_custom_encoder_destr
   491: 000aa2f0  2068 FUNCGLOBAL DEFAULT   11 
opus_custom_mode_create
   521: 000a8bc0   185 FUNCGLOBAL DEFAULT   11 opus_custom_decode
   564: 000a6450   100 FUNCGLOBAL DEFAULT   11 
opus_custom_encoder_creat
   577: 000a6440 7 FUNCGLOBAL DEFAULT   11 
opus_custom_encoder_init
   801: 000a5e90  1226 FUNCGLOBAL DEFAULT   11 
opus_custom_encoder_ctl
   820: 000a8f60   151 FUNCGLOBAL DEFAULT   11 
opus_custom_decoder_init
   823: 000a7510 5 FUNCGLOBAL DEFAULT   11 
opus_custom_decoder_destr
   840: 000b2e90 8 FUNCGLOBAL DEFAULT   11 
opus_get_version_string=
   876: 000a9000   100 FUNCGLOBAL DEFAULT   11 
opus_custom_decoder_creat
  : 000a5e80 8 FUNCGLOBAL DEFAULT   11 
opus_custom_encode_float
  1338: 000a8bb0 8 FUNCGLOBAL DEFAULT   11 
opus_custom_decode_float
  1340: 000b2e6033 FUNCGLOBAL DEFAULT   11 opus_strerror
  =
  1418: 000a5e10   108 FUNCGLOBAL DEFAULT   11 opus_custom_encode
  1536: 000aa270   114 FUNCGLOBAL DEFAULT   11 
opus_custom_mode_destroy
  1853: 000a8c80   730 FUNCGLOBAL DEFAULT   11 
opus_custom_decoder_ctl
  2031: 000a74d025 FUNCGLOBAL DEFAULT   11 
opus_custom_decoder_get_s
  2420: 000a0cb037 FUNCGLOBAL DEFAULT   11 
opus_custom_encoder_get_s

rather than reinventing opus or even jack and the others, my suggestion
is to rename the non-custom symbols in the custom library before
packaging. the package then will probably be debian specific and will
still contain duplicate object code/symbols for the sake of 1ms. but in
my understanding shipping a static library is revertible enough to give
it a try.

thanks
felix

[1] git://tool.em.cs.uni-frankfurt.de/git/opus
[2] git://tool.em.cs.uni-frankfurt.de/git/jackd2


signature.asc
Description: Digital signature

Bug#720994: libppl0.12-dev: ppl.hh contains definitions which are also in gmpxx.h

[Felix Salfelder]

On Thu, Aug 29, 2013 at 08:43:09PM +0200, Roberto Bagnara wrote:
 Unless some problems are reported, this will become PPL 1.1.
 Kind regards,

You are right. it's fixed. The error message leading to the collision in
ppl.hh vs gmpxx.h was caused by a bogus mpir.h include (for whatever
reason).

sorry for the noise.

regards
felix


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

Bug#720994: libppl0.12-dev: ppl.hh contains definitions which are also in gmpxx.h

[Felix Salfelder]

On Wed, Aug 28, 2013 at 05:36:57PM +0200, Matthias Klose wrote:
 that should be fixed in the version in experimental.

If you are referring to 1.1~pre8-1, I'm afraid it's not...

thanks
felix


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

Bug#720994: libppl0.12-dev: ppl.hh contains definitions which are also in gmpxx.h

[Felix Salfelder]

Package: libppl0.12-dev
Version: 1:1.0-7
Severity: important

Dear Maintainer,

ppl.hh contains a remark about a transition concerning the numeric_limits
declaration.

/*
  [..]
  \note
  The PPL provides the specializations of the class template
  CODEnumeric_limits/CODE not only for PPL-specific numeric types,
  but also for the GMP types CODEmpz_class/CODE and
  CODEmpq_class/CODE. These specializations will be removed
  as soon as they will be provided by the C++ interface of GMP.
 */

Now, with libgmp-dev=2:5.1.2+dfsg-2, gmpxx.h contains these definitions. which
makes anything including both gmpxx.h and ppl.hh fail to build.

If you dont intend to pull in a new ppl release: for me it worked to simply
enclose the two template  class numeric_limitsmp{q,z}_class { [..] };
prototypes into #ifndef __GMP_PLUSPLUS__ .. #endif. I'd highly appreciate a
working package...

thanks
felix

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armel
i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libppl0.12-dev depends on:
ii  libppl-c4  1:1.0-7
ii  libppl12   1:1.0-7

Versions of packages libppl0.12-dev recommends:
ii  libgmp3-dev  2:5.1.2+dfsg-2

Versions of packages libppl0.12-dev suggests:
pn  libppl-doc  none

-- debconf-show failed


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

Bug#707347: sage build failure

[Felix Salfelder]

Hi there.

trying to compile/package sagelib (the core library of the sagemath project) i
am running into a similar issue.

upstream ppl might have already resolved this. from ppl.hh:
/*
  [..]
  \note
  The PPL provides the specializations of the class template
  CODEnumeric_limits/CODE not only for PPL-specific numeric types,
  but also for the GMP types CODEmpz_class/CODE and
  CODEmpq_class/CODE. These specializations will be removed
  as soon as they will be provided by the C++ interface of GMP.
 */

If you dont intend to pull in a new ppl release: for me it worked to simply
enclose the two template  class numeric_limitsmp{q,z}_class { [..] };
prototypes into #ifndef __GMP_PLUSPLUS__ .. #endif. I'd highly appreciate a
working package...

thank you
felix


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

Bug#693267: gnucap: please provide -dev package

[Felix Salfelder]

Package: gnucap
Version: 1:0.36~20091207-2
Severity: important
Tags: upstream

Dear Maintainer,

deep inside, gnucap provides support to load external modules. compiling
modules requires development headers, which should be available in a
gnucap-dev package, to expose the functionality to a debian user.

most importantly, not having headers makes it impossible to package
additional modules (see for example http://www.gnucap.org/devel for
bsim, and several *spice models).

upstream gnucap does neither provide header installation, nor support
for out-of-tree module compilation, nor a default location to look for
installed modules. the repository at
git://tool.em.cs.uni-frankfurt.de/git/gnucap_deb
contains quilt patches on top of the current gnucap package. these
implement the most important bits in a canonical way.

regards
felix

-- System Information:
Debian Release: wheezy/sid
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gnucap depends on:
ii  libc6 2.13-35
ii  libgcc1   1:4.7.1-7
ii  libreadline6  6.2-8
ii  libstdc++64.7.1-7

gnucap recommends no packages.

gnucap suggests no packages.

-- no debconf information


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

Bug#661777: acx100-source: package file gone without apparent reason

[Felix Salfelder]

On Sat, Mar 03, 2012 at 09:43:48PM +0100, Stefano Canepa wrote:
 Felix acx100-source was removed from Debian as I'm unable to maintain as
 I updated all my hardware and I need to use the old PC just to maintain
 this package. 

i'm wondering if it might be useful to retain source packages for
removed packages (well, i guess thats beyond this bug report).

 Could you be so kind to provide the URL where you found the .deb?

i do not remember. must have been some abadoned (backup of a) debian
mirror...
if you just need the .deb, take it from
http://tool.em.cs.uni-frankfurt.de/~felix/misc/acx100-source_20080210-1.2_all.deb

regards
felix



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

Bug#661777: acx100-source: package file gone without apparent reason

[Felix Salfelder]

Package: acx100-source
Version: 20080210-1.2
Severity: wishlist


while http://packages.debian.org/sid/acx100-source is up to date, the
links to acx100-source_20080210-1.2_all.deb are all quite dead.

it seems the package has been half-way removed. but this is not even
necessary:
i've found the .deb file (96f2eb220a3a8583cc17634ec8fee033c4846b00)
using an unrelated search engine, and it works (as far as i tested) on
squeeze (which is still supported, isn't it?).

regards
felix



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

Bug#619667: [imagemagick] Help

[Felix Salfelder]

On Thu, Apr 21, 2011 at 01:56:20PM +0200, Bastien ROUCARIES wrote:
 Package: imagemagick
 Version: 8:6.6.0.4-3
 
 Thanks for reporting this bug. I have no idea how to solve it, could you try 
 to help me ?

i've just checked out svn://svn.debian.org/svn/pkg-gmagick/trunk/debian
to prepare a patch against imagemagick.mime. something like

-image/avs; display avs:'%s'; test=test -n $DISPLAY; priority=2
+image/avs; display 'avs:%s'; test=test -n $DISPLAY; priority=2
(for all occuring values of avs)

unfortunately this would exactly revert the changes commited in (svn) revision 
113.
the changelog (7:6.5.9.8-1) says: 
  * Fix mime handling of filenames with spaces (Closes: #562959).
Thanks, Drew Parsons!

as I cannot reproduce problems with spaces (imagemagick 8:6.6.0.4-3, and
'avs:%s'), I suspect, bug #562959 has been fixed elsewhere.
in this case imagemagick.mime should be reverted the way I intended.
(but that's my opinion.)

also, i'd like to fix space problems, if someone tells me how to
reproduce them.

regards
felix



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

Bug#619667: imagemagick: mailcap still broken (as #589887)

[Felix Salfelder]

Package: imagemagick
Version: 8:6.6.0.4-3
Severity: important


Hello.

it seems, that a limitation (probably a bug) in mime-support=3.48-1 is
triggered (at least) by imagemagick=8:6.6.0.4-3 (squeeze):

while in lenny, imagemagick provides an update-mime input file
/usr/lib/mime/packages/imagemagick, containing lines like

image/xyz; display 'xyz:%s'; test=test -n $DISPLAY

the file shipped with squeeze, now
/usr/lib/mime/packages/imagemagick contains lines

image/xyz; display xyz:'%s'; test=test -n $DISPLAY; priority=2.

update-mime (squeeze), reading the corresponding file, for whatever
reason, outputs lines

image/xyz; display 'xyz:'%s''; test=test -n $DISPLAY;

into /etc/mailcap. for some other reason, run-mailcap (aka. see) fails
to parse this line, resulting in the error reported by Bastian
Kleineidam (#589887, archived).

while the behaviour or mime-support is certainly annoying, i see no
reason, why xyz:'%s' (squeeze) should be preferred to the previously
working version 'xyz:%s'. this issue for example affects the function
of all serious mail readers (if theres no package installed that
provides a working rule with higher priority), thus, is important.

after all, until mime-support is fixed, it would make sense to change
all occurrences of ([a-z]*):'%s' in /usr/lib/mime/packages/imagemagick
to '\1:%s'.

regards  thanks
felix

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages imagemagick depends on:
ii  libbz2-1.0  1.0.5-6  high-quality block-sorting file co
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libfontconfig1  2.8.0-2.1generic font configuration library
ii  libfreetype62.4.2-2.1FreeType 2 font engine, shared lib
ii  libglib2.0-02.24.2-1 The GLib library of C routines
ii  libgomp14.4.5-8  GCC OpenMP (GOMP) support library
ii  libice6 2:1.0.6-2X11 Inter-Client Exchange library
ii  libjpeg62   6b1-1The Independent JPEG Group's JPEG 
ii  liblcms11.18.dfsg-1.2+b3 Color management library
ii  liblqr-1-0  0.4.1-1  converts plain array images into m
ii  libltdl72.2.6b-2 A system independent dlopen wrappe
ii  libmagickcore3  8:6.6.0.4-3  low-level image manipulation libra
ii  libmagickwand3  8:6.6.0.4-3  image manipulation library
ii  libsm6  2:1.1.1-1X11 Session Management library
ii  libtiff43.9.4-5  Tag Image File Format (TIFF) libra
ii  libx11-62:1.3.3-4X11 client-side library
ii  libxext62:1.1.2-1X11 miscellaneous extension librar
ii  libxt6  1:1.0.7-1X11 toolkit intrinsics library
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages imagemagick recommends:
ii  ghostscript   8.71~dfsg2-9   The GPL Ghostscript PostScript/PDF
pn  libmagickcore3-extra  none (no description available)
ii  netpbm2:10.0-12.2+b1 Graphics conversion tools between 
pn  ufraw-batch   none (no description available)

Versions of packages imagemagick suggests:
pn  autotrace   none   (no description available)
pn  curlnone   (no description available)
ii  enscript1.6.5.2-1converts text to Postscript, HTML 
pn  ffmpeg  none   (no description available)
ii  gimp2.4.7-1  The GNU Image Manipulation Program
ii  gnuplot 4.4.0-1.1A command-line driven interactive 
pn  grads   none   (no description available)
ii  groff-base  1.20.1-10GNU troff text-formatting system (
pn  hp2xx   none   (no description available)
pn  html2ps none   (no description available)
pn  imagemagick-doc none   (no description available)
pn  libwmf-bin  none   (no description available)
ii  lprng [lpr] 3.8.A-3  lpr/lpd printer spooling system
ii  mplayer 2:1.0~rc3++final.dfsg1-1 movie player for Unix-like systems
ii  povray  1:3.6.1-12   Persistence of vision raytracer (3
pn  radiancenone   (no description available)
pn  sane-utils  none   (no description available)
ii  texlive-binarie 2009-8   Binaries for TeX Live
pn  transfignone   (no description available)
ii  xdg-utils   1.0.2+cvs20100307-2  

Bug#596565: libasound2-plugins: jack plugin stops working after few seconds

[Felix Salfelder]

Package: libasound2-plugins
Version: 1.0.23-1+b1
Severity: normal

Hi.

following the instructions in
/usr/share/doc/libasound2-plugins/README-jack
i've set up an alsa-jack connection.

this basically works, but playback stops after about 10 seconds. with
the attached .asoundrc in ~ i've used the commands
jackd -v -dalsa -dhw:0 -P
mplayer -ao alsa some.audio.file

note that sound always stops after a fixed duration. this duration can
be controlled using the -p switch of jackd.

note also that sending alsa-jack-alsa-hw:0 is not what i'm intending
to do. but this triggers the bug.

thank you
felix

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libasound2-plugins depends on:
ii  libasound2 1.0.23-1  shared library for ALSA applicatio
ii  libavcodec52   5:0.6~svn20100726-0.0 library to encode decode multimedi
ii  libc6  2.11.2-2  Embedded GNU C Library: Shared lib
ii  libjack-jackd2-0 [ 1.9.5~dfsg-19 JACK Audio Connection Kit (librari
ii  libpulse0  0.9.21-3+b1   PulseAudio client libraries
ii  libsamplerate0 0.1.7-3   Audio sample rate conversion libra
ii  libspeexdsp1   1.2~rc1-1 The Speex extended runtime library

libasound2-plugins recommends no packages.

libasound2-plugins suggests no packages.

-- no debconf information
pcm.!default {
type plug
slave { pcm jackdevice }
}

pcm.onboard {
type hw
card 0
device 0
}

pcm.jackdevice {
type jack
playback_ports {
0 system:playback_1
1 system:playback_2
}
capture_ports {
0 system:capture_1
1 system:capture_1
}
}

Bug#596427: evilwm: switching to another wm isnt documented (annoying bug or intended feature?)

[Felix Salfelder]

Package: evilwm
Version: 1.0.0-1
Severity: wishlist
Tags: upstream

common windowmanagers allow users to switch to different ones.
i happened to switch to evilwm, but then had to kill my xsession to get
back.

the manual states that exiting evilwm is done by killing it. so i'm not
sure whether this is intended behaviour. if so, i suggest to make this
more explicit in the BUGS section of the man page.

thanks for considering this thought
felix

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages evilwm depends on:
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libx11-6  2:1.3.3-3  X11 client-side library
ii  libxext6  2:1.1.2-1  X11 miscellaneous extension librar
ii  libxrandr22:1.3.0-3  X11 RandR extension library

evilwm recommends no packages.

evilwm suggests no packages.

-- no debconf information



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

Bug#594989: nut: mge-utalk driver doesnt compensate UPS refusing to set LowBatt

[Felix Salfelder]

Package: nut
Version: squeeze
Severity: normal
Tags: patch


I got the following ups:

ups.id: EXtreme 3000 250
ups.mfr: MGE UPS SYSTEMS
ups.model: EXtreme 3000

it reports the following values

driver.parameter.LowBatt: 50
battery.charge.low: 20

the first value is due to the LowBatt setting in ups.conf, the second
probably because the UPS refuses to change it. initups: Low Battery
Level cannot be set is what the driver outputs with -D set.

The problem is, that, when discharging the UPS, the transition OB - LB
comes in too late.

The attached patch makes mge-utalk catch this condition:
in the described case it reads the battery level instead of the status
bit and set_status(LB) when it makes sense.
its quite a hack, but not changing anything when LowBatt is not
set or the UPS behaves as it should.

thank you.
felix
--- mge-utalk-orig.c2010-08-31 09:29:56.0 +0200
+++ mge-utalk.c 2010-08-31 09:46:01.0 +0200
@@ -50,6 +50,9 @@
  * 
  * enable_ups_comm() is called before each attempt to read/write data
  * from/to the UPS to re synchronise the communication.
+ *
+ * If the UPS refuses to set the LowBatt level at startup as configured,
+ * the reported LB status bit will be derived from the current battery level.
  */
 
 #include ctype.h
@@ -58,13 +61,14 @@
 #include main.h
 #include serial.h
 #include mge-utalk.h
+#include stdbool.h
 
 /* --- */
 /*  Define technical constants   */
 /* --- */
 
 #define DRIVER_NAMEMGE UPS SYSTEMS/U-Talk driver
-#define DRIVER_VERSION 0.89
+#define DRIVER_VERSION 0.89-lowbatt
 
 
 /* driver description structure */
@@ -102,6 +106,7 @@ upsdrv_info_t upsdrv_info = {
 #define SD_STAYOFF 1
 
 int sdtype = SD_RETURN;
+bool LB_trust_ups = true;
 static time_t lastpoll; /* Timestamp the last polling */
 
 /* --- */
@@ -185,7 +190,10 @@ void upsdrv_initups(void)
if(!strcmp(buf, OK))
upsdebugx(1, Low Battery Level set to %d%%, 
mge_ups.LowBatt);
else
+   {
upsdebugx(1, initups: Low Battery Level cannot be 
set);
+   LB_trust_ups = false;
+   }
}
 
 /* Try to set ON delay (if supported and given) */
@@ -269,7 +277,8 @@ void upsdrv_initinfo(void)
if(bytes_rcvd  0  buf[0] != '?') {
  upsdebugx(1, initinfo: Si == %s, buf);
 
- printf(\nCAUTION : This is an older model. It may 
not support too much polling.\nPlease read man mge-utalk and use 
pollinterval\n);
+ printf(\nCAUTION : This is an older model. It may 
not support too much polling.\n
+ Please read man mge-utalk and use 
poll_interval\n);
 
  p = strchr(buf, ' ');
 
@@ -296,8 +305,8 @@ void upsdrv_initinfo(void)
  }
 
  if( model == NULL )
-   printf(No model found by that model and 
version ID\nPlease contact us with UPS model, name and reminder info\nReminder 
info : Data1=%i , Data2=%i\n, si_data1, si_data2);
-
+   printf(No model found by that model and 
version ID\nPlease contact us with UPS model,
+name and reminder 
info\nReminder info : Data1=%i , Data2=%i\n, si_data1, si_data2);
}
  }
 
@@ -686,7 +695,36 @@ static void extract_info(const char *buf
 }
 
 
+/* --- */
+/* use reported level to calculate status */
+bool LB_by_level(){
+   char buf[BUFFLEN];
+   char infostr[32];
+   mge_info_item_t level_item = mge_info[0];
+   int chars_rcvd = mge_command(buf, sizeof(buf), level_item.cmd);
+
+   if ( chars_rcvd  1 || buf[0] == '?' ) {
+   return(true); // to be sure...
+   } else {
+   level_item.ok = TRUE;
+   extract_info(buf, level_item, infostr, sizeof(infostr));
+   dstate_setinfo(level_item.type, infostr);
+   dstate_setflags(level_item.type, level_item.flags);
+   upsdebugx(1, initinfo: %s == %s, level_item.type, infostr);
+
+   /* Set max length for strings */
+   if (level_item.flags  ST_FLAG_STRING)
+   dstate_setaux(level_item.type, level_item.length);
+   if ( atoi( getval (lowbatt) )  atoi(infostr)) {
+   upsdebugx(1, not lowbatt %s, infostr );
+   return(false);
+   }else {
+   upsdebugx(1, lowbatt %s, infostr );
+   return(true);
+   }
 
+   }
+}
 /* 

Bug#585173: ifupdown: wkan rf killswitch doesnt trigger ifup/down

[Felix Salfelder]

Package: ifupdown
Version: 0.6.10
Severity: wishlist

Hi

some wlan drivers trigger uevents, whenever the user presses/toggles the
rf killswitch. if would make perfect sense to hand this over to
ifup/down if this is wanted by the user.

i suggest putting a file, say 99-rfkill.rules, containing the following
lines (or similar) into /etc/udev/rules.d/.

ACTION==change, \
ENV{RFKILL_TYPE}==wlan, ENV{RFKILL_STATE}==1,SUBSYSTEM==rfkill, \
RUN+=/sbin/ifup --allow=rfkill wlan0

ACTION==change, \
ENV{RFKILL_TYPE}==wlan, ENV{RFKILL_STATE}==2,SUBSYSTEM==rfkill, \
RUN+=/sbin/ifdown --allow=rfkill wlan0

this reduces te configuation overhead of the end user to adding
allow-rfkill wlan0 to her interface file, and doesnt do any harm to
someone who doesnt like it.

unfortunately, i am lacking a method to find the correct ifname (wlan0
here). i leave this open, since i dont have many rfkill switches to test
anyway. the proposed rules work with Intel N WiFi Link 5300 (iwlagn)

Thank you
felix

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ifupdown depends on:
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib
ii  lsb-base  3.2-23.1   Linux Standard Base 3.2 init scrip
ii  net-tools 1.60-23The NET-3 networking toolkit

ifupdown recommends no packages.

Versions of packages ifupdown suggests:
ii  dhcp3-client  3.1.3-2DHCP client
ii  iproute   20100224-5 networking and traffic control too
pn  ppp   none (no description available)

-- no debconf information



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

Bug#584170: remind: does not resolve tilde in include file path

[Felix Salfelder]

Package: remind
Version: 03.01.05-2
Severity: normal
Tags: patch

Hi.

putting INCLUDE ~/.somethingelse into ~/.reminders yields
.reminders(1): Can't open file: ~/.somethingelse when executing
remind -c .reminders.

this seems like a bug to me, since ~ is where a user probably wants to
put his reminders...

the attached patch simply replaces ^~ by $HOME just before fopen is
called. i hope it's not too much a hack...

regards
felix

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-7-owl (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages remind depends on:
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib

remind recommends no packages.

Versions of packages remind suggests:
ii  tkremind  03.01.05-2 Tk GUI interface to remind
ii  wyrd  1.4.4-1text-based calendar application

-- no debconf information
--- src.orig/files.c	2008-03-25 04:12:37.0 +0100
+++ src/files.c	2010-06-02 00:53:33.715406754 +0200
@@ -1,3 +1,4 @@
+//  vim:ts=8:sw=4:
 /***/
 /* */
 /*  FILES.C*/
@@ -239,8 +240,18 @@ int OpenFile(char const *fname)
 	if (DebugFlag  DB_TRACE_FILES) {
 	fprintf(ErrFp, Reading `-': Reading stdin\n);
 	}
+/* Resolve tilde */
 } else {
-	fp = fopen(fname, r);
+	if( fname[0] == '~' ) { 
+	char* home = getenv(HOME);
+	int n = strlen(fname) + strlen(home);
+	char* fnametmp = (char*) malloc( n*sizeof(char) );
+	sprintf( fnametmp, %s%s, home, fname+1 );
+	fp = fopen(fnametmp, r);
+	free(fnametmp);
+	} else {
+	fp = fopen(fname, r);
+	}
 	if (DebugFlag  DB_TRACE_FILES) {
 	fprintf(ErrFp, Reading `%s': Opening file on disk\n, fname);
 	}

Bug#581615: supplied initramfs-tools scripts dont work if $udev_root != /dev

[Felix Salfelder]

Hi Marco.

On Fri, May 14, 2010 at 01:19:53PM +0200, Marco d'Itri wrote:
 Changing $udev_root has never been properly tested or documented,
 considering the recent focus on devtmpfs I do not believe that it will
 continue to work for a long time no matter how many hacks I could add.

i respect Your expertise and Your efforts to keep udev running.
anyway what you claim here is plain wrong. let me explain:

- the testing of a non-default value for $udev_root has taken place.
  i can at least speak for myself, having changed this setting shortly
  after i encountered udev. as i wansn't involved in fixing the
  /etc/init.d/udev{,-mtab} scripts i conclude that theres somebody else
  caring about $udev_root.

- in fact $udev_root is documented. don't You ship the manpage?
  i confirm that it is working as described in this manpage.

- the move from /dev to $rootmnt$udev_root does hardly change when
  switching from tmpfs to devtmpfs. this will continue to work whatever
  filesystem will be used for udev in furure releases.

- You mistook my work as a 'hack'. this is the cleanest possible way to
  get the initramfs-tool make its job and leave behind a system as the
  user wishes -- just like yaird does (did with kernels = 2.6.30)
  to fix this later on (after chroot) would be a serious hack.

- udev_root does not occur in init-top/udev or init-bottom/udev scripts.
  so obviously this is not about how many hacks are involved here.

could You explain why You are opposed to allow the user to choose for
himself? If there's already a discussion on this, please redirect me.

Your strategy about removing every trace of $udev_root doesnt sound
amusing.
I'd really hope You take some time and rethink this point.

regards
felix



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

Bug#581615: supplied initramfs-tools scripts dont work if $udev_root != /dev

[Felix Salfelder]

Package: udev
Version: 154-1
Severity: important
Tags: patch


Hi,

Just recently i switched to initramfs-tools, so the bug i'm reporting
might be rather old. But i didnt find any references.

As i understand the $udev_root option it helps keeping udev out of /dev.
since /etc/init.d/udev and udevd itself respect this option, i conclude
that it makes sense to fix the initramfs-tools part as well.

Currently, changing $udev_root in udev.conf somewhat messes up the
initrd made by update-initramfs:
- udev resides (half way?) in $udev_root, while devices are looked for
  in /dev. depending on how the root device is adressed, this ends in a
  debug shell.
- before chroot, $rootmnt/dev is messed up regeardless of the setting of
  $udev_root. this is unfortunate when a static /dev is in use

The attached patch forces udev to live in /dev before chroot regardless of the
$udev_root setting (init-top/udev). but then it is moved to where the user
specified, to $rootmnt$udev_root (init-bottom/udev).

i'd be happy if this could be merged.

regards
felix

-- System Information:
Debian Release: squeeze
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-4-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages udev depends on:
ii  debconf [debconf-2.0]1.5.32  Debian configuration management sy
ii  libc62.10.2-6Embedded GNU C Library: Shared lib
ii  libselinux1  2.0.94-1SELinux runtime shared libraries
ii  libusb-0.1-4 2:0.1.12-14 userspace USB programming library
ii  lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip
ii  util-linux   2.16.2-0Miscellaneous system utilities

Versions of packages udev recommends:
ii  pciutils  1:3.1.7-3  Linux PCI Utilities
ii  usbutils  0.87-1 Linux USB utilities

udev suggests no packages.

-- Configuration Files:
/etc/udev/udev.conf changed:
udev_log=err
tmpfs_size=10M
udev_root=/etc/udev/.dev


-- debconf information excluded
diff -rupN itramfs-tools.orig/scripts/init-bottom/udev initramfs-tools/scripts/init-bottom/udev
--- initramfs-tools.orig/scripts/init-bottom/udev	2010-05-13 16:28:24.0 +0200
+++ initramfs-tools/scripts/init-bottom/udev	2010-05-14 01:09:38.0 +0200
@@ -21,10 +21,15 @@ for proc in /proc/[0-9]*; do
   fi
 done
 
+udev_root=/dev
+if [ -e /etc/udev/udev.conf ]; then
+. /etc/udev/udev.conf
+fi
+
 # move the /dev tmpfs to the rootfs
-mount -n -o move /dev $rootmnt/dev
+mount -n -o move /dev $rootmnt$udev_root
 
 # create a temporary symlink to the final /dev for other initramfs scripts
 nuke /dev
-ln -s $rootmnt/dev /dev
+ln -s $rootmnt/$udev_root /dev
 
diff -rupN initramfs-tools.orig/scripts/init-top/udev initramfs-tools/scripts/init-top/udev
--- initramfs-tools.orig/scripts/init-top/udev	2010-05-13 16:28:24.0 +0200
+++ initramfs-tools/scripts/init-top/udev	2010-05-14 01:06:01.0 +0200
@@ -13,7 +13,7 @@ esac
 
 echo  /sys/kernel/uevent_helper
 
-udevd --daemon --resolve-names=never
+UDEV_ROOT=/dev udevd --daemon --resolve-names=never
 
 mkdir -p /dev/.udev/queue/
 udevadm trigger --action=add

Bug#572972: hibernate: FindXServer depends on 'last', depends on '/var/log/wtmp', which might not exist (intentionally)

[Felix Salfelder]

Package: hibernate
Version: 1.99-1.1
Severity: important
Tags: patch


Hi all.

XFindServer is reading /var/log/wtmp to find X sessions. But it is
common practice not to have this wtmp file. e.g. to decrease write
access to the root file system. And it is common practice to have a
tmpfs mounted on /var/run, where utmp resides.

/var/run/utmp seems to be perfectly suited for finding xusers and their
$DISPLAYs. the attached patch replaces 'last' by 'w'. w reads the utmp
file.

As far a I understand, XFindServer is meant to find only one xsession.
this doesn't seem to be easily fixed, but with the patch a log message is
triggered in case multiple displays are in use. (see hibernate.log below)

I hope the patch is useful and doesn't break too much.

regards
felix

PS: unfortunately this leaves open #370787, since w also has an 8
character limit (although utmp contains the complete names).

-- Package-specific info:
--- configuration
== /etc/hibernate/common.conf ==
Verbosity 10
LogFile /var/log/hibernate.log
LogVerbosity 10
Distribution debian
SaveClock restore-only
LockXtrLock yes
UnloadBlacklistedModules yes
LoadModules auto
SwitchToTextMode yes
== /etc/hibernate/disk.conf ==
TryMethod ususpend-disk.conf
TryMethod sysfs-disk.conf
== /etc/hibernate/hibernate.conf ==
TryMethod suspend2.conf
TryMethod disk.conf
TryMethod ram.conf
== /etc/hibernate/ram.conf ==
TryMethod ususpend-ram.conf
TryMethod sysfs-ram.conf
== /etc/hibernate/suspend2.conf ==
UseSuspend2 yes
Reboot no
EnableEscape yes
DefaultConsoleLevel 1
Compressor lzf
Encryptor none
FullSpeedCPU yes
Include common.conf
== /etc/hibernate/sysfs-disk.conf ==
UseSysfsPowerState disk
Include common.conf
== /etc/hibernate/sysfs-ram.conf ==
UseSysfsPowerState mem
Include common.conf
== /etc/hibernate/ususpend-both.conf ==
USuspendMethod both
Include common.conf
== /etc/hibernate/ususpend-disk.conf ==
USuspendMethod disk
Include common.conf
== /etc/hibernate/ususpend-ram.conf ==
USuspendMethod ram
Include common.conf

--- /sys/power
== /sys/power/disk ==
[platform] test testproc shutdown reboot 
== /sys/power/image_size ==
524288000
== /sys/power/resume ==
0:0
== /sys/power/state ==
mem disk

--- s2ram -n
Machine unknown
This machine can be identified by:
sys_vendor   = 
sys_product  = 
sys_version  = 
bios_version = 
--- log
Starting suspend at Sun Mar 7 21:56:59 CET 2010
hibernate: [01] Executing CheckLastResume ...
hibernate: [01] Executing CheckRunlevel ...
hibernate: [01] Executing LockFileGet ...
hibernate: [01] Executing NewKernelFileCheck ...
hibernate: [10] Executing EnsureSysfsPowerStateCapable ...
hibernate: [11] Executing XHacksSuspendHook1 ...
hibernate: [59] Executing RemountXFSBootRO ...
hibernate: [89] Executing SaveKernelModprobe ...
Saved /proc/sys/kernel/modprobe is /sbin/modprobe
hibernate: [91] Executing ModulesUnloadBlacklist ...
Unloading blacklisted modules listed /etc/hibernate/blacklisted-modules
Module version for ipw2100 is
Module version for ipw2200 is
Module version for snd_bt_sco is
Module version for ndiswrapper is
hibernate: [91] Executing ModulesUnloadBlacklist ...
Unloading blacklisted modules listed /etc/hibernate/blacklisted-modules
Module version for ipw2100 is
Module version for ipw2200 is
Module version for snd_bt_sco is
Module version for ndiswrapper is
hibernate: [95] Executing XHacksSuspendHook2 ...
xhacks: changing console from 7 to 15
hibernate: [98] Executing CheckRunlevel ...
hibernate: [99] Executing DoSysfsPowerStateSuspend ...
hibernate: Activating sysfs power state disk ...
hibernate: [91] Executing LockXtrlock ...
hibernate skipping :0.0,felix in favour of :1.0,felix (stupid?)
Trying xtrlock
Locking felix's xtrlock on display :1.0 using authority file 
/home/felix/.Xauthority
hibernate: [90] Executing ModulesLoad ...
hibernate: [89] Executing RestoreKernelModprobe ...
hibernate: [85] Executing XHacksResumeHook2 ...
xhacks: changing console back to 7
hibernate: [70] Executing ClockRestore ...
hibernate: [70] Executing ClockRestore ...
hibernate: [59] Executing RemountXFSBootRW ...
hibernate: [11] Executing XHacksResumeHook1 ...
hibernate: [01] Executing NoteLastResume ...
hibernate: [01] Executing LockFilePut ...
Resumed at Sun Mar 7 21:57:09 CET 2010

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-7-owl (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages hibernate depends on:
ii  console-tools1:0.2.3dbs-65.1 Linux console and font utilities

Versions of packages hibernate recommends:
ii  dash  0.5.5.1-2  POSIX-compliant shell
ii  hdparm8.9-3  tune hard disk parameters for high
ii  uswsusp   0.8-1.2tools to use userspace software su
ii  vbetool   1.0-3  run real-mode video BIOS code to a

Bug#540713: nautilus-open-terminal: does not depend on gnome-terminal, but doesnt respect alternatives either

[Felix Salfelder]

Package: nautilus-open-terminal
Version: 0.8-2
Severity: normal

The program in question tries to spawn a gnome-terminal upon mouse-clicking.
This does make perfectly no sense, if gnome-terminal is not installed.
The dependency is missing.

The current testing version (0.16-1) does not depend on it either. One
could suspect that it has learned to repect /etc/alternatives but a
grep for 'alternatives' does not convince me.

Needless to say, that this package wasn't necessary if nautilus did not
refuse to execute something similar to xterm -c cd %s; bash (which is
another story).

regards
Felix

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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