Bug#1077976: puppetdb's autopkg tests fail with OpenJDK 21

[Jérôme Charaoui]

Hello,

Le 2024-08-05 à 07 h 48, Matthias Klose a écrit :

Tests fail with:

201s autopkgtest [17:10:41]:  summary
201s standalone   FAIL stderr: warn: JDK 21.0.4 is neither 
tested nor supported. Please use JDK 17


I'm not sure about the value of such a test ... instead of testing that 
the software works.


Obviously, the test is not only checking which JDK version is running.

PuppetDB is simply emitting a warning about that on stderr, and the test 
is just missing "Restriction: allow-stderr".


I'll fix that in the next upload.

-- Jérôme

Bug#1070745: Bug#1070730 etc.: libglib2.0-0: ibus input regression

[Jérôme Charaoui]

On Wed, 8 May 2024 13:03:51 +0100 Simon McVittie  wrote:

On Wed, 08 May 2024 at 03:48:21 +, unfathomabl...@protonmail.com wrote:
> Latest upgrade from 2.74.6-2 to 2.74.6-2+deb12u1 broke input of Japanese
> characters GTK programs (such as firefox, gedit etc).

For users of testing/unstable, this will be fixed as soon as I can,
probably by version 2.80.1-1. Each GLib build takes around an hour,
plus the time required for testing, so it is not possible to fix this
instantaneously.

For users of Debian 12 'bookworm', a test-build of a fix for this
regression is available here: https://people.debian.org/~smcv/bug1070730/
(amd64 + i386 + source)


I can confirm these builds fix the input issues reported here on my system.

Thank you for moving so fast on this,

-- Jérôme

Bug#1069192: Autopkgtest failure: missing dependency on python3-pytz

[Jérôme Charaoui]

Hi Nilesh,

Le 2024-04-18 à 06 h 24, Nilesh Patra a écrit :

I will NMU this in a week or so if I see no activity. This package has been
going through in-attention for a while.


Please, you may upload the fix whenever you wish, it's fine with me.

-- Jérôme

Bug#1067209: marked as pending in jruby

[Jérôme Charaoui]

Control: tag -1 pending

Hello,

Bug #1067209 in jruby reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/java-team/jruby/-/commit/1e0e33a4429ec76990cb8729df7e4b7bde33abb4


d/control: update libfixposix4 runtime depency

libfixposix4 was renamed to libfixposix4t64

Closes: #1067209


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1067209

Bug#1042314: closing 1042314

[Jérôme Charaoui]

close 1042314 8.4.0-1
thanks

I believe this bug is now fixed in the latest version of jruby and puppetserver
uploaded to sid.

Thanks,

-- Jérôme

Bug#1064686: vagrant-librarian-puppet: FTBFS

[Jérôme Charaoui]

Hello,

I think this package should be removed from Debian.

In addition to the FTBFS issues:

- Project appears to be abandoned upstream, last commit was 6 years ago

- The future of Vagrant in Debian is in serious doubt (see #104)

- It's currently blocking the transition of the latest puppet-agent 
package in Debian


I'm not a maintainer or uploader of this package, so if someone feels 
like they're wearing one of those hats, please file a removal request [0].


Thanks,

-- Jérôme


[0] https://wiki.debian.org/ftpmaster_Removals#How_to_request_removal

Bug#1025078: closing 1025078

[Jérôme Charaoui]

close 1025078 5.0.3-1
thanks

With now both ruby-faraday and ruby-puppet-forge up to date in sid, this issue
is solved.

Bug#1064295: puppet-agent: ununsatisfiable dependencies: depends on ruby-concurrent (< 1.2.0)

[Jérôme Charaoui]

Hello,

On Mon, 19 Feb 2024 20:38:19 +0100 Aurelien Jarno  
wrote:

puppet-agent in unstable is not installable anymore as it depends on
ruby-concurrent (< 1.2.0), while the version in unstable is now 1.2.3-2.


Yes, I'm aware. puppet-agent 8.4.0, which works with ruby-concurrent >= 
1.2.0, is now available in experimental.


It's working for me, but I'm waiting on some feedback before uploading 
it to unstable.


Thanks,

-- Jérôme

Bug#1033316: Autopkgtest is flaky

[Jérôme Charaoui]

Control: tags -1 + confirmed
Control: owner -1 !


Hello,

I'm preparing an update for this package which should fix the issue.

Thanks,

-- Jérôme

Bug#1058702: pius fails completely on bookworm and up

[Jérôme Charaoui]

On Thu, 14 Dec 2023 14:32:45 -0500 Antoine Beaupre  
wrote:> pius: error: GnuPG binary not found at /usr/bin/gpg2.


gpg2 hasn't been around for a long time. but maybe we can work around
this with:


Yeah I would also like like to see this patched.


pius: error: Keyring /home/anarcat/.gnupg/pubring.gpg doesn't exist

Nope! That doesn't work either! I have not dared to use the --keyring
argument to correct `.gnupg/pubring.kbx` keyring, for fear of
corruption, but clearly something is wrong here.


FWIW I've used --keyring and it didn't seem to corrupt the keyring or do 
anything bad, but you can also test it yourself on a copy of your 
keyring, the signatures thus produces will be just as valid.


Another thing that would be nice to fix upstream, or in the package at 
least.


-- Jérôme

Bug#1055049: libtakari-polyglot-groovy-java: missing Breaks+Replaces: libtakari-polyglot-maven-java (<< 0.4.11-2)

[Jérôme Charaoui]

Le 2023-12-09 à 17 h 29, tony mancill a écrit :

On Sat, Dec 09, 2023 at 04:39:35PM -0500, Jérôme Charaoui wrote:

On Mon, 30 Oct 2023 09:37:34 +0100 Andreas Beckmann  wrote:

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

 From the attached log (scroll to the bottom...):

   Preparing to unpack .../libtakari-polyglot-groovy-java_0.4.11-2_all.deb ...
   Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ...
   dpkg: error processing archive 
/var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb 
(--unpack):
trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is 
also in package libtakari-polyglot-maven-java 0.4.11-1
   Errors were encountered while processing:
/var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb


Thanks for the heads up.

I'm not sure what's happening here: polyglot-groovy-0.4.11.jar was indeed
split away from "libtakari-polyglot-maven-java" and into
"libtakari-polyglot-groovy-java", however the new version of
"libtakari-polyglot-maven-java" does *not* depend on/recommend
"libtakari-polyglot-groovy-java".

So I'm unsure why "libtakari-polyglot-groovy-java" is being installed in the
first place, during the piuparts upgrade. It's not present in testing, and
it has currently zero reverse-dependencies.

I did my own testing and on a bare system with
"libtakari-polyglot-maven-java" installed, upgrading to sid does not include
an installation of "libtakari-polyglot-groovy-java".

Any idea what's going on?


Hi Jérôme,

I believe you're correct that in the normal upgrade case, this is
unlikely to occur.  Here's the test case I ran instead a clean trixie
chroot:

1. Install libtakari-polyglot-maven-java (0.4.11-1)
2. Update sources.list to unstable and then apt-get update
3. apt-get -y install libtakari-polyglot-groovy-java

Step (3) will upgrade libtakari-polyglot-maven-java to 0.4.11-2 *before*
installing libtakari-polyglot-groovy-java, so there's no problem.


However, the issue can occur when using dpkg directly, or some other
factor influences the ordering such that libtakari-polyglot-groovy-java
is installed *before* libtakari-polyglot-maven-java is upgraded.

For example:

1. Install libtakari-polyglot-maven-java (0.4.11-1)
2. wget 
http://ftp.us.debian.org/debian/pool/main/t/takari-polyglot-maven/libtakari-polyglot-groovy-java_0.4.11-2_all.deb
3. dpkg -i libtakari-polyglot-groovy-java_0.4.11-2_all.deb

Preparing to unpack libtakari-polyglot-groovy-java_0.4.11-2_all.deb ...
Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ...
dpkg: error processing archive libtakari-polyglot-groovy-java_0.4.11-2_all.deb 
(--install):
  trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is 
also in package libtakari-polyglot-maven-java 0.4.11-1
Errors were encountered while processing:
  libtakari-polyglot-groovy-java_0.4.11-2_all.deb


This is the reason that the relationship needs to be explicit.

I'm not 100% certain, but perhaps we can get away with only adding a
versioned depends on libtakari-polyglot-maven-java (>= 0.4.11-2) to the
libtakari-polyglot-groovy-java package.  The problem as I see it is that
the current unversioned Depends can be satisfied by any version of
libtakari-polyglot-maven-java, including older versions with the file
conflict.  Requiring the newer libtakari-polyglot-maven-java would
prevent this.


Ok what I think I'll do is to add: "Breaks: 
libtakari-polyglot-maven-java (<< 0.4.11-2)" to 
libtakari-polyglot-groovy-java. I think that's more explicit than a 
versioned depends, and should prevent any instances of users 
accidentally having wrong versions of the two packages.


-- Jérôme

Bug#1055049: libtakari-polyglot-groovy-java: missing Breaks+Replaces: libtakari-polyglot-maven-java (<< 0.4.11-2)

[Jérôme Charaoui]

On Mon, 30 Oct 2023 09:37:34 +0100 Andreas Beckmann  wrote:

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

From the attached log (scroll to the bottom...):

  Preparing to unpack .../libtakari-polyglot-groovy-java_0.4.11-2_all.deb ...
  Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb 
(--unpack):
   trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is 
also in package libtakari-polyglot-maven-java 0.4.11-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb


Thanks for the heads up.

I'm not sure what's happening here: polyglot-groovy-0.4.11.jar was 
indeed split away from "libtakari-polyglot-maven-java" and into 
"libtakari-polyglot-groovy-java", however the new version of 
"libtakari-polyglot-maven-java" does *not* depend on/recommend 
"libtakari-polyglot-groovy-java".


So I'm unsure why "libtakari-polyglot-groovy-java" is being installed in 
the first place, during the piuparts upgrade. It's not present in 
testing, and it has currently zero reverse-dependencies.


I did my own testing and on a bare system with 
"libtakari-polyglot-maven-java" installed, upgrading to sid does not 
include an installation of "libtakari-polyglot-groovy-java".


Any idea what's going on?

Thanks,

-- Jérôme

Bug#1052722: closing 1052722

[Jérôme Charaoui]

close 1052722 2.6.0-1
thanks

Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol

[Jérôme Charaoui]

Le 2023-11-25 à 06 h 30, Miguel Landaeta a écrit :

On Sat, Nov 25, 2023 at 12:29 AM Jérôme Charaoui  wrote:


[...]

I've been working on a 9.4 release, you can see the progress here:
https://salsa.debian.org/lavamind/jruby

I plan to upload this version to experimental within a few days, I still
have some minor issues with the testsuite to iron out before.


Excellent, that's good to hear.
There is no point then just backporting the fix if you are close to
finishing preparing an upload.

Let me know if there is something else I can help with.
I think I'll take a look at some jnr-* dependencies packages that
could use a new upstream release and/or bugfixes.


For the record, the upload is ready to go. I'm now only waiting for a 
new build-dependency to pass through NEW, jruby-mavengem.

Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol

[Jérôme Charaoui]

Hi Miguel,

Le 2023-11-24 à 18 h 38, Miguel Landaeta a écrit :

Thomas and Jérôme,

Do you have any concerns with me uploading a fix for this issue?

I'm working with some folks here in Cambridge MiniDebConf and I
also have some cycles to spare to work on JRuby and maybe prepare
a new upstream release for 9.3 and/or 9.4 series (experimental).


I've been working on a 9.4 release, you can see the progress here: 
https://salsa.debian.org/lavamind/jruby


I plan to upload this version to experimental within a few days, I still 
have some minor issues with the testsuite to iron out before.


Thanks,

-- Jérôme

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Jérôme Charaoui]

On Wed, 7 Jun 2023 18:47:02 +0530 Utkarsh Gupta 
 wrote:> I've prepared a fix for the 
regression and uploaded the binaries at:

https://people.debian.org/~utkarsh/lts/ruby2.5/

Can you please give these a try and see if that fixes the regression
you're seeing?


These packages also fix the Puppet regression reported here, on our 
buster systems.


Thanks,

-- Jérôme

Bug#1034824: tomcat9 should not be released with Bookworm

[Jérôme Charaoui]

Le 2023-05-25 à 17 h 41, Martin Hostettler a écrit :


Quoting from J�r�me Charaoui in (#1036250):

I did further tests with puppetserver, which is a downstream dependency
of trapperkeeper-webserver-jetty9-clojure and unfortunately, the web
requests (access) logging remains broken. There are no warnings or error
messages anywhere: as you can imagine, the logging events are simply
lost in the ether.

I'm not sure if the latest patches from 2023-05-22 do fix those, but there
was no follow up on the bug with details.


For the record, these patches only fix the build issue and work around 
the test failures by disabling the affected tests.


The logging problem is still present in puppetserver (and almost 
certainly puppetdb) with the patched 
trapperkeeper-webserver-jetty9-clojure package.


Thanks,

-- Jérôme

Bug#1034855: trapperkeeper-webserver-jetty9-clojure: autopkgtest regression: Cannot invoke "Object.toString()" because "s" is null

[Jérôme Charaoui]

This problem is caused by a recent patch shipped by the liblogback-java 
package, specifically this line, which causes log events to be silently 
ignored:


https://salsa.debian.org/java-team/logback/-/blob/master/debian/patches/tomcat10-migration.patch#L91

See the discussion in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036250


In my view this is a bug in src:logback.

-- Jérôme

Bug#1036250: trapperkeeper-webserver-jetty9-clojure: FTBFS in testing: MDCAccessLogConverter.java:54: error: cannot access HttpServletRequest

[Jérôme Charaoui]

Hi Markus,

Thank you, your patch does indeed fix the build problem for this 
package, however, the test failure is not insignificant.


I did further tests with puppetserver, which is a downstream dependency 
of trapperkeeper-webserver-jetty9-clojure and unfortunately, the web 
requests (access) logging remains broken. There are no warnings or error 
messages anywhere: as you can imagine, the logging events are simply 
lost in the ether.


I think these logs are a critical feature for debugging and security and 
it would be very unfortunate for bookworm to ship with logging crippled 
in this way for puppetserver.


Although I did not test this specifically, I strongly suspect puppetdb 
is also affected in a similar way because they share many of the same 
components.


Do you think it might be possible to backport the accessEvent variable 
fix from a later version of Logback?


-- Jérôme


Le 2023-05-19 à 09 h 53, Markus Koschany a écrit :

Control: tags -1 patch

Hi,

I am attaching a patch for this issue. Somehow your package fell through the
cracks because it has no dependency on logback. Logback is pulled in by Jetty
though. While Logback and Jetty use the Jakarta servlet API now, your package
still depends on libservlet-api-java. The fix for that was trivial. However the
test failure is caused by my tomcat10-migration.patch

https://salsa.debian.org/java-team/logback/-/blob/master/debian/patches/tomcat10-migration.patch#L91

Back then I thought it was acceptable to work around a build failure by setting
the accessEvent variable to null since it seemed no package existed in Debian
which would be affected by it. The Logback developers fixed that problem in
newer versions, but a new upstream release of logback would have been too
intrusive. Long story short: please double-check my patch and if we can ignore
the logging problem

Regards,

Markus

Bug#1036250: trapperkeeper-webserver-jetty9-clojure: FTBFS in testing: MDCAccessLogConverter.java:54: error: cannot access HttpServletRequest

[Jérôme Charaoui]

Control: tags -1 confirmed help

Hello,

This bug, as well as bug #1034855, have a common cause.

The latest upload of src:logback, version 1:1.2.11-2, added a large 
patchset to migrate its dependencies from tomcat9 to tomcat10.


When attempting to build this package with the previous version of 
liblogback-java, 1:1.2.11-1, everything works.


Unfortunately I'm a little out of my depth here, because I'm not sure 
what's the best way to address this problem.


At this point it seems inappropriate to introduce a large patchset in 
this package to migrate over to tomcat10 libraries, if that is even 
possible.


Therefore, I would like to request assistance to find a solution.

The removal of this package would inevitably lead to the removal of 
puppetserver from Debian, which would be highly unfortunate.


Thanks,

-- Jérôme

Bug#1033005: puppetdb: "fresh" installion results in "permission denied for table schema_migrations"

[Jérôme Charaoui]

Control: tag -1 + moreinfo
Control: severity -1 important

Hello,

The puppetdb package wasn't part of the last Debian release, bullseye.

Are you upgrading from puppetdb 6.2.0-3 which was in Debian buster? I 
need to know precisely what were the steps you took here, so I can 
figure out how to reproduce the problem.


But nonetheless, if you install puppetdb on a clean system (really 
fresh), you should not hit this bug, so I'm reducing the severity to 
non-release critical.


If I can figure out how to reproduce and fix this I'll upload a fix, but 
since we're very close to the release I'm not sure if it'll get through.


Thanks,

-- Jérôme

Bug#1032734: OOM when unlocking encrypted root in initramfs

[Jérôme Charaoui]

Tagging ‘moreinfo’ then.  I can definitely see how one can reproduce
this theoretically (and possibly in the future when the kernel's memory
requirement increase high enough), and mentioned that in the upstream
bug, but I'm unable to find a reproducer after dist-upgrading bullseye
systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso,
and “Encrypted LVM” partition scheme, on VMs with 1024M RAM).

Jérôme, what memory cost is the keyslot using?  (Paste the output of
`cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.)  Would also be
interested to see by how much the amount of memory available to
cryptsetup has changed before and after the uprade.  Please edit
/usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at
the begining of the setup_mapping() function (patch attached).  My own
findings are as follows (again on a minimal netinst system without
changing any default).  cryptsetup isn't even close to memory
exhaustion.


Memory cost:

- 8< -
# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
PBKDF:  argon2i
Time cost:  4
Memory: 787907
Threads:1
- >8 -

Free memory:

- 8< -
Loading Linux 6.1.0-5-amd64 ...
Loading initial ramdisk ...
  totalusedfree  shared  buff/cache 
available
Mem: 993756   74720  725012  60  194024 
660412

Swap: 0   0   0
- >8 -

I've also tested on another of my virtual machines that has 1GiB of RAM 
and got another result, closer to what you got in your experimentation:


- 8< -
# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
PBKDF:  argon2i
Time cost:  6
Memory: 499912
Threads:1
- >8 -

So, I think what's happening is that the first VM may have been created 
with a different (larger) memory configuration, and was reduced at a 
later point in time. I don't have absolute certainty of this, but it 
would very well explain the discrepancy in memory cost.


Also, I think I agree with your assessment that in the memory usage 
increase of the kernel may be involved: between the two releases, 
according to your numbers it appears to have increased nearly 25% (!). 
So it could also explain why it (probably very nearly) worked under 
bullseye.


I there any way we could make the cryptsetup-initramfs hook aware of 
this, and emit a warning if it finds that the encrypted root lacks a 
keyslot with appropriate (low-enough) memory cost?



Thanks,

-- Jérôme

Bug#1032734: OOM when unlocking encrypted root in initramfs

[Jérôme Charaoui]

Package: cryptsetup
Version: 2:2.6.1-1
Severity: critical

Dear maintainer,

Today I upgraded a small KVM machine with a LUKS2 encrypted root and 
1GiB of RAM to bookworm, and was very surprised to be confronted with an 
OOM immediately upon entering my LUKS password in the initramfs prompt:


Loading Linux 6.1.0-5-amd64 ...
Loading initial ramdisk ...
Please unlock disk vda5_crypt:
[7.982435] Out of memory: Killed process 243 (cryptsetup) 
total-vm:799000kB, anon-rss:678296kB, file-rss:6440kB, shmem-rss:0kB, 
UID:0 pgtables:1384kB oom_score_adj:0

Killed
cryptsetup: ERROR: vda5_crypt: cryptsetup failed, bad password or 
options?


This machine was booting just fine before upgrading, under bullseye.

The problem appears to be perhaps related to #924560, but in this 
instance, the issue causing an unbootable system post-upgrade.



Thanks,

-- Jérôme

Bug#1030427: marked as pending in trapperkeeper-metrics-clojure

[Jérôme Charaoui]

Control: tag -1 pending

Hello,

Bug #1030427 in trapperkeeper-metrics-clojure reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/clojure-team/trapperkeeper-metrics-clojure/-/commit/0a6c16e047b5bc56d7ab7114156a13ad9fbceedd


drop jackson and snakeyaml version overrides

Avoid leaking bogus dependency versions in maven-repo. Requires updated
build-deps where the issue is fixed and makes the project.clj overrides
obsolete.

Closes: #1030427


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1030427

Bug#1030428: marked as pending in trapperkeeper-scheduler-clojure

[Jérôme Charaoui]

Control: tag -1 pending

Hello,

Bug #1030428 in trapperkeeper-scheduler-clojure reported by you has been fixed 
in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/clojure-team/trapperkeeper-scheduler-clojure/-/commit/34adc0f06153cae2ec61008d5fe397c80809f1c8


d/patches: remove gettext from :exclusions

Closes: #1030428


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1030428

Bug#1030256: [Pkg-puppet-devel] Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet

[Jérôme Charaoui]

I think this is occurring because the test is being run as "root".

I don't know how common that is in build environments, but it's not 
something that I have or think I should have in my build (sbuild) or 
test (autopkgtest) environments.


Is there some flag we could use to tell reproducible-builds to build 
this package as a regular user instead of root?


If not I might have to patch the test suite to work around some of the 
logic in there, which I'm not too excited about.


Perhaps an alternative would be to add "puppet-agent" as a build 
dependency, because that package will create a "puppet" user in the 
environment.


Thanks,

-- Jérôme

Bug#1028333: puppetserver: find an upgrade path from puppet-master

[Jérôme Charaoui]

The old "puppet-master" and "puppet-master-passenger" were basically 
just configuration files for the systemd/sysvinit and Apache2/Passenger, 
because the main (ruby) code was always in the "puppet" package.


I think the way forward here is that first, we should make the 7.x 
transitional dummy package "puppet" "Breaks: puppet-master, 
puppet-master-passenger", to make clear that the old master packages 
cannot function with the libraries shipping in the latest puppet-agent 
package.


And secondly, we should carefully consider whether a "seamless" 
transition is even possible at all. Puppetserver is completely different 
software which is configured differently than the old master, and as 
such I doubt that one can simple replace one package with the other and 
expect things to "just work". Even if it does, important bits of the 
configuration may likely be lost in translation (eg. auth.conf).


So considering all this I'm currently leaning towards adding a 
transitional "puppet-master" and/or "puppet-master-passenger" package 
for the purpose of shipping a NEWS file recommending that users migrate 
to the puppetserver package manually.


-- Jérôme

Bug#997323: lektor: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13

[Jérôme Charaoui]

Le 2023-01-03 à 11 h 45, Bastian Germann a écrit :

X-Debbugs-Cc: jer...@riseup.net

On Tue, 3 Jan 2023 17:35:24 +0100 Bastian Germann  wrote:

This will be rectified with importing v3.3.0+.
But there will be other problems with the current werkzeug version 
which are addressed with v3.4.0b1:

https://github.com/lektor/lektor/pull/1051


I see the maintainer and Jérôme have worked on new versions but they 
were never released.

Is there something missing?


And of course I've just noticed that python3-mistune0 now exists in 
Debian, so maybe I can finally upload Lektor 3.3 ...

Bug#997323: lektor: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13

[Jérôme Charaoui]

Le 2023-01-03 à 11 h 45, Bastian Germann a écrit :

X-Debbugs-Cc: jer...@riseup.net

On Tue, 3 Jan 2023 17:35:24 +0100 Bastian Germann  wrote:

This will be rectified with importing v3.3.0+.
But there will be other problems with the current werkzeug version 
which are addressed with v3.4.0b1:

https://github.com/lektor/lektor/pull/1051


I see the maintainer and Jérôme have worked on new versions but they 
were never released.

Is there something missing?


Since python-mistune has moved to 2.x in Debian, the Lektor 3.2 and 3.3 
branches are no longer functional. Upstream has integrated mistune 2.0 
support in 3.4 but there have only been beta releases of it so far, and 
I'm not entirely sure if we should upload that and release it with bookworm?


In short, I've been working on it but it has been quite a moving target 
so far.


-- Jerome

Bug#1026329: bouncycastle breaks pgpainless autopkgtest: premature end of stream

[Jérôme Charaoui]

Hello,

According to the pgpainless upstream, this bug is fixed bouncycastle 
1.72.1 and later versions.


Unfortunately, upstream does not appear to have tagged any version 
beyond 1.72 in their git repository.


Thanks,

-- Jerome

Bug#1025442: marked as pending in jruby

[Jérôme Charaoui]

Control: tag -1 pending

Hello,

Bug #1025442 in jruby reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/java-team/jruby/-/commit/456069f250320fc8b131d1446a73d2da8d2a87d9


d/control: add Breaks+Replaces on jruby-openssl (Closes: #1025442)

A Provides is not necessary since no other packages depend on this
jruby-specific library.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1025442

Bug#1013662: core-async-clojure: FTBFS randomly in bullseye

[Jérôme Charaoui]

On Mon, 5 Dec 2022 22:04:06 +0100 Santiago Vila  wrote:

Hi.

I attach an upload proposal for bullseye, in debdiff format against 
version 1.3.610-4 (stable version), so you can upload it "as is" if 
everything else is ok.


There is a stable point release around the corner, it would be wonderful 
if this could be fixed by then.



I'm not opposed to uploading it but I'm curious to know why this is 
needed now, because the next stable release is also "around the corner", 
in relative terms...


Thanks,

-- Jerome

Bug#1020639: pdfarranger: libqpdf 11 require pdfarranger 1.9.1

[Jérôme Robert]

Package: pdfarranger
Version: 1.8.2-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: jeromerob...@gmx.com

Dear Maintainer,

pdfarranger depends on pikepdf. pikepdf 5.1.1 FTBS with libqpdf 11:

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

According to Salsa pikepdf 6 is about to be uploaded. Once done
pdfarranger will stop working because of:

https://github.com/pdfarranger/pdfarranger/issues/716

So pdfarranger should be updated to 1.9.1.

Tagging as grave because pdfarranger has already been removed from
testing because pikepdf was removed from testing because of 1019694.
Once pikepdf will be back in version 6 pdfarranger will be unusable.

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pdfarranger depends on:
ii  gir1.2-glib-2.01.73.0+ds-1
ii  gir1.2-gtk-3.0 3.24.34-3
ii  gir1.2-poppler-0.1822.08.0-2.1
ii  python33.10.6-1
ii  python3-cairo  1.20.1-3+b1
ii  python3-dateutil   2.8.1-6
ii  python3-gi 3.42.2-2
ii  python3-gi-cairo   3.42.2-2
ii  python3-pikepdf5.1.1+dfsg-1+b1
ii  python3-pkg-resources  65.3.0-1.1

Versions of packages pdfarranger recommends:
ii  python3-img2pdf  0.4.4-2

pdfarranger suggests no packages.

-- no debconf information

Bug#1011967: trapperkeeper-clojure: autopkgtest regression: FileNotFoundException

[Jérôme Charaoui]

Hello,

This bug has been fixed by uploading core-async-clojure version 
1.3.610-5 which includes this change:


https://salsa.debian.org/clojure-team/core-async-clojure/-/commit/afae424e1de2e423e1842dec6d23085f31a5bc9c

Thanks!

-- Jerome

Bug#1013662: marked as pending in core-async-clojure

[Jérôme Charaoui]

Control: tag -1 pending

Hello,

Bug #1013662 in core-async-clojure reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/clojure-team/core-async-clojure/-/commit/9cbf1ca97cf3ab072c70f5a5d8239b40fa3337ce


Skip test assertions which hang in single-cpu env

Replaces previous patch which didn't work on autobuilders, tests still
failed systematically.

Closes: #1013662


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1013662

Bug#1013662: core-async-clojure: FTBFS: make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1

[Jérôme Charaoui]

Hello,

I'm unable to reproduce this bug locally.

When I diff, the build logs, the only relevant element I can find is 
that in my build environment, the "clojure_1.10.3-1" package is 
installed, whereas in the failing build log, it appears to be absent.


I think it would be worth it to attempt to build it again.

Thanks,

-- Jerome

Bug#1011843: powerline-gitstatus: FTBFS: make[1]: *** [debian/rules:17: override_dh_auto_install] Error 1

[Jérôme Charaoui]

Version: 1.3.1-4

The colorscheme patch was refreshed to fix the FTBFS bug.

-- Jeroime

Bug#996726: Some other questions

[Jérôme Pouiller]

On Friday 5 November 2021 03:02:13 CET Norbert Preining wrote:
> >   After 2 weeks, the bug has finally been fixed. But I wonder why the bug
> > wasn't tested out in the unstable branch and was pushed into the testing
> 
> Because on unstable everything worked. The bug happens only due to
> different transition times from unstable to testing. This cannot be
> tested in unstable before.

Is there a way to avoid this problem happen in the future?

-- 
Jérôme Pouiller

Bug#995050: ecere-sdk FTBFS with gcc 10

[Jérôme St-Louis]

Thank you Adrian for reporting this.

We have fixes for this upstream:

commit *c94efd6390599a4a291b7fe8b3d2d62699247380*
Author: Jerome St-Louis 
Date:   Sun Sep 6 03:35:01 2020 -0400

    compiler/bootstrap: Updated for GCC 10 Common fixes

commit *7d835dd5c6e17ad1626ec7b6f1725e0f7f8a9371*
Author: Rejean Loyer 
Date:   Mon Aug 3 13:18:51 2020 -0400

    compiler/ecs: add -no-attribute-common for targetting wasm. 
workaround "Common symbols are not yet implemented for Wasm" message 
coming from emscripten-releases\llvm-project\llvm\li

b\MC\MCWasmStreamer.cpp's MCWasmStreamer::emitCommonSymbol function.

commit *ca58cfa4e26e03271e32ee6aae3206956fdc26fd*
Author: Jerome St-Louis 
Date:   Wed May 20 07:25:49 2020 -0400

    compiler/libec: Fixed multiple definitions issues breaking on GCC 
10 without -fcommon


There is also a more recent commit fixes for GCC 11 which will surely 
show up sooner or later:


commit *53ec01de1c42cf342a35dc125a4fef01ffb5fced* (origin/master, master)
Author: Jerome St-Louis 
Date:   Thu Aug 5 21:07:56 2021 -0400

    compiler/libec/lexer.l: Initial fix for failure to build on GCC 11
    - bootstrap updated
    - # 0 instead of # 1 generated by preprocessor triggered problem in 
lexer's preprocessor()
    - NOTE: This was likely resulting in declMode, defaultDeclMode and 
structDeclMode not being set properly

    - It may also be related to #1135

There are other important fixes on master since 0.44.15, including fixes 
for #898832 .


In general, the master branch of our repo is currently (HEAD: 
53ec01de1c42cf342a35dc125a4fef01ffb5fced) very conservatively stable, 
and would be a good candidate for a patch 0.44.15 release.


On our side we are overdue for a new release, but we hope to bring in a 
lot of new improvements and functionality for the next 0.44.16 release, 
which is proving difficult to complete given that our development branch 
(/lates//t/) is now more than 1200 commits ahead of master. We are also 
quite busy with our geospatial software endeavours (making use of the 
Ecere SDK).


If someone is willing to help with the Debian packaging / update to 
close these bugs, myself and possibly others in our community will be 
more than happy to provide assistance and otherwise contribute to the 
effort.


Thank you!

Best regards,

-Jerome

On 9/25/21 6:27 AM, Adrian Bunk wrote:

Source: ecere-sdk
Version: 0.44.15-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ecere-sdk=0.44.15-1%2Bb4

...
gcc -Wl,-z,relro  -Wl,--no-undefined   -Wl,--no-undefined   -Wl,--no-undefined  
 -Wl,--no-undefined  -L../ecere/obj/bootstrap.linux 
-L../libec/obj/bootstrap.linux obj/bootstrap.linux/ecp.o 
obj/bootstrap.linux/ecp.main.o-lecereBootstrap -lecBootstrap -lm -ldl -o 
obj/bootstrap.linux/ecp
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:52:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Eof'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:388: first 
defined here
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:54:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Puts'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:384: first 
defined here
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:56:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Read'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:390: first 
defined here
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:58:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first 
defined here
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:60:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Write'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:392: first 
defined here
...
/usr/bin/ld: 
../libec/obj/bootstrap.linux/libecBootstrap.a(shortcuts.o):./compiler/bootstrap/libec/bootstrap/shortcuts.c:298:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Write'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:392: first 
defined here
/usr/bin/ld: 
../libec/obj/bootstrap.linux/libecBootstrap.a(shortcuts.o):./compiler/bootstrap/libec/bootstrap/shortcuts.c:300:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first 
defined here
/usr/bin/ld: 
../libec/obj/bootstrap.linux/libecBootstrap.a(type.o):./compiler/bootstrap/libec/bootstrap/type.c:392:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; 

Bug#949647: firefox: Unable to lounch

[Jérôme Fix]

Hi,

Exactly the same issue here since lasts updates.
It's the same thing with Thunderbird.

➜  ~ thunderbird 
ExceptionHandler::GenerateDump cloned child 46082
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child


➜  ~ /usr/bin/firefox   
ExceptionHandler::GenerateDump cloned child 46533
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Regards,

Jérôme.

On Thu, 23 Jan 2020 08:03:43 +0100 Michael Rasmussen  wrote:
> Package: firefox
> Version: 72.0.2-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Starting firefox produces the error below and firefox informs me that it has 
crashed and cannot start:
> 
> ExceptionHandler::GenerateDump cloned child 
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
> 13819
> ExceptionHandler::SendContinueSignalToChild sent continue signal to child
> 
> I see exactly the same whether I am starting firefox with or without the 
option --safe-mode.
> 
> 
> -- Package-specific info:
> 
> 
> -- Addons package information
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'unstable-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-3-amd64 (SMP w/16 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages firefox depends on:
> ii  debianutils   4.9.1
> ii  fontconfig2.13.1-2+b1
> ii  libatk1.0-0   2.34.1-1
> ii  libc6 2.29-9
> ii  libcairo-gobject2 1.16.0-4
> ii  libcairo2 1.16.0-4
> ii  libdbus-1-3   1.12.16-2
> ii  libdbus-glib-1-2  0.110-5
> ii  libevent-2.1-72.1.11-stable-1
> ii  libffi7   3.3-3
> ii  libfontconfig12.13.1-2+b1
> ii  libfreetype6  2.10.1-2
> ii  libgcc1   1:9.2.1-24
> ii  libgdk-pixbuf2.0-02.40.0+dfsg-2
> ii  libglib2.0-0  2.62.4-1+b1
> ii  libgtk-3-03.24.13-1
> ii  libnspr4  2:4.24-1
> ii  libnss3   2:3.49.1-1
> ii  libpango-1.0-01.42.4-8
> ii  libsqlite3-0  3.31.0-1
> ii  libstartup-notification0  0.12-6
> ii  libstdc++69.2.1-24
> ii  libx11-6  2:1.6.8-1
> ii  libx11-xcb1   2:1.6.8-1

Bug#947319: missing directory

[Jérôme Bouat]

It seems a directory is missing :
---
Could not enumerate user data directory /var/lib/lightdm/data: Error opening 
directory '/var/lib/lightdm/data': No such file or directory
---

I attached the last lines of my /var/log/syslog
Dec 24 15:31:43 l systemd[1]: anacron.service: Succeeded.
Dec 24 15:39:30 l systemd[1]: Starting Cleanup of Temporary Directories...
Dec 24 15:39:31 l systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Dec 24 15:39:31 l systemd[1]: Started Cleanup of Temporary Directories.
Dec 24 15:47:42 l systemd[1]: Started Getty on tty2.
Dec 24 15:47:47 l systemd[1]: Started Session 5 of user j.
Dec 24 16:05:02 l systemd[1]: Stopping Authorization Manager...
Dec 24 16:05:02 l systemd[1]: Stopped target Sound Card.
Dec 24 16:05:02 l systemd[1]: Stopping Save/Restore Sound Card State...
Dec 24 16:05:02 l systemd[1]: Stopped target Graphical Interface.
Dec 24 16:05:02 l systemd[1]: Stopped target Multi-User System.
Dec 24 16:05:02 l systemd[1]: Stopped target Login Prompts.
Dec 24 16:06:37 l systemd-modules-load[168]: Inserted module 'firewire_sbp2'
Dec 24 16:06:37 l systemd[1]: Starting Flush Journal to Persistent Storage...
Dec 24 16:06:37 l systemd[1]: Started Flush Journal to Persistent Storage.
Dec 24 16:06:37 l systemd[1]: Started Set the console keyboard layout.
Dec 24 16:06:37 l systemd[1]: Reached target Local File Systems (Pre).
Dec 24 16:06:37 l systemd[1]: Started udev Kernel Device Manager.
Dec 24 16:06:37 l systemd-udevd[197]: Using default interface naming scheme 
'v240'.
Dec 24 16:06:37 l systemd-udevd[197]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
Dec 24 16:06:37 l systemd-udevd[202]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
Dec 24 16:06:37 l systemd[1]: Condition check resulted in Rebuild Hardware 
Database being skipped.
Dec 24 16:06:37 l systemd[1]: Condition check resulted in FUSE Control File 
System being skipped.
Dec 24 16:06:37 l systemd[1]: Condition check resulted in File System Check on 
Root Device being skipped.
Dec 24 16:06:37 l systemd[1]: Condition check resulted in Set Up Additional 
Binary Formats being skipped.
Dec 24 16:06:37 l systemd[1]: Condition check resulted in Kernel Configuration 
File System being skipped.
Dec 24 16:06:37 l systemd[1]: Found device RTL-8100/8101L/8139 PCI Fast 
Ethernet Adapter.
Dec 24 16:06:37 l systemd[1]: Found device FUJITSU_MHM2100AT 5.
Dec 24 16:06:37 l systemd[1]: Activating swap 
/dev/disk/by-uuid/03a421c3-c67f-4c3a-8731-8b01bf8b9571...
Dec 24 16:06:37 l systemd[1]: Activated swap 
/dev/disk/by-uuid/03a421c3-c67f-4c3a-8731-8b01bf8b9571.
Dec 24 16:06:37 l systemd[1]: Reached target Swap.
Dec 24 16:06:37 l systemd[1]: tmp.mount: Directory /tmp to mount over is not 
empty, mounting anyway.
Dec 24 16:06:37 l systemd[1]: Mounting /tmp...
Dec 24 16:06:37 l systemd[1]: Mounted /tmp.
Dec 24 16:06:37 l systemd[1]: Reached target Local File Systems.
Dec 24 16:06:37 l systemd[1]: Condition check resulted in Commit a transient 
machine-id on disk being skipped.
Dec 24 16:06:37 l systemd[1]: Starting Set console font and keymap...
Dec 24 16:06:37 l systemd[1]: Starting Load AppArmor profiles...
Dec 24 16:06:37 l systemd[1]: Starting Create Volatile Files and Directories...
Dec 24 16:06:37 l systemd[1]: Started Set console font and keymap.
Dec 24 16:06:37 l systemd[1]: Started Create Volatile Files and Directories.
Dec 24 16:06:37 l apparmor.systemd[256]: Restarting AppArmor
Dec 24 16:06:37 l apparmor.systemd[256]: Reloading AppArmor profiles
Dec 24 16:06:37 l systemd[1]: Starting Network Time Synchronization...
Dec 24 16:06:37 l systemd[1]: Starting Update UTMP about System Boot/Shutdown...
Dec 24 16:06:37 l systemd[1]: Started Update UTMP about System Boot/Shutdown.
Dec 24 16:06:37 l kernel: [0.00] Linux version 4.19.0-6-686-pae 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP 
Debian 4.19.67-2+deb10u2 (2019-11-11)
Dec 24 16:06:37 l kernel: [0.00] x86/fpu: x87 FPU will use FXSAVE
Dec 24 16:06:37 l kernel: [0.00] BIOS-provided physical RAM map:
Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 
0x-0x0009f7ff] usable
Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 
0x0009f800-0x0009] reserved
Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 
0x000ea400-0x000f] reserved
Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 
0x0010-0x0ffe] usable
Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 
0x0fff-0x0bff] ACPI data
Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 
0x0c00-0x0fff] ACPI NVS
Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 
0xfffe-0x] reserved
Dec 24 16:06:37 l kernel: [0.00] Notice: NX (Execute Disable) 
protection missing in CPU!
Dec 24 16:06:37 l 

Bug#929483: robocode: Class not found program wont start

[Bardot Jérôme]

Le 24/05/2019 à 17:00, Markus Koschany a écrit :
> Control: severity -1 grave
>
> On Fri, 24 May 2019 13:45:04 +0200 Bardot Jerome
>  wrote:
> [...]
>> Can't find robocode.core-1.x.jar module near to robocode.jar
>> Class path: /usr/share/java/robocode.jar
> Thanks for reporting. This is another Java 11 issue. It seems we have to
> explicitly add some jar files to the classpath now. This is also known
> upstream as
>
> https://sourceforge.net/p/robocode/bugs/407/
>
> I will prepare an update for Buster soon.
>
> Regards,
>
> Markus
>
Nice thx a lot for your efforts



0x053A41EF03878A98.asc
Description: application/pgp-keys

Bug#927824: Grisbi 1.2.1-1 always crashes when creating a new transaction

[Jérôme de Bretagne]

Thanks Ludovic, the updated version has been unblocked and has now
migrated to testing, this fixes the issue.

Le mer. 24 avr. 2019 à 17:10, Ludovic Rousseau
 a écrit :
>
> Le 24/04/2019 à 15:51, Ludovic Rousseau a écrit :
> > debian-release will not accept to migrate 1.2.2 into testing.
>
> Maybe they will. Grisbi version 1.2.2 is just a bug fix of version 1.2.1.
> I created https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927881 asking for 
> an unblock.
>
> Bye
>
> --
>   Dr. Ludovic Rousseau

Bug#908615: Issue with Python3.7

[Jérôme Kieffer]

Hi,

I am the main developper of pyFAI and we are aware there are issues
with python 3.7.0 (we have issues opened on github about that). We will
re-enable CI on python-3.7 as soon as 3.7.1 is out and our code can run
on it.

Would it be possible to get an extra month to setup a new release
supporting python 3.7 as today our code cannot run due to missing
dependencies.

Thanks for your patience.

Cheers,

Jerome

Bug#898832: ecere-sdk: FTBFS on i386: /usr/lib/gcc/i686-linux-gnu/7/include/stddef.h:435:78: error: syntax error

[Jérôme St-Louis]

Dear Sven,

Thank you for the notice.
It would be extremely helpful in solving this rapidly to have a 
quick-link to the exact version of that stddef.h (possibly the other 
libc headers as well if that line refers so something else...).


Were you suggesting those commits because there were __alignof or 
__float128 at that line?


Best regards,

-Jerome

On 2018-05-16 6:34 AM, Sven Joachim wrote:

Source: ecere-sdk
Version: 0.44.15-1
Severity: serious
Tags: buster sid

Your package fails to build on i386[1] with a rather bogus syntax error:

,
| Building 2nd stage ecere...
| make[2]: Entering directory '/tmp/ecere-sdk-0.44.15/ecere'
| /usr/lib/gcc/i686-linux-gnu/7/include/stddef.h:435:78: error: syntax error
| Makefile:1078: recipe for target 'obj/release.linux/EARArchive.c' failed
| make[2]: *** [obj/release.linux/EARArchive.c] Error 1
`

Possible fixes in the upstream git repository, which I have not tested
at all:

https://github.com/ecere/ecere-sdk/commit/73e2e8c1f1e1963cfad0ae4b9866cd159a0c3ece
https://github.com/ecere/ecere-sdk/commit/9085cb19656728b5ccdbbbe26377ad5112513d01


1. 
https://buildd.debian.org/status/fetch.php?pkg=ecere-sdk=i386=0.44.15-1%2Bb2=1526325541=0

Bug#885284: gbirthday: Depends on unmaintained pygtk

[Jérôme]

Le Fri, 12 Jan 2018 11:13:20 +0100,
Rolf Leggewie <debian-b...@rolf.leggewie.biz> a écrit :

> On 11.01.2018 21:49, Jérôme wrote:
> > QBirthday now has a setup.py which makes it easier to install. I
> > hope it also makes it easier to create a .deb from the sources.
> >
> > Rolf (or anyone), would you like to package QBirthday?  
> 
> Jerome, thank you.  That sounds pretty good.  I shall look into it.

Hi Rolf.

Did you get the time to give it a look.

Is there anything I could do upstream to help?

Thanks.

-- 
Jérôme

Bug#868202: Remove build-depends and depends on python3-trollius

[Jérôme Lebleu]

Hi Iain,

python3-trollius is still a dependency of python3-qtile, probably an
oversight!

Also, I would be glad to help you maintaining qtile if you need so -
even if I'm not yet a DD.

Thanks in advance,

Jérôme



signature.asc
Description: OpenPGP digital signature

Bug#892270: [reportbug] Crash when report type set to None

[Bardot Jérôme]

Package: reportbug
Version: 7.1.10
Severity: grave

--- Please enter the report below this line. ---

Reportbug (gtk2 ui) crash when i select package.

The command line  output :

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2265, in 
    main()
  File "/usr/bin/reportbug", line 1109, in main
    return iface.user_interface()
  File "/usr/bin/reportbug", line 1721, in user_interface
    latest_first=self.options.latest_first)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line
1764, in func
    args, kwargs = op.sync_pre_operation(*args, **kwargs)
TypeError: 'NoneType' object is not iterable

And when i start report bug with --test option there is no crash and the
commmand line output is :

invalid report type None, defaulting to debbugs

--- System information. ---
Architecture:
Kernel: Linux 4.14.0-3-amd64

500 testing ftp.fr.debian.org


--- Package information. ---
Depends (Version) | Installed
===-+-==
python3:any |
apt | 1.6~beta1
python3-reportbug (= 7.1.10) | 7.1.10
sensible-utils | 0.0.11
python3:any (>= 3.3.2-2~) |
apt | 1.6~beta1
python3-debian | 0.1.32
python3-debianbts (>= 1.13) | 2.7.2
file | 1:5.32-2
python3-requests | 2.18.4-2
python3-apt | 1.4.0~beta3+b1


Package's Recommends field is empty.

Suggests (Version) | Installed
=-+-
postfix |
OR exim4 |
OR mail-transport-agent |
gnupg | 2.2.5-1
OR pgp |
debconf-utils (>> 1.1.0) |
debsums (>= 2.0.47) | 2.2.2
file (>> 1.30) | 1:5.32-2
dlocate |
python3-urwid |
python3-gi | 3.26.1-2
python3-gi-cairo | 3.26.1-2
gir1.2-gtk-3.0 | 3.22.28-1
gir1.2-vte-2.91 | 0.50.2-4
python3-gtkspellcheck | 4.0.5-1
xdg-utils | 1.1.2-2
emacs24-bin-common |
OR emacs25-bin-common |
claws-mail (>= 3.8.0) | 3.16.0-1
reportbug | 7.1.10



--- Output from package bug script ---
** Environment settings:
EMAIL="bardot.jer...@gmail.com"
DEBFULLNAME="BARDOT??Jerome"

** /home/jerome/.reportbugrc:
reportbug_version "6.6.5"
mode novice
ui gtk2
email "bardot.jer...@gmail.com"
no-cc
header "X-Debbugs-CC: bardot.jer...@gmail.com"
smtphost reportbug.debian.org



0x03878A98.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#885284: gbirthday: Depends on unmaintained pygtk

[Jérôme]

Hi all.

GBirthday is not maintained.

If someone wants to port it to GObject Introspection, I'll happily
leave it to him.

However, I ported it to Python 3 and PyQt5. That new version is
called... QBirthday !

Here it is:

https://github.com/lafrech/qbirthday
https://pypi.python.org/pypi/qbirthday/

It is a huge rework. I think I fixed a few issues (and probably
introduced new ones...).

QBirthday now has a setup.py which makes it easier to install. I hope
it also makes it easier to create a .deb from the sources.

Rolf (or anyone), would you like to package QBirthday?

If and once a qbirthday package is pushed, do you think you could
publish a transition package from gbirthday?

There will be a few breaking changes, so the update won't be 100%
transparent to the user, who may have to recreate his configuration,
but it is better than nothing.

Thanks.

-- 
Jérôme

Bug#876021: libreoffice-writer: launching writer makes libreoffice crash

[Jérôme Bouat]

Hello.

FYI,
I removed the libreoffice-wiki-publisher package. Next I achieved to use 
Writer. However I experienced a crash when I tried to create a new LO Base file.

Bug#876021: libreoffice-writer: launching writer makes libreoffice crash

[Jérôme Bouat]

I reproduced this crash by following a slightly different use case.

At first, I saved a few memory (the host has only 256MB RAM).

The NetworkManager service is always disabled on this host.
As root the following command :
systemctl stop rsyslog.service

Next as normal user, I terminated the nm-applet process in order to save memory 
in the openbox session.

As normal user, the following command :
libreoffice --backtrace

Next I didn't created new Draw, Impress and Calc documents as in previous use 
case. I directly attempted to launch writer by using the shortcut in left panel 
for creating a new Writer document.

Libreoffice crashed and I attached the backtrace.

Do you need more information before I remove the libreoffice-wiki-publisher 
package ?

Regards.
warning: Currently logging to gdbtrace.log.  Turn the logging off and on to make the new setting effective.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xafadeb40 (LWP 947)]
[New Thread 0xae4b5b40 (LWP 948)]
[New Thread 0xadaffb40 (LWP 949)]
[Thread 0xae4b5b40 (LWP 948) exited]
[New Thread 0xae4b5b40 (LWP 951)]
[New Thread 0xacfaeb40 (LWP 952)]
[New Thread 0xac4f4b40 (LWP 954)]
[Thread 0xac4f4b40 (LWP 954) exited]
[New Thread 0xac4f4b40 (LWP 971)]
[Thread 0xac4f4b40 (LWP 971) exited]
[New Thread 0xac4f4b40 (LWP 972)]
[Thread 0xac4f4b40 (LWP 972) exited]
[New Thread 0xac4f4b40 (LWP 975)]
[Thread 0xac4f4b40 (LWP 975) exited]
Can't read data for section '.debug_info' in file '/usr/lib/debug/.build-id/a8/3ed458e560517bc1b835be230488a4c5b7a0ac.debug'
[New Thread 0xac4f4b40 (LWP 976)]
[Thread 0xac4f4b40 (LWP 976) exited]

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
_expand_stack_to (bottom=0xbf805fff , bottom@entry=0xbf805000 ) at ./src/hotspot/src/os/linux/vm/os_linux.cpp:673
673	./src/hotspot/src/os/linux/vm/os_linux.cpp: Aucun fichier ou dossier de ce type.
#0  _expand_stack_to (bottom=0xbf805fff , bottom@entry=0xbf805000 ) at ./src/hotspot/src/os/linux/vm/os_linux.cpp:673
#1  0xa816d7a4 in os::Linux::manually_expand_stack (t=0x1547400, addr=0xbf805000 ) at ./src/hotspot/src/os/linux/vm/os_linux.cpp:686
#2  0xa8177ce8 in os::create_attached_thread (thread=0x1547400) at ./src/hotspot/src/os/linux/vm/os_linux.cpp:965
#3  os::create_main_thread (thread=0x1547400) at ./src/hotspot/src/os/linux/vm/os_linux.cpp:915
#4  0xa82ba69e in Thread::set_as_starting_thread (this=0x1547400) at ./src/hotspot/src/share/vm/runtime/thread.cpp:988
#5  Threads::create_vm (args=0xbfffd908, canTryAgain=0xbfffd767) at ./src/hotspot/src/share/vm/runtime/thread.cpp:3405
#6  0xa7f65f45 in JNI_CreateJavaVM (vm=0xbfffd8a8, penv=0xbfffdb68, args=0xbfffd908) at ./src/hotspot/src/share/vm/prims/jni.cpp:5220
#7  0xb23389a1 in ?? () from /usr/lib/libreoffice/program/libjvmfwklo.so
#8  0xb234abf4 in jfw_startVM(JavaInfo const*, JavaVMOption*, long, JavaVM_**, JNIEnv_**) () from /usr/lib/libreoffice/program/libjvmfwklo.so
#9  0xa899411a in ?? () from /usr/lib/libreoffice/program/libjavavmlo.so
#10 0xa89a8933 in ?? () from /usr/lib/libreoffice/program/libjavaloaderlo.so
#11 0xa89aa7ef in ?? () from /usr/lib/libreoffice/program/libjavaloaderlo.so
#12 0xb23cd058 in ?? () from /usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3
#13 0xb23cf274 in ?? () from /usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3
#14 0xb23cf3a5 in ?? () from /usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3
#15 0xb23caf87 in ?? () from /usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3
#16 0xb4ffde35 in framework::DispatchProvider::implts_searchProtocolHandler (this=0x13001d8, aURL=...) at ./framework/source/dispatch/dispatchprovider.cxx:457
#17 0xb50007ca in framework::DispatchProvider::implts_queryFrameDispatch (this=0x13001d8, xFrame=..., aURL=..., sTargetFrameName=..., nSearchFlags=0) at ./framework/source/dispatch/dispatchprovider.cxx:364
#18 0xb50023c9 in framework::DispatchProvider::queryDispatch (this=, aURL=..., sTargetFrameName=..., nSearchFlags=) at ./framework/source/dispatch/dispatchprovider.cxx:111
#19 0xa95c7ea6 in SwXDispatchProviderInterceptor::queryDispatch(com::sun::star::util::URL const&, rtl::OUString const&, long) () from /usr/lib/libreoffice/program/../program/libswlo.so
#20 0xb5002c75 in framework::InterceptionHelper::queryDispatch (this=0x1343f70, aURL=..., sTargetFrameName=..., nSearchFlags=) at ./framework/source/dispatch/interceptionhelper.cxx:83
#21 0xb50a8697 in (anonymous namespace)::Frame::queryDispatch (this=0x101cf78, aURL=..., sTargetFrameName=..., nSearchFlags=0) at ./framework/source/services/frame.cxx:2342
#22 0xb5144862 in framework::MenuBarManager::Activate (this=, pMenu=) at ./framework/source/uielement/menubarmanager.cxx:862
#23 0xb663ae89 in Link::Call (data=0x14516b0, this=0x14516cc) at ./include/tools/link.hxx:84
#24 Menu::Activate (this=0x14516b0) at ./vcl/source/window/menu.cxx:209
#25 0xb663e4cd in 

Bug#876021: libreoffice-writer: launching writer makes libreoffice crash

[Jérôme Bouat]

Hello,


Do you have libreoffice-wiki-publisher installed?


yes I have, version 1.2.0+LibO5.2.7-1


To confirm, please send a gb backtrace; see
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information


For each installed package of libreoffice, openjdk and libstdc++, I installed 
the matching (by name) dbgsym package of the stretch-debug repository.

Next I reproduced this bug with the following command :
libreoffice --backtrace

I attached the log.

Do you need more information ?

Regards.
warning: Currently logging to gdbtrace.log.  Turn the logging off and on to make the new setting effective.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xafadeb40 (LWP 700)]
[New Thread 0xae4b5b40 (LWP 701)]
[New Thread 0xadaffb40 (LWP 702)]
[Thread 0xae4b5b40 (LWP 701) exited]
[New Thread 0xae4b5b40 (LWP 703)]
[New Thread 0xacfaeb40 (LWP 704)]
[New Thread 0xac4f4b40 (LWP 705)]
[Thread 0xac4f4b40 (LWP 705) exited]
[New Thread 0xac4f4b40 (LWP 723)]
[Thread 0xac4f4b40 (LWP 723) exited]
[New Thread 0xac4f4b40 (LWP 724)]
[Thread 0xac4f4b40 (LWP 724) exited]
[New Thread 0xac4f4b40 (LWP 727)]
[Thread 0xac4f4b40 (LWP 727) exited]
Can't read data for section '.debug_info' in file '/usr/lib/debug/.build-id/02/02e01aa461b74ee75649a05de2b0ca973b42d2.debug'
[New Thread 0xac4f4b40 (LWP 728)]
[Thread 0xac4f4b40 (LWP 728) exited]
[New Thread 0xac4f4b40 (LWP 729)]
[Thread 0xac4f4b40 (LWP 729) exited]
[New Thread 0xac4f4b40 (LWP 730)]
[New Thread 0xa86deb40 (LWP 731)]
[New Thread 0xa7eddb40 (LWP 732)]
[Thread 0xa7eddb40 (LWP 732) exited]
[Thread 0xac4f4b40 (LWP 730) exited]
[New Thread 0xac4f4b40 (LWP 738)]
[Thread 0xac4f4b40 (LWP 738) exited]
[New Thread 0xac4f4b40 (LWP 739)]
[Thread 0xac4f4b40 (LWP 739) exited]
[Thread 0xa86deb40 (LWP 731) exited]
Can't read data for section '.debug_info' in file '/usr/lib/debug/.build-id/1a/e404de1a5457611b078246705ec5a6ec26a059.debug'
[New Thread 0xa86deb40 (LWP 750)]
[New Thread 0xac4f4b40 (LWP 751)]
[Thread 0xa86deb40 (LWP 750) exited]
[Thread 0xac4f4b40 (LWP 751) exited]
[New Thread 0xac4f4b40 (LWP 752)]
[Thread 0xac4f4b40 (LWP 752) exited]
[New Thread 0xac4f4b40 (LWP 753)]
[Thread 0xac4f4b40 (LWP 753) exited]
[New Thread 0xac4f4b40 (LWP 754)]
[Thread 0xac4f4b40 (LWP 754) exited]
[New Thread 0xac4f4b40 (LWP 755)]
[Thread 0xac4f4b40 (LWP 755) exited]
[New Thread 0xac4f4b40 (LWP 756)]
[Thread 0xac4f4b40 (LWP 756) exited]
[New Thread 0xac4f4b40 (LWP 757)]
[Thread 0xac4f4b40 (LWP 757) exited]
[New Thread 0xac4f4b40 (LWP 758)]
[Thread 0xac4f4b40 (LWP 758) exited]
[New Thread 0xac4f4b40 (LWP 759)]
[Thread 0xac4f4b40 (LWP 759) exited]
[New Thread 0xac4f4b40 (LWP 760)]
[Thread 0xac4f4b40 (LWP 760) exited]
[New Thread 0xac4f4b40 (LWP 763)]
[Thread 0xac4f4b40 (LWP 763) exited]
[New Thread 0xac4f4b40 (LWP 764)]
[Thread 0xac4f4b40 (LWP 764) exited]
[New Thread 0xac4f4b40 (LWP 765)]
[Thread 0xac4f4b40 (LWP 765) exited]
[New Thread 0xac4f4b40 (LWP 766)]
[Thread 0xac4f4b40 (LWP 766) exited]
[New Thread 0xac4f4b40 (LWP 767)]
[Thread 0xac4f4b40 (LWP 767) exited]
[New Thread 0xac4f4b40 (LWP 768)]
[Thread 0xac4f4b40 (LWP 768) exited]
[New Thread 0xac4f4b40 (LWP 769)]
[Thread 0xac4f4b40 (LWP 769) exited]
[New Thread 0xac4f4b40 (LWP 771)]
[Thread 0xac4f4b40 (LWP 771) exited]
[New Thread 0xac4f4b40 (LWP 772)]
[Thread 0xac4f4b40 (LWP 772) exited]
[New Thread 0xac4f4b40 (LWP 775)]
[Thread 0xac4f4b40 (LWP 775) exited]
Can't read data for section '.debug_info' in file '/usr/lib/debug/.build-id/e0/1e630782090836bdc45d2510dbb50a33d4abc1.debug'
[New Thread 0xac4f4b40 (LWP 776)]
[Thread 0xac4f4b40 (LWP 776) exited]
Error while reading shared library symbols for /usr/lib/libreoffice/program/../program/libswlo.so:
Can't read symbols from /usr/lib/debug/.build-id/a8/3ed458e560517bc1b835be230488a4c5b7a0ac.debug: Mémoire épuisée
[Thread 0xacfaeb40 (LWP 704) exited]
[Thread 0xae4b5b40 (LWP 703) exited]
[Thread 0xadaffb40 (LWP 702) exited]
[Thread 0xafadeb40 (LWP 700) exited]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
/usr/lib/libreoffice/program/gdbtrace:9: Error in sourced command file:
No stack.

Bug#876021: libreoffice-writer: launching writer makes libreoffice crash

[Jérôme]

Package: libreoffice-writer
Version: 1:5.2.7-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,


I tried to launch Libreoffice Writer by the desktop menu entry, nothing
happends. However, I successfully ran Calc, Impress and Draw.

Next, I opened a terminal and launched the "libreoffice" command.
Then only warning error I got was :
---
** (soffice:1099): WARNING **: Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not
provided by any .service files
---
Next the Libreoffice window appeared and I achieved to run Calc, Impress and
Draw. However, if I try to open a new Writer document, then all Libreoffice
window disappear.

The next time I'm running "libreoffice", a window proposes to restore the Calc,
Impress and Draw documents.

I can reproduce this bug always.



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

Kernel: Linux 4.9.0-3-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libreoffice-writer depends on:
ii  dpkg   1.18.24
ii  libabw-0.1-1   0.1.1-4
ii  libc6  2.24-11+deb9u1
ii  libe-book-0.1-10.1.2-4
ii  libetonyek-0.1-1   0.1.6-5
ii  libgcc11:6.3.0-18
ii  libicu57   57.1-6
ii  libmwaw-0.3-3  0.3.9-2
ii  libodfgen-0.1-10.1.6-2
ii  libreoffice-base-core  1:5.2.7-1
ii  libreoffice-core   1:5.2.7-1
ii  librevenge-0.0-0   0.0.4-6
ii  libstdc++6 6.3.0-18
ii  libwpd-0.10-10 0.10.1-5
ii  libwpg-0.3-3   0.3.1-3
ii  libwps-0.4-4   0.4.5-1
ii  libxml22.9.4+dfsg1-2.2+deb9u1
ii  uno-libs3  5.2.7-1
ii  ure5.2.7-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:5.2.7-1

Versions of packages libreoffice-writer suggests:
ii  default-jre [java5-runtime]2:1.8-58
ii  fonts-crosextra-caladea20130214-1
ii  fonts-crosextra-carlito20130920-1
ii  libreoffice-base   1:5.2.7-1
pn  libreoffice-gcj
ii  libreoffice-java-common1:5.2.7-1
ii  openjdk-8-jre [java5-runtime]  8u141-b15-1~deb9u1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.7+b1
ii  fonts-opensymbol  2:102.7+LibO5.2.7-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-4
ii  libc6 2.24-11+deb9u1
ii  libcairo2 1.14.8-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.1-8
ii  libcurl3-gnutls   7.52.1-5
ii  libdbus-1-3   1.10.18-1
ii  libdbus-glib-1-2  0.108-2
ii  libdconf1 0.26.0-2+b1
ii  libeot0   0.01-4+b1
ii  libexpat1 2.2.0-2+deb9u1
ii  libexttextcat-2.0-0   3.4.4-2+b1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglew2.02.0.0-3+b1
ii  libglib2.0-0  2.50.3-2
ii  libgltf-0.0-0v5   0.0.2-5
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.3.10-1
ii  libharfbuzz-icu0  1.4.2-1
ii  libharfbuzz0b 1.4.2-1
ii  libhunspell-1.4-0 1.4.1-2+b2
ii  libhyphen02.8.8-5
ii  libice6   2:1.0.9-2
ii  libicu57  57.1-6
ii  libjpeg62-turbo   1:1.5.1-2
ii  liblangtag1   0.6.2-1
ii  liblcms2-22.8-4
ii  libldap-2.4-2 2.4.44+dfsg-5
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-2
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1.1
ii  libodfgen-0.1-1   0.1.6-2
ii  libpcre3  2:8.39-3
ii  libpng16-16   1.6.28-1
ii  librdf0   1.0.17-1.1
ii  libreoffice-common1:5.2.7-1
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.2-1+b3
ii  libstdc++66.3.0-18
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxml2   2.9.4+dfsg1-2.2+deb9u1
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.29-2.1
ii  uno-libs3 5.2.7-1
ii  ure   5.2.7-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.24+nmu5

-- no debconf information

Bug#826352: ecere-dev: clashes with gnome-builder over /usr/bin/ide

[Jérôme St-Louis]

We agree to rename 'ide' to 'ecere-ide' but we're hoping the decided 
policy is to leave 'ide' alone for anyone. (We'll now have to setup 
'ide' aliases in our bash configs)
It's true we don't enjoy the same popularity / awareness as that GNOME 
project, but our IDE has been around since 2003.
What is the expected time frame to fix this, can it wait for the 
upcoming upstream release? Thank you.


Best regards,

-Jerome

On 2016-06-04 4:41 PM, Jeremy Bicha wrote:

Package: ecere-dev
Version: 0.44.14-1
Severity: serious


This is the other half of https://bugs.debian.org/824517

"gnome-builder 3.20.x ships /usr/bin/ide, making it impossible to
install alongside ecere-dev:

   Unpacking gnome-builder (3.20.4-1) over (3.18.1-1) ...
   dpkg: error processing archive
/var/cache/apt/archives/gnome-builder_3.20.4-1_amd64.deb (--unpack):
trying to overwrite '/usr/bin/ide', which is also in package
ecere-dev 0.44.14-1+b1
   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

"ide" is a sufficiently generic name that both packages should
arguably leave it alone."

Thanks,
Jeremy Bicha

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.4.0-23-generic

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Jérôme de Bretagne]

Hi Ben, Hi Matt,

I can confirm as well that the latest package version 4.4.6-1 fixes
the issue on a Lenovo ThinkPad Tablet 8.

Thanks a lot,
Jérôme

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Jérôme de Bretagne]

Package: linux-image-4.4.0-1-amd64
Version: 4.4.4-2
Followup-For: Bug #815125

Hi,

I am facing the same issue on a Lenovo ThinkPad Tablet 8, which boots
fine with a vanilla kernel built locally (4.5-rc6).

> Please can you each reply to the bug address with the following
> details:
>
> - Does the affected system boot using the BIOS boot protocol
>   (including CSM) or UEFI boot protocol?

It boots using UEFI boot protocol.

> - If you boot with the added kernel parameter "earlyprintk=vga" or
>   "earlyprintk=serial" (and without "quiet"), do any boot messages
>   appear before the hang/reboot?  PLease send them (a photo is fine).

No, nothing more is displayed with these parameters. It never leaves
Grub screen:
Loading initial ramdisk ...

> - If it boots with UEFI, does the kernel parameter "efi=noruntime"
>   work around the problem?

Yes. The kernel boots fine with that parameter.

> - If you haven't already reported this, does the Linux 4.5-rc4 package
>   from experimental have the same problem?

Yes, same problem with the current Linux (4.5-rc7) package from experimental.

Jérôme

Bug#808293: Bug also affect Squeeze LTS

[Jérôme Deliège]

This kernel is also affected : linux-image-2.6.32-5-686_2.6.32-48squeeze17

Bug#789980: FTBFS: from pymongo import ... ImportError: cannot import name Connection

[Jérôme]

I believe this is fixed since v8.

-- 
Jérôme

Bug#786165: gbirthday: deprecation of python-support

[Jérôme]

Rolf, Mattia.

I just released v0.6.9 which includes the patch from Mattia.

Note you can drop the recommandation on evolution-data-server and
python-evolution since v0.6.8.

-- 
Jérôme

Bug#786165: gbirthday: deprecation of python-support

[Jérôme]

Le 2015-12-16 13:39, Mattia Rizzolo a écrit :
> On Wed, Dec 16, 2015 at 09:47:09AM +0100, Jérôme wrote:

> oh, that's what happens!
> I expected a full-sized window.  My systry is really tiny, and I don't
> look at it (that's why is tity), so didn't notice the new icon.
> Ok, then it works fine, yeah ^^

Ha, ha.

Now you can a simple .csv file with your friends birthdays and be
notified, but you'd rather enlarge your systray if you want to rely on
this to keep your friends.
 
>> Ah, ok. I didn't think about patching upstream. Sure, why not. It may
>> look a bit dodgy, but it wouldn't break anything, I guess.
> 
> Usually in Debian we try to have few local patches as possible :)

Sure. I'll look into it.

It looks a bit like modifying upstream to adapt to a distro issue, but I
don't mind, for many excellent reasons. When I get the time, I do that.
 
> I uploaded a source package, which got built by the autobuilders, and
> now also the binary (=.deb) is in the archive.
> Since August we can do real source-only uploads and get them built by
> the autobuilders, instead of uploading binaries (which is bad).

Great.

I tested it in a "clean" VM and it seems to work. It is not my home
computer with actual config but it shouldn't make any difference.
 
> that sentence was meant to be "I want to *avoid* uploading a new...".
> A NMU is a "Non Maintainer Upload", which means uploaded done by people
> who are not the maintainer.
> NMUs should be as tiny as possible.
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu

OK, I get it. Thanks.

-- 
Jérôme

Bug#786165: gbirthday: deprecation of python-support

[Jérôme]

Le 2015-12-16 01:23, Mattia Rizzolo a écrit :

>> Do you want to put all gbirthday in /usr/share/gbirthday ? Or only
>> the images, while the code would be in /usr/lib/python2.7/dist-packages?
> 
> It's not really important from my POV.
> the gbirthday python module can really be thought as a private module,
> and interely installed in /usr/share/. See the Debian Python
> Policy for more in this regard:
> 
> https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs
> 
> I figured it would be easier for me to just do that, rather than trying
> to separate assents (since ISTR it's not only images) from the code.

Yes, absolutely. IMHO, it makes more sense to keep everything altogether
in /use/share/gbirthday.

And I can't think of any other Python program that would import
gbirthday.
 
>> You mean package gbirthday from stable/testing does not work for you? I
>> guess this should be investigated. You should probably file a bug.
>> Maybe also try GitHub version (no need to install, executing from
>> the repo is fine).
>>
>> Missing dependency?
>>
>> Any console output?
> 
> dunno:
> mattia@chase ~/devel/NMU/gbirthday % gbirthday
> ^CTraceback (most recent call last):
>   File "/usr/bin/gbirthday", line 12, in 
> main()
>   File "/usr/share/gbirthday/gbirthday/__init__.py", line 249, in main
> gtk.main()
> KeyboardInterrupt

That's quite strange.

Expected output is an icon in the systray. I suppose if you have no
systray, you don't see anything. Perhaps any relevant output in
~/.xsessions-errors (I doubt it)?
 
> The try/except structure is to make it easier to get accepted and
> incorporated by you upstream.
> I wanted to avoid doing such checks if the gbirthday module is already
> present.  TBH, I did that following what I read on openshot main script
> earlier today, which was in more or less the same issue.

Ah, ok. I didn't think about patching upstream. Sure, why not. It may
look a bit dodgy, but it wouldn't break anything, I guess.

After all I hope the whole packaging issue will be simplified when
gbirthday switches to distutils. (I may be wrong but I'd rather stick to
this idea, as it is an incentive to do the switch.)
 
>> If you upload an experimental version, I'll give it a try.
> 
> Ok, I these days I feel very lightway wrt uploading, so I just pushed
> that to experimental.

I don't see any binary package. You uploaded a "source package" and I
don't know what to do with it.
 
>> There you go:
>>
>> https://github.com/Jerome-github/gbirthday/releases
> 
> Actually I screw the upload up: I uploaded, then recalled about this,
> hurried up to cancel the upload, but I got a mail telling me it didn't
> cancel anything, so meh.
> 
> Anyway, I'll include it in the unstable upload.

OK, I don't understand everything but you seem to know what you're
doing.

I noticed you removed python-evolution dependency. This is the point of
the latest upstream version, in which I removed support for evolution
(which was broken anyway).

> I want to try uploading a new upstream version in a NMU, if possible :)

I don't know what a NMU is, and neither my search engine nor wikipedia
helped.
 
>> Thanks.
> 
> Thank you for being involved downstream! :)

Well, I'm a Debian user, so I'm taking care of myself in the process. Of
course I'm glad if Debian users and Debian derivatives benefit from it.

Thank you for your help.

-- 
Jérôme

Bug#808108: ecere-sdk needs an update for giflib 5

[Jérôme St-Louis]

Hi Matthias,

That's correct. The two commits that fixed this were:

https://github.com/ecere/ecere-sdk/commit/5c2998f4ca264d8e1663911ea497d7fdbc04d88c
https://github.com/ecere/ecere-sdk/commit/38f6e9c42338c3068bd97fe692ad884c71d420d4

I would gladly welcome a full update for 0.44.12 however. 0.44.12 is 
mainly a bug fix release, as was 0.44.11.

( https://github.com/ecere/ecere-sdk/archive/0.44.12.tar.gz )
The last time I submitted an updated 0.44.11 Debian package for 
sponsorship on mentors no one uploaded it.

(July 13, 2015:

Your package ecere-sdk all versions has been removed from mentors.debian.net 
for the following reason:
Your package found no sponsor for 20 weeks)

There are also 3 further important bug fixes on 'master' that were fixed 
after the 0.44.12 release:

( http://github.com/ecere/ecere-sdk/archive/master.tar.gz )

https://github.com/ecere/ecere-sdk/commit/fd7ec6a7ffad6b549c9c4f35892fd435241b2f78
https://github.com/ecere/ecere-sdk/commit/e69b560d9bcd2eda02599ffe155c81afc2607e80
https://github.com/ecere/ecere-sdk/commit/126614c65f5d6747169d988e4f0ab8b9c314a38a

The Debian packaging is at 
https://github.com/ecere/ecere-sdk/tree/ppa/debian/debian

( https://github.com/ecere/ecere-sdk/archive/0.44.11-1.tar.gz )

Please let me know if you require my assistance.

Best regards,

Jerome

*Jérôme Jacovella-St-Louis*
/Founder, Chief Technology Officer/
Ecere Corporation _http://ecere.ca_ <http://ecere.ca/>
<tel:%28819%29%20663-8539>


On 2015-12-16 1:04 AM, Matthias Klose wrote:

Package: src:ecere-sdk
Version: 0.44.10-1
Severity: serious
Tags: sid stretch upstream patch

Missed that package when preparing the giflib transition. The package 
fails to build with giflib 5. It looks like the new upstream 0.44.12 
has the required fix.


Building 2nd stage ecere...
make[2]: Entering directory '/«PKGBUILDDIR»/ecere'
/«PKGBUILDDIR»/ecere/src/gfx/bitmaps/GIFFormat.ec:32:31: warning: not 
enough arguments for function DGifOpen (2 given, expected 3)
/«PKGBUILDDIR»/ecere/src/gfx/bitmaps/GIFFormat.ec:108:10: warning: not 
enough arguments for function DGifCloseFile (1 given, expected 2)
obj/release.linux/GIFFormat.c: In function 
'__ecereMethod___ecereNameSpace__ecere__gfx__bitmaps__GIFFormat_Load':
obj/release.linux/GIFFormat.c:1033:25: error: too few arguments to 
function 'DGifOpen'
 GifFileType * gifFile = DGifOpen(f, (void 
*)(__ecereNameSpace__ecere__gfx__bitmaps__ReadData));

 ^
obj/release.linux/GIFFormat.c:579:15: note: declared here
 GifFileType * DGifOpen(void * userPtr, InputFunc readFunc, int * Error);
   ^
obj/release.linux/GIFFormat.c:1117:1: error: too few arguments to 
function 'DGifCloseFile'

 DGifCloseFile(gifFile);
 ^
obj/release.linux/GIFFormat.c:581:5: note: declared here
 int DGifCloseFile(GifFileType * GifFile, int * ErrorCode);
 ^
Makefile:1548: recipe for target 'obj/release.linux/GIFFormat.o' failed
make[2]: *** [obj/release.linux/GIFFormat.o] Error 1
make[2]: Leaving directory '/«PKGBUILDDIR»/ecere'
Makefile:202: recipe for target 'ecere' failed
make[1]: *** [ecere] Error 2
make[1]: Leaving directory '/«PKGBUILDDIR»'

Bug#786165: gbirthday: deprecation of python-support

[Jérôme]

Hi.

To my knowledge, gbirthday is not worked on by anyone but myself.

The Debian package is maintained is Rolf Leggewie.

I'm clueless about Debian packaging, so I'm afraid I can't help with the
python-support issue. I've paid a look at the wiki page about the
migration to see if I could help, but that's too many new concepts to
grasp.

For the record, gbirthday has moved to GitHub:
https://github.com/Jerome-github/gbirthday/. I should update the watch
file (this seems feasible to me, but there is no need to do it as long
as there is no new release).

Regarding the future of gbirthday, unless somebody takes over, it won't
be ported to Python3/GTK3.

However, I started a Python3/Qt port:

https://github.com/Jerome-github/gbirthday/tree/pyQt4_python3_port

No release date planned ("when it's ready"...). Still a lot of things to
polish. I's not just about graphical toolkit switch, the code is also
pretty old and deserves improvements / simplifications.

The roadmap includes proper Python packaging to replace current makefile
(https://github.com/Jerome-github/gbirthday/issues/7). I hope this will
make Debian packaging easier if not trivial.

Note that if the Qt port is finally released, it may come with a new
name, as gbirthday sounds GTKish.

To conclude, the way I see it:

- Unless somebody comes in, gbirthday won't evolve as it is and will
probably be out of Stretch or the next Debian release due to
dependencies deprecation. I'm happy if I'm wrong.

- I hope to get a Qt version packageable for Stretch. Help welcome, of
course.

Have a nice day.

-- 
Jérôme

Bug#786165: gbirthday: deprecation of python-support

[Jérôme]

Le Tue, 15 Dec 2015 13:30:36 +,
Mattia Rizzolo <mat...@debian.org> a écrit :

> On Tue, Dec 15, 2015 at 10:04:09AM +0100, Jérôme wrote:
> > Hi.
> 
> Hi Jérôme!
> Please note that nor me nor anybody else but the maintainer receive
> emails from bug reports unless they have subscribed through the PTS or
> to that specific bug.  So if you want to get the attention of somebody
> in cases like this would be better if you keep the in Cc or such.

Actually, I didn't mean to ping anybody. I was rather writing this for
the record, for anyone looking for this and ending up on the bugtracker.
 
> Yeah, this bug is mostly about deprecating a debian tool (pysupport)
> in favour of another (dh-python, or better, dh_python2 in this case).

This is pretty much all I had understood.
 
> I uploaded dozens of packages in the last 4 days removing it, but I'm
> stuck at gbirthday because it insists at installing images in sitelib,
> which used to be /usr/share/pyshared/gbirthday/ with pysupport, but
> now we're migrating off that directory and going to
> /usr/lib/python2.7/dist-packages, where images are not really welcome.

OK, this is concrete.
 
> So, given that this is actually an application and not a python module
> or such.
> 
> To do so, I'd like to upload what I attached as debdiff.
> In particoular I'm adding a patch to let it load from
> /usr/share/gbirthday.  

Alright. I have no educated opinion about this choice.

Do you want to put all gbirthday in /usr/share/gbirthday ? Or only
the images, while the code would be in /usr/lib/python2.7/dist-packages?

> Happens that the program doesn't load here, no
> UI appears; since this is the same behaviour I have with the package
> already in the archive that's not a regression, 

You mean package gbirthday from stable/testing does not work for you? I
guess this should be investigated. You should probably file a bug.
Maybe also try GitHub version (no need to install, executing from
the repo is fine).

Missing dependency?

Any console output?

> but given that
> uploading such untested changes would be too bad, I'd like to ask you
> what do you think of the patch attached as 'patch'.

Well, the patch looks fine. It worked on my machine.

I don't really see the need for the try clause. I mean if gbirthday is
installed in /usr/share/gbirthday, it is bound to fail, isn't it? And
the code in the except clause will be executed everytime.

If you upload an experimental version, I'll give it a try.

> > For the record, gbirthday has moved to GitHub:
> > https://github.com/Jerome-github/gbirthday/. I should update the
> > watch file (this seems feasible to me, but there is no need to do
> > it as long as there is no new release).
> 
> I would update it, but I don't know which kind of filenames you'll
> use, since there is no release already made there.

Ah. I didn't notice I had not uploaded the tags...

There you go:

https://github.com/Jerome-github/gbirthday/releases

(Note that a new version is available that gets rid of a broken
dependency.)

> [...]
> > - Unless somebody comes in, gbirthday won't evolve as it is and will
> > probably be out of Stretch or the next Debian release due to
> > dependencies deprecation. I'm happy if I'm wrong.
> 
> Not with *this* deprecation ;)

Alright. Good to know.
 
> > - I hope to get a Qt version packageable for Stretch. Help welcome,
> > of course.
> 
> Stretch will still release with python2, even if we definitely would
> like to remove it for buster.

Yep, I read that.

Don't give me too much time or I'll slack until last moment...

Thanks.

-- 
Jérôme

Bug#784709: issue with os-prober

[Jérôme Kieffer]

On Thu, 21 May 2015 12:14:15 +0800
Paul Wise p...@debian.org wrote:

 On Wed, 20 May 2015 14:59:04 +0200 Jérôme Kieffer wrote:
 
  jerome@patagonia:~$ sudo blkid -o value -s TYPE /dev/sdb4
  jerome@patagonia:~$ echo $?
  0
 
 That is strange, what about just this?
 
 sudo blkid /dev/sdb4 ; echo $?

Dear Paul,

# uname -a
Linux patagonia 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 
GNU/Linux

# fdisk -l /dev/sdb
Disque /dev/sdb : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x9a2578f7

Device Boot  StartEndSectors  Size Id Type
/dev/sdb1   63   33575849   33575787   16G 82 Linux swap / Solaris
/dev/sdb2 33575850  243304424  209728575  100G 83 Linux
/dev/sdb3243304425  453032999  209728575  100G 83 Linux
/dev/sdb4453033000 3907024064 3453991065  1,6T  5 Extended
/dev/sdb5453033063  557905319  104872257   50G 83 Linux
/dev/sdb6557905383  662777639  104872257   50G 83 Linux
/dev/sdb766203  767649959  104872257   50G 83 Linux
/dev/sdb8767650023  872522279  104872257   50G 83 Linux
/dev/sdb9872522343 1082250854  209728512  100G 83 Linux
/dev/sdb10  1082250918 3907024064 2824773147  1,3T 83 Linux

# blkid /dev/sdb?
/dev/sdb1: LABEL=Swap2T UUID=b3de0b2e-9092-4d08-af8d-09fefe8e9735 
TYPE=swap PARTUUID=9a2578f7-01
/dev/sdb2: LABEL=Win UUID=78d417f1-a097-4cf3-9218-32a621f78c68 TYPE=ext4 
PARTUUID=9a2578f7-02
/dev/sdb3: LABEL=Root UUID=9b3d9c65-6ba2-425f-bc5a-729cb6098165 TYPE=ext4 
PARTUUID=9a2578f7-03
/dev/sdb4: PTTYPE=dos PARTUUID=9a2578f7-04
/dev/sdb5: LABEL=UsrLocal UUID=dee401ac-fa36-44a5-9463-2571f8f52a84 
TYPE=ext4 PARTUUID=9a2578f7-05
/dev/sdb6: LABEL=Var UUID=e49c7936-3e39-4644-b025-e943172cd218 TYPE=ext4 
PARTUUID=9a2578f7-06
/dev/sdb7: LABEL=Backup UUID=251f4ed5-6114-4f19-b9c7-060eb82ececb 
TYPE=ext4 PARTUUID=9a2578f7-07
/dev/sdb8: LABEL=Opt UUID=8c0395c2-c9da-4ffc-a1a1-08851774182e TYPE=ext4 
PARTUUID=9a2578f7-08
/dev/sdb9: LABEL=Big UUID=deab5b7f-fb85-4f0d-95ed-84d37180162d TYPE=ext4 
PARTUUID=9a2578f7-09

The extended partition looks different from the other, but the result of blkid 
under 3.2 is the same as 3.16.

Cheers,


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

Bug#776697: linux-image-3.16.0-4-686-pae: Boot randomly stucks at a stage

[Jérôme Deuchnord]

Package: src:linux
Version: 3.16.7-ckt2-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I'm having some trouble with this version of the kernel that makes my system 
fail to boot. It looks like that it stucks on a stage, so that the boot process 
cannot continue. I could not make any video, but here is a photo I toke: 
http://imgur.com/mWXG9C0
The only solution I found for the moment is to use a previous version of the 
kernel, which works correctly.

Sorry for my bad English, I'm a French user... I stay available if you need 
more information.

Yours sincerely,
Jérôme Deuchnord

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
not available

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Atom Processor D2xxx/N2xxx DRAM 
Controller [8086:0bf1] (rev 03)
Subsystem: ASUSTeK Computer Inc. Device [1043:84a9]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0

00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
D2xxx/N2xxx Integrated Graphics Controller [8086:0be1] (rev 09) (prog-if 00 
[VGA controller])
Subsystem: ASUSTeK Computer Inc. Device [1043:84a9]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at dfc0 (32-bit, non-prefetchable) [size=1M]
Region 1: I/O ports at f0e0 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: gma500

00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition 
Audio Controller [8086:27d8] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8437]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 45
Region 0: Memory at dff0 (64-bit, non-prefetchable) [size=16K]
Capabilities: access denied
Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 2000-2fff
Memory behind bridge: 4040-405f
Prefetchable memory behind bridge: 4060-407f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: access denied
Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
2 [8086:27d2] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 1000-1fff
Memory behind bridge: dfe0-dfef
Prefetchable memory behind bridge: 4020-403f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: access denied
Kernel driver in use: pcieport

00:1c.3 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
4 [8086:27d6] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: e000-efff
Memory behind bridge: dfd0-dfdf

Bug#602724: please remove kfreebsd-any from Architecture

[Jérôme Vouillon]

Hi,

On 30/05/2014 17:57, Steven Chamberlain wrote:
 On 16:01, Emilio Pozuelo Monfort wrote:
 Just a reminder: there are still various things depending on the removed
 packages, preventing things from migrating to testing.
 
 Do you agree it's just the two metapackages from src:meta-gnome3 that
 need changes, or is there anything else?
 
 http://lists.debian.org/53863f46.2050...@pyro.eu.org

Indeed, this is the only issue.

task-gnome-desktop depends on gnome-core, but this will not prevent the
migration.

Regards,

-- Jérôme


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

Bug#731415: unrar-free is dead upstream and completely useless

[Jérôme]

Why not make it a transit package to unar, then ?

-- 
Jérôme


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

Bug#734813: systemd as pid1 allows lxc-containers to unmount host filesystems

[Jérôme Petazzoni]

To clarify — the above-mentioned gist is not a workaround against the
issue, but a sample snippet to repair my machine after it becomes unusable
because of this bug. It's just remounting everything which was unmounted to
make the machine usable again. It's (obviously) specific to my system, but
it might be helpful for those who want to investigate that issue without
having to reboot after each try.

-- 
@jpetazzo https://twitter.com/jpetazzo
Latest blog post: http://jpetazzo.github.io/2013/12/07/pxe-netboot-docker/

Bug#513796: fixed in xapian-bindings 1.1.5-2

[Jérôme Warnier]

Is there a way for us to build only this module ourselves, without messing
with the whole php5 packages suite?
Is this documented somewhere?

Thanks



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

Bug#517005: Info received (Still problematic)

[Jérôme Marant]

Please ignore my previous mail. The culprit is libdrm2.

Regards,

- Mail Original -
De: Debian Bug Tracking System ow...@bugs.debian.org
À: Jérôme Marant jerome.mar...@free.fr
Envoyé: Samedi 28 Mars 2009 18:24:02 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Bug#517005: Info received (Still problematic)


Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Fglrx packaging team pkg-fglrx-de...@lists.alioth.debian.org

If you wish to submit further information on this problem, please
send it to 517...@bugs.debian.org, as before.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.


-- 
517005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517005
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

Bug#521720: Lastest libdrm2 breaks Xorg

[Jérôme Marant]

Package: libdrm2
Version: 2.4.5-2
Severity: serious

Hi,

After upgrading from 2.3.1-2 to 2.4.5-2, my Xorg failed to
work properly. After downgrading to 2.3.1-2, situation is
normal again.

I do use latest Xorg from unstable along with fglrx non-free
drivers, and kernel 2.6.26.

Regards,



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

Bug#517005: Still problematic

[Jérôme Marant]

Hi,

I recenlty updated my system and Xorg won't start.
It looks like the problem is still around.

Regard,



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

Bug#460247: easytag destroys existing ogg vorbis tags without any notice

[Jérôme COUDERC]

Hi,

   Also, the patch is also included in the last version 2.1.6 (but not 
yet available on debian)


Regards,
Jérôme

Christian Hammers wrote, the 26/08/2008 23:42 :

Hello Sebastian

What do you think of the latest patch proposal for this bug?

Currently there is NO version of easytag in testing/lenny due to this bug
although there would be a freeze exception otherwise (if I understand the
package tracking page correctly).

bye,

-christian-





  




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

Bug#432257: easytag is unable to find any .mp3's

[Jérôme COUDERC]

Hi,

In the version 2.1.1, there is a small mistake in the configure script 
that may cause the problem of detection of MP3 support. This will be 
fixed in the 2.1.2 version


In attachment, a patch from Thomas Klausner

Regards,
Jerome

--
EasyTAG - Tag editor for MP3 and Ogg Vorbis files
http://easytag.sourceforge.net
--
Jerome COUDERC [EMAIL PROTECTED]

$NetBSD: patch-aa,v 1.1.1.1 2007/07/07 07:47:51 wiz Exp $

--- configure.orig  2007-07-04 18:50:16.0 +
+++ configure
@@ -21294,7 +21294,7 @@ _ACEOF
 
 fi
 
-if test x$enable_id3v23 == xyes; then
+if test x$enable_id3v23 = xyes; then
 echo $as_me:$LINENO: checking for library containing 
ID3Tag_Link 5
 echo $ECHO_N checking for library containing ID3Tag_Link... $ECHO_C 6
 if test ${ac_cv_search_ID3Tag_Link+set} = set; then

Bug#401665: #401665

[Jérôme Marant]

Hi Andreas,

I want to let you know I'm unable to work on #401665.
I don't have the necessary hardware, nor the knowledge about
such an architecture, nor the support from Ryan Murray I asked
for (he runs the autobuilder but never replies to mails).

I also did not work on the port myself and applied patches
that used to work.

Regards,

--
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le samedi 16 décembre 2006 21:09, Rob Browning a écrit :
 Jérôme Marant [EMAIL PROTECTED] writes:
 
  Shall we contact Ryan?
 
 Sounds like a good idea.  Though I suppose there's another difference
 between vaughan and the buildd.  On vaughan I wasn't building from a
 clean chroot.

Rob, are you taking care of this, or should I?

Thanks.

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le jeudi 21 décembre 2006 21:34, Rob Browning a écrit :
 Jérôme Marant [EMAIL PROTECTED] writes:
 
  Rob, are you taking care of this, or should I?
 
 Please do, if you have the time.

I will only available till next Saturday so I guess someone will have to
take care of it if both of us are unavailable.

-- 
Jérôme Marant

Bug#401665: [HELP] Re: Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Hi Ryan,

We would like to find out why latest version of emacs21 (21.4+1-2) failed to 
build
on mipsel.
21.4+1-1 used to build fine and no change related to the C code nor autoconf
files has been made in 21.4+1-2.

Since we don't have a clean sid chroot on vaughan (the only developer mipsel 
machine
which seems to be available), could you please help us investigating the 
problem?

Thanks in advance.

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le samedi 16 décembre 2006 04:18, Rob Browning a écrit :
 [EMAIL PROTECTED] writes:
 
  Do you know how to use an etch chroot on vaughan? (I guess this is the
  only mipsel machine available to developers?)
 
  Thanks in advance.
 
 I just started a build in the vaughan sid chroot, and it's well past
 sysdep.c now, so I'm not sure what the problem is, but I'm wondering
 if it might be something on the buildd or something that was broken in
 etch that has since been fixed in etch (or sid).

It looks like it has been rescheduled for building yesterday and it
is still failing.

Please note that vaughan is not the build machine. It is rem which
is maitained by Ryan Murray.

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le samedi 16 décembre 2006 19:08, Rob Browning a écrit :
 Jérôme Marant [EMAIL PROTECTED] writes:
 
  It looks like it has been rescheduled for building yesterday and it
  is still failing.
 
  Please note that vaughan is not the build machine. It is rem which
  is maitained by Ryan Murray.
 
 Right, but it is a mipsel machine, so the fact that it works in a sid
 chroot on vaughan suggests to me that something's probably wrong on
 the other machine.

Shall we contact Ryan?

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le vendredi 15 décembre 2006 11:38, Andreas Barth a écrit :
 * Jérôme Marant ([EMAIL PROTECTED]) [061215 11:35]:
  Le mardi 12 décembre 2006 16:46, Andreas Barth a écrit :
  
   
   As described in the developers reference:
   http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-dchroot
   
   However, apt sources don't seem to be too current there. If there is
   anything I can help you on my mipsel-machine, please say so.
  
  Andreas,
  
  Have you tried anything yet w.r.t. my last reply?
 
 Not yet, because my mipsel machine started to segfault, and currently I
 cannot ssh into it. I hope to be able to test it in the next 24 hours,
 though.

Alright. Please keep us informed as soon as you have something working again.

Thanks.

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le mardi 12 décembre 2006 16:46, Andreas Barth a écrit :

 
 As described in the developers reference:
 http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-dchroot
 
 However, apt sources don't seem to be too current there. If there is
 anything I can help you on my mipsel-machine, please say so.

Andreas,

Have you tried anything yet w.r.t. my last reply?

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le vendredi 15 décembre 2006 12:52, Martin Michlmayr a écrit :
 fakeroot debian/rules autofiles-sync gives:
 
 ...
 test $(QUILT_PATCHES=debian/patches quilt top) = autofiles.diff
 QUILT_PATCHES=debian/patches quilt pop
 Removing patch autofiles.diff
 Restoring aclocal.m4
 Restoring configure
 
 Now at patch ldapsearch-output.diff
 mkdir -p debian/tmp-autofiles/old
 tar cpSf - --exclude ./debian --exclude ./.pc . | tar -C 
 debian/tmp-autofiles/old -xpSf -
 cp -a debian/tmp-autofiles/old debian/tmp-autofiles/new
 # rm aclocal.m4 so it doesn't confuse newer autoconfs, but touch it
 # so ./Makefile won't be upset if it's not recreated (b/c not needed).
 cd debian/tmp-autofiles/new  rm -f aclocal.m4
 cd debian/tmp-autofiles/new  touch aclocal.m4
 cd debian/tmp-autofiles/new  aclocal
 cd debian/tmp-autofiles/new  autoconf
 autoconf: Undefined macros:
 configure.in:1351:AC_SYS_LARGEFILE
 configure.in:1442:AC_C_PROTOTYPES
 configure.in:1443:AC_C_VOLATILE
 configure.in:2040:AC_FUNC_MKTIME
 configure.in:2047:AC_FUNC_FSEEKO
 configure.in:29:AC_CONFIG_LIBOBJ_DIR(src)
 make: *** [autofiles-sync] Error 1
 zsh: exit 2 fakeroot debian/rules autofiles-sync

Hmm, some package might be missing.

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le vendredi 15 décembre 2006 14:38, Andreas Barth a écrit :

   autoconf: Undefined macros:
   configure.in:1351:AC_SYS_LARGEFILE
   configure.in:1442:AC_C_PROTOTYPES
   configure.in:1443:AC_C_VOLATILE
   configure.in:2040:AC_FUNC_MKTIME
   configure.in:2047:AC_FUNC_FSEEKO
   configure.in:29:AC_CONFIG_LIBOBJ_DIR(src)
   make: *** [autofiles-sync] Error 1
   zsh: exit 2 fakeroot debian/rules autofiles-sync
  
  Hmm, some package might be missing.
 
 Any hint which one that could be? What auto* do you use yourself?

Those macros are part of autoconf.

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le vendredi 15 décembre 2006 15:22, Stephen Gran a écrit :
 This one time, at band camp, Martin Michlmayr said:
  * Stephen Gran [EMAIL PROTECTED] [2006-12-15 14:10]:
autoconf 2.60a-4 and autoconf2.13 2.13-58 are installed on my machine.
   Which one does /usr/bin/autoconf point to?
  
  autoconf --version
  Autoconf version 2.13
  ---
  Autoconf 2.13 chosen by Debian wrapper script.
 
 Do you mind repointing it to the newer one, and seeing if it still
 FTBFS?

FYI, it is not proper FTBFS. The autofiles-sync rule is run manually before
building the package. 

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le vendredi 15 décembre 2006 15:56, Martin Michlmayr a écrit :
 * Martin Michlmayr [EMAIL PROTECTED] [2006-12-15 15:28]:
  Okay, it works after removing autoconf2.13.  Let's see whether the
  package compiles...
 
 No, fails in the same way.

Then I don't know. Why does it fail only on mipsel?
As I said no patch has been applied to the C code nor anything related
to it (like autotools).

Dare I question the toolchain?

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le vendredi 15 décembre 2006 16:45, Martin Michlmayr a écrit :
 * Jérôme Marant [EMAIL PROTECTED] [2006-12-15 16:08]:
  Then I don't know. Why does it fail only on mipsel?
  As I said no patch has been applied to the C code nor anything related
  to it (like autotools).
  
  Dare I question the toolchain?
 
 I don't know.

We're going to need to remove emacs from the mipsel release candidate
package list then.

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le jeudi 07 décembre 2006 02:20, Rob Browning a écrit :

 I suppose it's possible that that changing the series order might have
 broken something if I didn't re-run autofiles-sync after the move,
 but I thought I did.

Hi Rob,

Are you working on it ?

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le mardi 05 décembre 2006 10:18, Andreas Barth a écrit :
 Package: emacs21
 Version: 21.4a+1-2
 Severity: serious
 
 Hi,
 
 the build of emacs failed on mipsel. Please see
 http://buildd.debian.org/fetch.cgi?pkg=emacs21ver=21.4a%2B1-2arch=mipselstamp=1165216366file=log
 for the full build log.

Rob,

Didn't you break the autofiles, by chance? You told me you changed something
in the autodiff patch?

I'm just asking because on mipsel, X libraries fail to be autodetected from
the configure script.

The breakage could come from somewhere else though because it looks
file on other architectures.

-- 
Jérôme Marant

Bug#401665: FTBFS on mipsel

[Jérôme Marant]

Le mardi 05 décembre 2006 10:18, Andreas Barth a écrit :
 Package: emacs21
 Version: 21.4a+1-2
 Severity: serious
 
 Hi,
 
 the build of emacs failed on mipsel. Please see
 http://buildd.debian.org/fetch.cgi?pkg=emacs21ver=21.4a%2B1-2arch=mipselstamp=1165216366file=log
 for the full build log.

Hi,

Nothing changed in that part of the code nor in build option or anything related
and I was building just fine in 21.4a+1-1.

-- 
Jérôme Marant

Bug#396875: tagging 396875

[Jérôme Marant]

Selon Andreas Barth [EMAIL PROTECTED]:

 * Jérôme Marant ([EMAIL PROTECTED]) [061106 07:07]:
  [...]

 When do you plan to upload a fix for this bug? Or should I rather upload
 an NMU?

I've already prepared a fix plus other fixes.
Rob wants to upload the package himself, so I provided the necessary
changes.
I pinged him and I'm now waiting for him to do the upload.

This is how it works.

Cheers,

--
Jérôme Marant

Bug#378427: removal of bluez-pin? (was Re: Bug#378427: needs to be updated to libbluetooth2)

[Jérôme Marant]

Le samedi 30 septembre 2006 23:28, Filippo Giunchedi a écrit :
 On Fri, Sep 29, 2006 at 10:01:33PM +0200, JJJrrrme Marant wrote:
  Hi,
 
  Is anyone taking care of this?

 bluez-pin is now obsoleted by the new bluez (=3.x) which uses a dbus
 interface to request pin. See my ITP for bluez-gnome which is going to
 provide a replacement.

 bluez-pin should be removed from unstable.

Thanks.

-- 
Jérôme Marant

Bug#378427: needs to be updated to libbluetooth2

[Jérôme Marant]

Hi,

Is anyone taking care of this?

Thanks.

-- 
Jérôme Marant

Bug#378301: juman: FTBFS: Segmentation fault during makepat

[Jérôme Pouiller]

It'd seems real problem come from '-O2' option

$ apt-get source juman  cd juman-5.1  fakeroot ./debian/rules 
pre-build  cd build-tree/juman-5.1  env CFLAGS='-O2' ./configure  
make

do segfault but 

$ apt-get source juman  cd juman-5.1  fakeroot ./debian/rules 
pre-build  cd build-tree/juman-5.1  env CFLAGS='' ./configure  
make

doesn't (notice default of CFLAGS is -O2 -g)

I tried to execute valgrind on makepat (compiled without '-O2'), but, it 
found no errors.

-- 
Jérôme Pouiller (Jezz) jezz AT sysmic DOT org

Bug#378301: juman: FTBFS: Segmentation fault during makepat

[Jérôme Pouiller]

Le jeudi 3 août 2006 11:33, Jérôme Pouiller a écrit :
 I tried to execute valgrind on makepat (compiled without '-O2'), but,
 it found no errors.
In fact, I didn't run correctly valgrind, there is only one error with 
CFLAGS=-g:
==32258== Conditional jump or move depends on uninitialised value(s)
==32258==at 0x4026754: getpath (iotool.c:145)
==32258==by 0x80487C2: main (makepat.c:46)
Because strlen(JumanPath) == 0. It isn't our bug but, it'd be a good 
idea to correct it

and with CFLAGS=-O2 -g, this error appears:
==1782== Use of uninitialised value of size 4
==1782==at 0x8048A3E: main (makepat.c:68)
makepat.c:68 match with return of main function. Surely, there is a 
buffer overflow while write in one of local variables of main function. 

So I have search an invalid acces to one these variables and it appears:
  char kugiri[1];
  [...]
  sprintf(kugiri,\t);

\t use two bytes, so this instruction overwrite some data of stack and 
program do segfault.

I join patch to correct this bug:

diff -r juman-5.1.orig/build-tree/juman-5.1/makepat/makepat.c 
juman-5.1/build-tree/juman-5.1/makepat/makepat.c
32c32
   char kugiri[1]; /* �ڤ� */
---
   char kugiri[2]; /* �ڤ� */


-- 
Jérôme Pouiller (Jezz) jezz AT sysmic DOT org

Bug#373651: and: init script stop fails if not running

[Jérôme Warnier]

Le mercredi 14 juin 2006 à 22:05 +0200, Peter Palfrader a écrit :
 Package: and
 Version: 1.2.2-1
 Severity: serious
 
 [EMAIL PROTECTED]:~$ sudo /etc/init.d/and stop
 Stopping auto nice daemon: and.
 [EMAIL PROTECTED]:~$ sudo dpkg --remove and
 (Reading database ... 229177 files and directories currently installed.)
 Removing and ...
 Stopping auto nice daemon: invoke-rc.d: initscript and, action stop failed.
 dpkg: error processing and (--remove):
  subprocess pre-removal script returned error exit status 1
 Starting auto nice daemon: and.
 Errors were encountered while processing:
  and
 [EMAIL PROTECTED]:~$
 
 I think your start-stop-daemon call could use an --oknodo
It would help if you could test yourself and submit a patch.

I think there could be a new upstream version soon (with some minor
improvements only, but hey!, that'd be great anyway).

Hope to hear from you soon.
Thanks for reporting
-- 
Jérôme Warnier [EMAIL PROTECTED]
BeezNest

Bug#372719: libfreetype6: Stack trace with OOo 2.02

[Jérôme Bertorelle]

Steve Langasek wrote:

Hi Jérome,

On Tue, Jun 13, 2006 at 07:36:17PM +0200, Jérôme Bertorelle wrote:
  

The crash is due to a SIGFPE in libfreetype6, here's a gdb trace:


[...]
  
Please try the package at

http://people.debian.org/~vorlon/libfreetype6_2.1.7-3_i386.deb and let

 me

know if this fixes the problems you're seeing.
  

Yes, this fixes the problems. Thanks!

Jérôme

Bug#369045: libasound2: version ALSA_0.9.0rc4 not defined in file libasound.so.2 with

[Jérôme Schneider]

 Package: libasound2
 Version: 1.0.11-5
 Severity: grave
 Justification: renders package unusable

 [..]
 aplay: relocation error: aplay: symbol snd_pcm_hw_params_set_rate_near, 
 version ALSA_0.9.0rc4 not defined in file libasound.so.2 with link time 
 reference
   
I have exactly the same problem with all applications that use Alsa
since version 1.0.11-5.

The temporary solution is to downgrade the package on testing (1.0.11-3).

Jérôme Schneider

Bug#364877: bugzilla: Too many arguments for main::fix_pl_scripts_perm

[Jérôme Schneider]

Package: bugzilla
Version: 2.20.1-1
Severity: grave
Justification: renders package unusable

The installation failed after the configuration :

aptitude install bugzilla
[..]
Setting up bugzilla (2.20.1-1) ...
Too many arguments for main::fix_pl_scripts_perm at 
/usr/share/bugzilla/lib/checksetup.pl line 4581, near '/usr/share/bugzilla')
Too many arguments for main::fix_pl_scripts_perm at 
/usr/share/bugzilla/lib/checksetup.pl line 4582, near 
'/usr/share/bugzilla/lib')
Execution of /usr/share/bugzilla/lib/checksetup.pl aborted due to compilation 
errors.
Error in postinst: unable to find /usr/share/bugzilla/debian/params.new
dpkg: error processing bugzilla (--configure):
 subprocess post-installation script returned error exit status 13
Errors were encountered while processing:
 bugzilla
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up bugzilla (2.20.1-1) ...
dpkg: error processing bugzilla (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 bugzilla

/usr/share/bugzilla/lib/checksetup.pl :

4580 fix_www_data_perm('/var/lib/bugzilla');
4581 fix_pl_scripts_perm('/usr/share/bugzilla');
4582 fix_pl_scripts_perm('/usr/share/bugzilla/lib');

I purge bugzilla and reinstall it and I had the same problem. I try a reinstall 
of perl 5.8 and same problem ...


Jérôme Schneider

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (1000, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.9
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages bugzilla depends on:
ii  apache2-mpm-worker [httpd]   2.0.55-4high speed threaded model for Apac
ii  debconf [debconf-2.0]1.5.0   Debian configuration management sy
ii  libappconfig-perl1.56-2  Perl module for configuration file
ii  libdbd-mysql-perl3.0002-2+b1 A Perl5 database interface to the 
ii  libmailtools-perl1.74-0.1Manipulate email in perl programs
ii  libtemplate-perl 2.14-1  template processing system written
ii  libtimedate-perl 1.1600-5Time and date functions for Perl
ii  patch2.5.9-4 Apply a diff file to an original
ii  postfix [mail-transport-agen 2.2.10-1A high-performance mail transport 
ii  ucf  2.009   Update Configuration File: preserv

Versions of packages bugzilla recommends:
ii  libchart-perl 2.4.1-3Chart Library for Perl
ii  libxml-parser-perl2.34-4 Perl module for parsing XML files
ii  mysql-server  5.0.20-1   mysql database server (current ver
ii  mysql-server-5.0 [mysql-serve 5.0.20-1   mysql database server binaries

-- debconf information:
* bugzilla/mysql_user: bugzilla
  bugzilla/mysql_available: true
* bugzilla/bugzilla_installation_way: Manual
* bugzilla/bugzilla_admin_real_name: Jerome Schneider
* bugzilla/mysql_host: localhost
  bugzilla/bugzilla_installation_way_single: Manual
* bugzilla/mysql_need_root: false
* bugzilla/mysql_root_name: root
  bugzilla/index_upgrade1:
* bugzilla/mysql_name: bugzilla
* bugzilla/bugzilla_admin_name: [EMAIL PROTECTED]
  bugzilla/mysql_user_couldnotbe_empty:
* bugzilla/mysql_port: 3306
  bugzilla/index_upgrade2: