Bug#1068713: oar-common: Submitting jobs does not work on a fresh installation of OAR

[Pierre Neyron]

Package: oar-common
Version: 2.5.9-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: pierre.ney...@imag.fr

Hello

After a fresh install of OAR on Debian stable (bookworm), starting jobs does 
not work.

Indeed the ssh connection to nodes is forbidden because the oar user is locked, 
instead of just not accepting password connections.

It is due to a change in the way the adduser ( >= 3.130 ) `--disabled-password` 
option works (it now set `!` instead of `*` in the password hash field).
`usermod -p '*' oar` fixes the issue.

This bug is fixed in Debian testing / oar-common 2.5.10-1.

-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 oar-common depends on:
ii  adduser  3.134
ii  libc62.36-9+deb12u4
ii  liboar-perl  2.5.9-1
ii  perl 5.36.0-7+deb12u1
ii  ucf  3.0043+nmu1

oar-common recommends no packages.

Versions of packages oar-common suggests:
pn  oar-doc 
pn  oar-node
pn  oar-server  
ii  oar-user2.5.9-1

-- no debconf information

Bug#1068711: oar-web-status: the Monika CGI page does not work - missing dependency.

[Pierre Neyron]

Package: oar-web-status
Version: 2.5.9-1
Severity: serious
Tags: 
Justification: Monika requires libcgi-fast-perl
X-Debbugs-Cc: pierre.ney...@free.fr

Hello,

When installing the oar-web-status package only, without the oar-restful-api 
alongside (not dependency between then), the Monika CGI page does not work.

The problem does not arise when oar-restful-api is installed alongside as well, 
because it bring the required dependency: libcgi-fast-perl.

oar-web-status should require libcgi-fast-perl, like oar-restful-api.

Problem still occures in Debian testing with oar-web-status 2.5.10-1. 

-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 oar-web-status depends on:
ii  apache2 [httpd-cgi]   2.4.57-2
ii  libappconfig-perl 1.71-2.2
ii  libdbd-pg-perl3.16.0-2
ii  libdbi-perl   1.643-4
ii  libsort-naturally-perl1.03-4
ii  libtie-ixhash-perl1.23-4
ii  perl  5.36.0-7+deb12u1
ii  php   2:8.2+93
ii  php-pgsql 2:8.2+93
ii  php8.2 [php]  8.2.7-1~deb12u1
ii  php8.2-pgsql [php-pgsql]  8.2.7-1~deb12u1

oar-web-status recommends no packages.

Versions of packages oar-web-status suggests:
pn  oar-doc  

-- no debconf information

Bug#1068444: (no subject)

[Pierre Neyron]

Hello,

This bug is known and fixed in Debian testing.

Indeed, the create_function function was removed from PHP 8: it must be 
replaced.


Also, there is another bug arising with PHP8: static methods must be 
declared static, otherwise the program still does not work and the 
following message shows up in the apache logs:



[Mon Apr 08 14:05:42.179046 2024] [php:error] [pid 15211] [client 
192.168.40.1:59772] PHP Fatal error:  Uncaught Error: Non-static method 
Shuffle::get_int() cannot be called statically in 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php:482\nStack 
trace:\n#0 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php(804): 
Job->color()\n#1 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php(1165): 
Resource->svg_jobs()\n#2 {main}\n  thrown in 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php on line 482, 
referer: http://192.168.40.4/drawgantt-svg/


Thanks for the bug report.
Pierre

Bug#927255: powerpc-utils is uninstallable

[Pierre Neyron]

Hello,

Yes, the following command running on a buster system complains about
pmac-utils in the second stage:

debootstrap --foreign --arch=ppc64 --no-check-gpg '--include=locales
openssh-server linux-image-powerpc64' sid /rootfs
https://deb.debian.org/debian-ports

chroot /rootfs /usr/bin/qemu-ppc64-static /bin/bash
/debootstrap/debootstrap --second-stage

[...]
I: Configuring initramfs-tools...
W: Failure while configuring base packages.  This will be re-attempted
up to five times.
W: See //debootstrap/debootstrap.log for details (possibly the package
powerpc-utils is at fault)

which says:

dpkg: error processing package powerpc-utils (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 powerpc-utils
dpkg: dependency problems prevent configuration of powerpc-utils:
 powerpc-utils depends on pmac-utils; however:
  Package pmac-utils is not installed.


The packages page https://packages.debian.org/sid/powerpc-utils
shows pmac-utils as dependence but not available also.

Best regards
Pierre

Bug#927255: powerpc-utils is uninstallable

[Pierre Neyron]

Hello

any news regarding this bug ? This is indeed annoying when
debootstraping a ppc64 BE system.

Regards
-- 
Pierre

Bug#971369: ipmctl 02.00.00.3809+ds-1 breaks the Intel Optane DC PMEM aka Apache path (AEC)

[Pierre Neyron]

Package: ipmctl
Version: 02.00.00.3809+ds-1
Severity: normal
X-Debbugs-Cc: pierre.ney...@free.fr

Dear Maintainer,

ipmctl 02.00.00.3809+ds-1 which ships with Debian buster-backports,
bullseye and sid breaks the Intel Optane DC PMEM aka Apache path (AEC).

There was a regression, as stated in the fix committed just before
version 02.00.00.3820 :
https://github.com/intel/ipmctl/commit/9e3898cb15fa9eed3ef3e9de4488be1681d53ff4

We indeed currently have problems in our platform[1] composed of 4 Dell
R640 equipped with Intel Optane DC PMEM, when using ipmctl
02.00.00.3809+ds-1 to change the goal from Memory Mode to App Direct (or
vice versa). It just breaks the PMEM system: even from BIOS, it's
impossible to fix the config afterward. The only option is to
sanitize/reset to factory default (which takes ~30min each time!).

Pierre
[1] http://www.grid5000.fr

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 ipmctl depends on:
ii  libc6   2.31-3
ii  libipmctl4  02.00.00.3809+ds-1

ipmctl recommends no packages.

ipmctl suggests no packages.

-- no debconf information

Bug#942382: dstat in buster given --disk-util option fails to start

[Pierre Neyron]

Package: dstat
Version: 0.7.4-6
Followup-For: Bug #942382

Dear Maintainer,

I confirm that the bug reported above is also present in a fresh install of
buster.

I tried an upgrade to the 0.7.4-6 version of the package from Debian testing,
and the issue is not fixed either:
Although `dstat --disk-util` succeeds to start, the output is still bogus:

$ dstat --disk-util
/usr/bin/dstat:2619: DeprecationWarning: the imp module is deprecated in favour
of importlib; see the module's documentation for alternative uses
  import imp

* Exception in plugin ['sda', 'sdb', 'sr0']
'tot_ticks'
sda--sdb--sr0-
util:util:util
63.0:51.8:
* Exception in plugin ['sda', 'sdb', 'sr0']
'tot_ticks'

 240: 197:
* Exception in plugin ['sda', 'sdb', 'sr0']
'tot_ticks'

 240: 197:
* Exception in plugin ['sda', 'sdb', 'sr0']
'tot_ticks'

 240: 197:


-> Warning at startup, exceptions reported and some values are above 100%.

Hope this new report helps fixing the wonderful tool.
Thanks.



-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (550, 'stable'), (500, 'stable-updates'), (100, 'testing'), (90, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dstat depends on:
ii  python3  3.7.3-1
ii  python3-six  1.12.0-1

dstat recommends no packages.

dstat suggests no packages.

-- no debconf information

Bug#775761: libguestfs incorrectly detects host CPU architecture -> virt-customize

[Pierre Neyron]

Hi,

I also have an issue with libguestfs incorrectly detecting the host CPU
architecture in Debian, when using the virt-customize command on a
aarch64 machine.

E.g.:

neyron@digarm:~/scm/environments-recipes/build/debian-buster-arm64$
virt-customize -a base_debian-buster-arm64.qcow2 --run-command "mkdir /test"
[   0.0] Examining the guest ...
[  11.1] Setting a random seed
virt-customize: warning: random seed could not be set for this type of
guest
[  11.2] Running: mkdir /test
virt-customize: error: host cpu (x86_64) and guest arch (aarch64) are not
compatible, so you cannot use command line options that involve running
commands in the guest.  Use --firstboot scripts instead.

If reporting bugs, run virt-customize with debugging enabled and include
the complete output:

  virt-customize -v -x [...]


This seems due to the fact that the package is built with
the ocaml mlstdutils/guestfs_config host_cpu set to "X86_64", whatever
the actual system architechure is.

Indeed, when rebuilding the arm64 package with the following patch
included, virt-customize works as expected.

--- libguestfs-1.40.2.orig/common/mlstdutils/guestfs_config.ml
+++ libguestfs-1.40.2/common/mlstdutils/guestfs_config.ml
@@ -22,4 +22,4 @@ let package_version = "1.40.2"
 let package_version_full = "1.40.2"
 let prefix = "/usr"
 let datadir = prefix ^ "/share"
-let host_cpu = "x86_64"
+let host_cpu = "aarch64"

However this patch of course will break virt-customize on other archs !.

My understanding is that this should be fixed in the packages rules, so
that "@host_cpu@" is correctly set with regard to the target arch. But I
did not find out how to do that for now.


-- System Information:
Debian Release: 10.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-6-arm64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libguestfs-tools depends on:
ii  curl   7.64.0-4
ii  libc6  2.29-3
ii  libconfig9 1.5-0.4
ii  libfuse2   2.9.9-1
ii  libguestfs-perl1:1.40.2-2+b12
ii  libguestfs01:1.40.2-2+b12
ii  libintl-perl   1.26-2
ii  libjansson42.12-1
ii  liblzma5   5.2.4-1
ii  libpcre3   2:8.39-12
ii  libreadline8   8.0-3
ii  libstring-shellquote-perl  1.04-1
ii  libsys-virt-perl   5.6.0-1+b1
ii  libtinfo6  6.1+20181013-2+deb10u2
ii  libvirt0   5.6.0-2
ii  libwin-hivex-perl  1.3.18-2
ii  libxml22.9.4+dfsg1-7+b3

Versions of packages libguestfs-tools recommends:
ii  gnupg  2.2.12-1+deb10u1

libguestfs-tools suggests no packages.

-- no debconf information

Bug#942467: oar-user: In HPC cluster with around 1000 cores, OAR fails to accept jobs

[Pierre Neyron]

This attached patch fix the issue by removing the max recursion
limitation in the usage of Perl's Storable module in OAR.
--- ResourceTree.pm.distrib	2019-10-02 22:49:09.541077657 +0200
+++ ResourceTree.pm	2019-10-02 22:49:57.449683280 +0200
@@ -7,6 +7,9 @@
 use Storable qw(dclone);
 #use Time::HiRes qw(gettimeofday);
 
+$Storable::recursion_limit=-1;
+$Storable::recursion_limit_hash=-1;
+
 ###
 #   RESOURCE TREE MANAGEMENT  #
 ###

Bug#942467: oar-user: In HPC cluster with around 1000 cores, OAR fails to accept jobs

[Pierre Neyron]

The missing references:

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no=912695
[2] https://rt.perl.org/Public/Bug/Display.html?id=133326


On Wed, 16 Oct 2019 22:58:50 +0200 Pierre Neyron 
wrote:
> This is due to a restriction implemented in Perl's Storable module
> distributed in Buster. See [1] and [2].

Bug#942467: oar-user: In HPC cluster with around 1000 cores, OAR fails to accept jobs

[Pierre Neyron]

The missing references:

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no=912695
[2] https://rt.perl.org/Public/Bug/Display.html?id=133326

Bug#942467: oar-user: In HPC cluster with around 1000 cores, OAR fails to accept jobs

[Pierre Neyron]

Package: oar-user
Version: 2.5.8-1
Severity: important

Dear Debian Developers,

In HPC clusters with around 1000 cores, a frontend under Buster fails to
accept jobs at the core level with the following error:

jdoe@frontend:~$ oarsub -l core=1 -I
Generate a job key...
Max. recursion depth with nested structures exceeded at 
/usr/share/perl5/OAR/Schedulers/ResourceTree.pm line 91.

This prevents using OAR on clusters of quite a common size.

This is due to a restriction implemented in Perl's Storable module
distributed in Buster. See [1] and [2].

-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages oar-user depends on:
ii  libc6   2.28-10
ii  libdbi-perl 1.642-1+b1
ii  oar-common  2.5.8-1
ii  oar-user-pgsql  2.5.8-1
ii  perl5.28.1-6

Versions of packages oar-user recommends:
ii  libxml-dumper-perl  0.81-1.2
ii  libyaml-perl1.27-1
ii  libyaml-syck-perl   1.31-1+b1

Versions of packages oar-user suggests:
pn  oar-doc 
ii  openssh-client  1:7.9p1-10
ii  xauth   1:1.0.10-1

-- no debconf information

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Pierre Neyron]

Hello,

Done here: https://github.com/dell/dkms/issues/74

BR,
Pierre

On 16/01/2019 11:31, Gianfranco Costamagna wrote:

hello,

diverging from upstream makes no sense to me, since the mkdeb approach 
has been introduced by us...

what about discussing this with them and find a common approach?

I'm not a direct user of this tool, so I can't have an opinion :)

G.
Il lunedì 14 gennaio 2019, 13:21:58 CET, Pierre Neyron 
 ha scritto:



Hello Gianfranco,

Ok, but what mkdeb patch would you like ?

a- should it actually include binaries unless source-only is set ?

   or

b- should it generate an arch independent _all.deb package (with man
page fixed accordingly) ?

I'm more likely to volunteer for b, even if it makes Debian's dkms
diverge from upstream in the way mkdeb works...

Cheers
Pierre

On 14/01/2019 13:01, Gianfranco Costamagna wrote:
 > Hello,
 > I'm happy to accept an eventual patch :)
 >
 > G.
 >
 > Il domenica 13 gennaio 2019, 17:10:39 CET, Pierre Neyron
 > mailto:pierre.ney...@free.fr>> ha scritto:
 >
 >
 > On 13/01/2019 16:18, drake763 wrote:
 >  > Thanks again for your quick and detailed response!
 >  >
 >  > On 1/13/19 2:49 PM, Gianfranco Costamagna wrote:
 >  >> Now, dkms run on amd64 produces binaries for *amd64* architecture,
 > and if you run the same command
 >  >> on i386 you will produce kernel modules that can run only on *i386*
 > architecture
 >  >
 >  > In my understanding, running in some src directory (which has to 
support

 >  > this obviously)
 >  >
 >  > make dkms_mkdeb
 >  >
 >  > produces an architecture independent deb package (hence my thought to
 >  > have the suffix _all.deb). When I then install that very _all.deb
 >  > package with dpkg, DKMS is invoked again and the actual compilation
 >  > takes place where the architecture dependent binary is produced 
(so dkms

 >  > is invoked twice. Once when creating the package, and again when
 > installing)
 >  >
 >  > My usecase is applying this patch for intel processors
 >  > (http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb
 >  > package with make dkms_mkdeb. The resulting deb package actually 
has no

 >  > binaries inside but only source code and - what I assume are - some
 >  > instructions for DKMS (dkms.conf and some .c and .patch files) for
 >  > actually installing the deb package with dpkg.
 >  >
 >  > Earlier in this thread, this was also discussed
 >  > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20).
 >  >
 >  > But then again the currently produced package works. So if no one else
 >  > complains, the behaviour may remain I guess (differentiating among
 >  > binary and non-binary packages just by name is probably not really
 > needed).
 >  >
 >  > Thanks again for fixing this bug.
 >  >
 >  > Cheers
 >
 > Hello,
 >
 > I also think `dkms mkdeb' should produce a architecture independent
 > "_all.deb" package as long as content is source only.
 >
 > My patch was taking "source-only" as de facto for mkdeb, because it
 > seemed to me to make sense with regard to the way I understand the usage
 > of dkms by Debian. However it does not match what the man page explains
 > and possibly breaks the way the command should act in some places.
 >
 > As a result, keeping mkdeb possibly include the binary modules, hence
 > have an architecture dependent package (e.g. amd64.deb) seems safer.
 >
 > That said however, running `dkms mkdeb' does not seem to include the
 > binary modules in my tests anyway, either with or without the
 > --binaries-only flag.
 >
 > As a result, it seems to me that the mkdeb command is broken anyway ?
 >
 >
 > All that explains why it was not easy to choose to report the fix
 > upstream or to just fix it in Debian, I guess.
 >
 > Hope this helps
 > (Hope I got it right...)
 >
 > Pierre
 >

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Pierre Neyron]

Hello Gianfranco,

Ok, but what mkdeb patch would you like ?

a- should it actually include binaries unless source-only is set ?

 or

b- should it generate an arch independent _all.deb package (with man 
page fixed accordingly) ?


I'm more likely to volunteer for b, even if it makes Debian's dkms 
diverge from upstream in the way mkdeb works...


Cheers
Pierre

On 14/01/2019 13:01, Gianfranco Costamagna wrote:

Hello,
I'm happy to accept an eventual patch :)

G.

Il domenica 13 gennaio 2019, 17:10:39 CET, Pierre Neyron 
 ha scritto:



On 13/01/2019 16:18, drake763 wrote:
 > Thanks again for your quick and detailed response!
 >
 > On 1/13/19 2:49 PM, Gianfranco Costamagna wrote:
 >> Now, dkms run on amd64 produces binaries for *amd64* architecture, 
and if you run the same command
 >> on i386 you will produce kernel modules that can run only on *i386* 
architecture

 >
 > In my understanding, running in some src directory (which has to support
 > this obviously)
 >
 > make dkms_mkdeb
 >
 > produces an architecture independent deb package (hence my thought to
 > have the suffix _all.deb). When I then install that very _all.deb
 > package with dpkg, DKMS is invoked again and the actual compilation
 > takes place where the architecture dependent binary is produced (so dkms
 > is invoked twice. Once when creating the package, and again when 
installing)

 >
 > My usecase is applying this patch for intel processors
 > (http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb
 > package with make dkms_mkdeb. The resulting deb package actually has no
 > binaries inside but only source code and - what I assume are - some
 > instructions for DKMS (dkms.conf and some .c and .patch files) for
 > actually installing the deb package with dpkg.
 >
 > Earlier in this thread, this was also discussed
 > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20).
 >
 > But then again the currently produced package works. So if no one else
 > complains, the behaviour may remain I guess (differentiating among
 > binary and non-binary packages just by name is probably not really 
needed).

 >
 > Thanks again for fixing this bug.
 >
 > Cheers

Hello,

I also think `dkms mkdeb' should produce a architecture independent
"_all.deb" package as long as content is source only.

My patch was taking "source-only" as de facto for mkdeb, because it
seemed to me to make sense with regard to the way I understand the usage
of dkms by Debian. However it does not match what the man page explains
and possibly breaks the way the command should act in some places.

As a result, keeping mkdeb possibly include the binary modules, hence
have an architecture dependent package (e.g. amd64.deb) seems safer.

That said however, running `dkms mkdeb' does not seem to include the
binary modules in my tests anyway, either with or without the
--binaries-only flag.

As a result, it seems to me that the mkdeb command is broken anyway ?


All that explains why it was not easy to choose to report the fix
upstream or to just fix it in Debian, I guess.

Hope this helps
(Hope I got it right...)

Pierre

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Pierre Neyron]

On 13/01/2019 16:18, drake763 wrote:

Thanks again for your quick and detailed response!

On 1/13/19 2:49 PM, Gianfranco Costamagna wrote:

Now, dkms run on amd64 produces binaries for *amd64* architecture, and if you 
run the same command
on i386 you will produce kernel modules that can run only on *i386* architecture


In my understanding, running in some src directory (which has to support
this obviously)

make dkms_mkdeb

produces an architecture independent deb package (hence my thought to
have the suffix _all.deb). When I then install that very _all.deb
package with dpkg, DKMS is invoked again and the actual compilation
takes place where the architecture dependent binary is produced (so dkms
is invoked twice. Once when creating the package, and again when installing)

My usecase is applying this patch for intel processors
(http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb
package with make dkms_mkdeb. The resulting deb package actually has no
binaries inside but only source code and - what I assume are - some
instructions for DKMS (dkms.conf and some .c and .patch files) for
actually installing the deb package with dpkg.

Earlier in this thread, this was also discussed
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20).

But then again the currently produced package works. So if no one else
complains, the behaviour may remain I guess (differentiating among
binary and non-binary packages just by name is probably not really needed).

Thanks again for fixing this bug.

Cheers


Hello,

I also think `dkms mkdeb' should produce a architecture independent 
"_all.deb" package as long as content is source only.


My patch was taking "source-only" as de facto for mkdeb, because it 
seemed to me to make sense with regard to the way I understand the usage 
of dkms by Debian. However it does not match what the man page explains 
and possibly breaks the way the command should act in some places.


As a result, keeping mkdeb possibly include the binary modules, hence 
have an architecture dependent package (e.g. amd64.deb) seems safer.


That said however, running `dkms mkdeb' does not seem to include the 
binary modules in my tests anyway, either with or without the 
--binaries-only flag.


As a result, it seems to me that the mkdeb command is broken anyway ?

Question is: how should it be fixed ?
- should it actually include binaries unless source-only is set ?
or
- should it generate an arch independent _all.deb package (with man page 
fixed accordingly) ?


All that explains why it was not easy to choose to report the fix 
upstream or to just fix it in Debian, I guess.


Hope this helps
(Hope I got it right...)

Pierre

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Pierre Neyron]

Hi Marco,

Problem is Debian dkms (v2.3) seems to be an old fork of github/dell
dkms (v2.5). Support for mkbmdeb comes from a patch in the Debian
package but does not exist upstream. As a result my patch is not so
relevant for upstream.

Do you know if the current Debian patches were already proposed to
upstream ? Do you know the roadmap for a possible merge from upstream
(bump Debian package version to 2.5) ?

Last be not least, since I do not have all the test cases in mind, I'd
be glad to get a review from the Debian maintainers before sending upstream.


Thanks,
Best regards,
Pierre

On 02/12/2018 06:27 PM, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
>> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of 
>> Pierre
>> Neyron
>> Sent: Monday, February 12, 2018 11:21 AM
>> To: 832...@bugs.debian.org
>> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
>>
>> Please find attached a patch for the dkms script (package version 2.3-3)
>> that fixes the following issues:
>>
>> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
>> package filename with -${debian_build_arch} instead of -all.
>>
>> - fix mkdeb (2): allow creating a dkms package without requiring to
>> build the binary module beforehand . The patch actually makes
>> --source-only de facto for mkdeb and mkdsc.
>>
>> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
>>
>> - fix usage: lacked mkdsc
>>
>> Regards
>> Pierre
> 
> Pierre,
> 
> Can you please submit the patches to upstream at github?
> 

Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Pierre Neyron]

Please find attached a patch for the dkms script (package version 2.3-3)
that fixes the following issues:

- fix mkdeb (1): mkdeb failed because a mv command was looking for a
package filename with -${debian_build_arch} instead of -all.

- fix mkdeb (2): allow creating a dkms package without requiring to
build the binary module beforehand . The patch actually makes
--source-only de facto for mkdeb and mkdsc.

- fix mkbmdeb: make --binary-only de facto for mkbmdeb

- fix usage: lacked mkdsc

Regards
Pierre
--- dkms-2.3/dkms	2018-02-12 18:03:16.454187565 +0100
+++ dkms.fixed/dkms	2018-02-12 18:02:24.901872644 +0100
@@ -132,8 +132,8 @@
 show_usage()
 {
 echo $"Usage: $0 [action] [options]"
-echo $"  [action]  = { add | remove | build | install | uninstall | match | autoinstall"
-echo $"   | mkdriverdisk | mktarball | ldtarball | mkrpm | mkkmp | mkdeb | mkbmdeb | status }"
+echo $"  [action]  = { add | remove | build | install | uninstall | match | autoinstall | mkdriverdisk |"
+echo $"mktarball | ldtarball | mkrpm | mkkmp | mkdeb | mkdsc | mkbmdeb | status }"
 echo $"  [options] = [-m module] [-v module-version] [-k kernel-version] [-a arch]"
 echo $"  [-d distro] [-c dkms.conf-location] [-q] [--force] [--all]"
 echo $"  [--templatekernel=kernel] [--directive='cli-directive=cli-value']"
@@ -3087,23 +3087,6 @@
 invoke_command "cp '$PREFIX/usr/lib/dkms/common.postinst' '$temp_dir_debian'" "copying legacy postinstall template"
 fi
 
-# Copy in the source tree
-if [[ ! $binaries_only ]]; then
-invoke_command "cp -Lpr '$dkms_tree/$module/$module_version/source' '$temp_dir_debian/$module-$module_version'" "Copying source tree"
-fi
-
-# Only if we are shipping binary modules, make a .tgz for the deb
-local archive_location="$dkms_tree/$module/$module_version/tarball/$module-$module_version.dkms.tar.gz"
-if [[ ! $source_only ]]; then
-binaries_only="binaries-only"
-invoke_command "make_tarball" "Gathering binaries"
-if [[ -f $archive_location ]]; then
-invoke_command "cp '$archive_location' '$temp_dir_debian'" "Copying DKMS tarball into DKMS tree"
-else
-die 12 $"Unable to find created tarball."
-fi
-fi
-
 # Calculate destination directory
 deb_basedir=$dkms_tree/$module/$module_version/${create_type}
 mkdir -p ${deb_basedir} >/dev/null 2>&1
@@ -3112,6 +3095,7 @@
 pushd "$temp_dir_debian" > /dev/null 2>&1
 case "$create_type" in
 dsc)
+invoke_command "cp -Lpr '$dkms_tree/$module/$module_version/source' '$temp_dir_debian/$module-$module_version'" "Copying source tree"
 invoke_command "dpkg-buildpackage -S -us -uc 1>/dev/null" "Building source package" || \
 die 7 $"There was a problem creating your ${create_type}."
 echo $""
@@ -3119,13 +3103,24 @@
 invoke_command "mv '$temp_dir/${debian_package}-dkms_${module_version}_source.changes' '$temp_dir/${debian_package}-dkms_${module_version}.dsc' '$temp_dir/${debian_package}-dkms_${module_version}.tar.gz' '$deb_basedir'" "Moving built files to $deb_basedir"
 ;;
 deb)
+invoke_command "cp -Lpr '$dkms_tree/$module/$module_version/source' '$temp_dir_debian/$module-$module_version'" "Copying source tree"
 invoke_command "dpkg-buildpackage -rfakeroot -d -b -us -uc 1>/dev/null" "Building binary package" || \
 die 7 $"There was a problem creating your ${create_type}."
 echo $""
 echo $"DKMS: mk${create_type} completed."
-	invoke_command "mv '$temp_dir/${debian_package}-dkms_${module_version}_${debian_build_arch}.deb' '$deb_basedir'" "Moving built files to $deb_basedir"
+	invoke_command "mv '$temp_dir/${debian_package}-dkms_${module_version}_all.deb' '$deb_basedir'" "Moving built files to $deb_basedir"
 	;;
 bmdeb)
+  # Only if we are shipping binary modules, make a .tgz for the deb
+  local archive_location="$dkms_tree/$module/$module_version/tarball/$module-$module_version.dkms.tar.gz"
+  binaries_only="binaries-only"
+  invoke_command "make_tarball" "Gathering binaries"
+  if [[ -f $archive_location ]]; then
+  invoke_command "cp '$archive_location' '$temp_dir_debian'" "Copying DKMS tarball into DKMS tree"
+  else
+  die 12 $"Unable to find created tarball."
+  fi
+
 	export KVER="$kernelver"
 	export KARCH="$arch"
 	invoke_command "dpkg-buildpackage -rfakeroot -d -b -us -uc 1>/dev/null" "Building binary package" || \

Bug#832558: dkms: mkdeb --source-only fails: can't find package

[Pierre Neyron]

Should dkms packages generated with `dpkg mkdeb' not be of arch "all" ?

Unless they provide arch specific blobs, they are just source code to be
compiled right ?

On Tue, 31 Oct 2017 14:54:51 -0300 Martin Galvan 
wrote:
> Package: dkms
> Version: 2.3-3ubuntu3
> Tags: patch
> Followup-For: Bug #832558
> 
> I'm attaching a patch that fixes /etc/dkms/template-dkms-mkdeb/debian/control
> so that the generated .deb has the arch suffix instead of 'all'.

Bug#758798: Increase severity ?

[Pierre Neyron]

Hi,

This bug prevents ifup to function correctly on Debian stable, if the
package is installed.

Should severity be increased ?

Thx
Pierre


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

Bug#782230: ca-certificates: update-ca-certificates manpage refers to the certificates.crt file instead of ca-certificates.crt

[Pierre Neyron]

Package: ca-certificates
Version: 20141019
Severity: minor

Dear Maintainer,

Reading the english manpage of update-ca-certificates, I see in the 2nd line of
the description:

   update-ca-certificates   is   a  program  that  updates  the  directory
   /etc/ssl/certs to hold SSL certificates and generates certificates.crt,
   a concatenated single-file list of certificates.

However the generated file seems to be ca-certificates.crt (/etc/ssl/certs/ca-
certificates.crt), which is misleading at some point.

Thanks
Pierre




-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (550, 'testing'), (500, 'unstable'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  openssl1.0.1k-1

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information excluded


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

Bug#778295: OAR 2.5.4-2 patch 3

[Pierre Neyron]

Hi Mehdi,

To me, this bug is critical, because it makes the use of the moldable
jobs feature break the advance reservation feature, and both features
are important to users of OAR.

Moldable jobs are  especially used in the case of heterogeneous clusters
(e.g. clusters composed of nodes of 2 or more different hardware
specifications, because of a purchase in 2 or more phases for instance).
In that case, a job must be described with several choices of
specifications (e.g. # of cores + total time of execution), one for each
of the different homogeneous subsets of the cluster.
This is quite a common case, met in many installations of OAR.
The advance reservation feature is wanted by users who need to interact
with their job, thus be able to program the job execution time in order
to be sure to be present in front of the machines. This feature is used
a lot in research testbeds like Grid'5000 (www.grid5000.fr).

I would admit that using both the moldable job feature and the advance
reservation feature in a same use case (by a same user) is not so likely
to happen (which explain also why the bug wasn't noticed before the
release). But having both users submitting moldable jobs and users
making advance reservations will happen (the bug was reported quite
quicky actually).

For ref, the error log is the following:

[debug] [2015-02-18 21:35:26.373] [MetaSched] Begin processing of
waiting reservations (accepted reservations which do not have assigned
resources yet)
[debug] [2015-02-18 21:35:26.376] [MetaSched] [2] job is (0,u:,,)
[debug] [2015-02-18 21:35:26.379] [MetaSched] [2] add job occupation in
gantt (0,,,)
[debug] [2015-02-18 21:35:26.379] [MetaSched] [2] Add job in database
Use of uninitialized value in vec at /usr/lib/oar/oar_meta_sched line 342.
Use of uninitialized value $r in vec at /usr/lib/oar/oar_meta_sched line
357.
[debug] [2015-02-18 21:35:26.380] [MetaSched] End processing of waiting
reservations
DBD::Pg::db do failed: ERROR:  syntax error at or near )
LINE 2:   VALUES (3,)
^ at /usr/share/perl5/OAR/IO.pm line 6270.

Job 1 is a moldable job here, then job 2's scheduling causes errors in
the code of the scheduler. As a result it is not scheduled, nor executed.

The administrator of the cluster will have no clue else than install the
next release of OAR, or the patched version.

Last info: The patch actually fixes another bug, regarding the clean-up
of the resource tree structure (calls to
delete_tree_nodes_with_not_enough_resources). This is a regression bug.
It is part of the patch because it was in the same commit in the
upstream VCS.
We could consider that second issue separately, but I think it is worth
being fixed as well, eventually as a whole.

Hope I convinced you.

Thanks for your time
Best regards,
Pierre


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

Bug#726866: fixed?

[Pierre Neyron]

Hello,

I believe this bug is fixed.

/usr/share/perl5/Sbuild/ChrootSetup.pm shipped with libsbuild-perl
0.65.0-1 has:

# Secret keyring needs to be readable by 'sbuild' group.
@command = ('chmod', '640',
$conf-get('SBUILD_BUILD_DEPENDS_SECRET_KEY'));
$host-run_command(
{ COMMAND = \@command,
  USER = $conf-get('BUILD_USER'),
  PRIORITY = 0,
  DIR = '/'});

return $?;

BR
Pierre

Bug#558456: nis: please let debconf ask whether to start ypbind

[Pierre Neyron]

On Wed, 2 Dec 2009 17:03:33 + Mark Brown broo...@debian.org wrote:

 This sort of transitiory configuration is really not the sort of thing
 that should go into debconf so I don't really think that this is an
 appropriate solution. Given that the issue occurs only when installing
 on a network where no existing server is available (which is a fairly
 rare occurrence) and results in less than a minute of latency in the
 installation I don't think the drawbacks of trying to force it through
 debconf are worth it.


Hi Mark,

Even if installing a NIS server is pretty rare (and rarer and rarer), it
turns out that this point makes _automating_ a fresh NIS server
installation (e.g. in a Vagrant setup) a real pain.
I'm currently in that case and trying to figure out a nice workaround.
(any idea would be welcome)

Thanks,
Pierre


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

Bug#558456: nis: please let debconf ask whether to start ypbind

[Pierre Neyron]

On Wed, 03 Sep 2014 16:35:51 +0200 Pierre Neyron pierre.ney...@free.fr
wrote:

 Even if installing a NIS server is pretty rare (and rarer and rarer), it
 turns out that this point makes _automating_ a fresh NIS server
 installation (e.g. in a Vagrant setup) a real pain.
 I'm currently in that case and trying to figure out a nice workaround.
 (any idea would be welcome)


Answering to myself, for what it's worth, my good enough workaround:

 NISDOMAIN=MyNISDomain
 echo nis nis/domain string $NISDOMAIN | debconf-set-selections
 echo '[ $1 = nis ]  exit 101 || exit 0'  /usr/sbin/policy-rc.d;
 chmod +x /usr/sbin/policy-rc.d
 DEBIAN_FRONTEND=noninteractive apt-get install -y nis
 rm /usr/sbin/policy-rc.d
 nisdomainname $NISDOMAIN
 sed -i -e s/^\(NISSERVER=\).*/\1true/ /etc/default/nis
 /usr/lib/yp/ypinit -m  /dev/null 2 /dev/null
 service nis restart

Pierre

Bug#734176: patch proposed upstream

[Pierre Neyron]

Hello,

I proposed a patch upstream to overcome the issue.

See here:

http://thread.gmane.org/gmane.comp.gnome.apps.gkrellm/1697

It allows to not enable any new network interface by default.

BR
Pierre


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

Bug#741462: opensm: Please allow the use opensm console on loopback (default config)

[Pierre Neyron]

Package: opensm
Version: 3.3.15-2
Severity: normal

Dear Maintainer,

Console on loopback should be allowed with opensm, since it is a default
configuration in the sources (see configure --help). However, it is not allowed
with opensm Debian binary package (see opensm logs with -console=loopback set).

Please add libwrap0-dev to the package build-dep, so that the configure stop
does not fail when trying to enable the console on loopback during the build.

Thanks




-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (990, 'stable'), (550, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#722621: [Oar-devel] Bug#722621: oar-web-status, oar-common: postinst uses /usr/share/doc content (Policy 12.3)

[Pierre Neyron]

Hi Andreas,

We'll try to fix that ASAP.

Thanks for the report,

Pierre

On 12/09/2013 22:46, Andreas Beckmann wrote:
 Package: oar-web-status,oar-common
 Version: 2.5.2-3.1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: piuparts
 
 Hi,
 
 a test with piuparts revealed that your package uses files from
 /usr/share/doc in its maintainer scripts which is a violation of
 Policy 12.3: Packages must not require the existence of any files in
 /usr/share/doc/ in order to function.
 http://www.debian.org/doc/debian-policy/ch-docs.html#s12.3
 
 These files must be moved to /usr/share/$PACKAGE and may be symlinked
 from /usr/share/doc/$PACKAGE.
 
 This piuparts test prevents the installation of (most) files into
 /usr/share/doc with 'dpkg --path-exclude=...'.
 
From the attached log (scroll to the bottom...):
 
   Selecting previously unselected package oar-web-status.
   (Reading database ... 11451 files and directories currently installed.)
   Unpacking oar-web-status (from .../oar-web-status_2.5.2-3.1_all.deb) ...
   Setting up oar-web-status (2.5.2-3.1) ...
   Error: The new file /usr/share/doc/oar-web-status/examples/apache.conf does 
 not exist!
   dpkg: error processing oar-web-status (--configure):
subprocess installed post-installation script returned error exit status 1
   Errors were encountered while processing:
oar-web-status
 
   Selecting previously unselected package oar-common.
   (Reading database ... 8135 files and directories currently installed.)
   Unpacking oar-common (from .../oar-common_2.5.2-3.1_amd64.deb) ...
   Setting up oar-common (2.5.2-3.1) ...
   Adding group oardone
   Adding system user oardone
   grep: /var/lib/oar/.bash_profile: No such file or directory
   grep: /var/lib/oar/.bashrc: No such file or directory
   Error: The new file /usr/share/doc/oar-common/examples/oar.conf does not 
 exist!
   dpkg: error processing oar-common (--configure):
subprocess installed post-installation script returned error exit status 1
   Errors were encountered while processing:
oar-common
 
 
 Cheers,
 
 Andreas

-- 
Pierre NEYRON




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#720431: [Oar-devel] Bug#720431: oar: diff for NMU version 2.5.2-3.1

[Pierre Neyron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Gregor,

Sorry for the late answer, I wasn't sure about what to do.

I actually got your patch and pushed it in our git repository for the
debian packaging of our last version: 2.5.3.

This version 2.5.3 is not pushed yet to Debian's repository. We've
only published it on our dedicated repository for now, by lake of time
and some hesitations due to the change of maintainer (Philippe Le
Brouster is not working with us anymore, so I'm taking over).

So my thinking is the following:

For 2.5.2-3.1, we are fine if you push it to Debian's repo as a NMU.
If you think it's preferable however, we can package 2.5.2-4, but this
will require me to get sponsored (Vincent Danjean can help me with
that) as a Debian Maintainer for the package.

For newer versions anyway, I will need to become DM for the package.

Best regards
Pierre



On 30/08/2013 17:44, gregor herrmann wrote:
 tags 720431 + pending thanks
 
 Dear maintainer,
 
 I've prepared an NMU for oar (versioned as 2.5.2-3.1) and uploaded
 it to DELAYED/2. Please feel free to tell me if I should delay it
 longer.
 
 Regards.
 
 
 
 ___ Oar-devel mailing
 list oar-de...@lists.gforge.inria.fr 
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/oar-devel
 


- -- 
Pierre NEYRON
Ing￩nieur de Recherche CNRS
Laboratoire d'Informatique de Grenoble
Equipes MESCAL et MOAIS (LIG/INRIA)
: pierre.ney...@imag.fr - 04.76.61.53.59 :
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSIMaEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MDYwMDQyNUEzRkUyNjNDQTRERkREOURD
OTQwNkVDRURCOUY2NDA0AAoJEMlAbs7bn2QE/wAP/1o6lcppHGKmQuLVIzIptSak
o23jmkAldcj+iNb7ltM1DUyEIt7VYASNaBbP6zfNbrC9MlgISDzfc+DrBEliieGD
+yX7DJKWIcKDERyOHukpxWA9ZTO8nNvlP75wC50ldIaENGiahqudRH0XtFE5vYzj
kOaHpwNgP0MEM09YXN0VHhti0oR3Ac18twwWxHULmuRU90h8pGFGrgu/r9wv14d7
eQH4tBQlL/Z1XWkKrCNSMUljjp2MDY0CtO1eqRf974cV8YiOdoc2PWUhRtDHkPNB
EoQFwrLOH02iUkqPs6CVo+XPA1UydQ8w84kD0J7237jWNxlslpggrIToAwTAskoG
kbyB26BQRX8dye13s/yxTVW0NgQgMpli881Mgze2F3lPPnqlnC5wXXckc4++jg/8
pHS9G4KJfvm3lEQ+kFbqIDVJXbCWP+6345m0R2suRPP4wjrXmYcqwhnL2Z653xxh
O2e1skinf+4u4BbTXiG9evJaerxhjaTpnf4mabKRJ1Q0GRKe4tkXFkRjhQxqsII0
z8jLk4fCE4r76xKa8x21pdYuKHj3JgJxUPDKdWq/kwh47/FR9OTZyiSQEHKJIov6
heN7x5oWr3BzWxCjABYFRktA2VVUvxWPAQvlRXxNzVLhU6tl3Td+QfDBTwdRpqzP
N+7Ih6eTbTlB8dn33amm
=JzMP
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#652282: e16-data: e16-gnome session does not work with gnome 3

[Pierre Neyron]

Package: e16-data
Version: 1.0.0-4
Severity: important

The e16-gnome X session does not work with gnome 3.
Adding the --session gnome-fallback (as present in the gnome-classic X session) 
makes it work.

--- /usr/share/e16/misc/starte16.orig   2011-12-15 22:46:24.607779012 +0100
+++ /usr/share/e16/misc/starte162011-12-15 22:47:56.245314030 +0100
@@ -8,7 +8,7 @@
test -x /usr/bin/gconftool-2  gconftool-2 --set 
/desktop/gnome/session/required_components/windowmanager --type string e16
WINDOW_MANAGER=e16
export WINDOW_MANAGER
-   exec gnome-session
+   exec gnome-session --session gnome-fallback
;;
 *kde|KDE)
KDEWM=e16



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (100, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages e16-data depends on:
ii  dpkg  1.16.1.2

e16-data recommends no packages.

e16-data suggests no packages.

-- no debconf information



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

Bug#556862: ITP: libparse-dmidecode-perl -- Interface to SMBIOS data reported by dmidecode

[Pierre Neyron]

Package: wnpp
Severity: wishlist
Owner: Pierre Neyron pierre.ney...@free.fr

* Package name: libparse-dmidecode-perl
  Version : 0.03
  Upstream Author : Nicola Worthington nico...@cpan.org
* URL : http://search.cpan.org/~nicolaw/Parse-DMIDecode/
* License : Apache-2.0
  Programming Lang: Perl
  Description : Interface to SMBIOS data reported by dmidecode

This module provides an OO interface to SMBIOS information through the 
dmidecode command which is known to work under a number of Linux, BSD and BeOS 
variants.  

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (990, 'stable'), (200, 'testing'), (100, 'unstable'), (10, 
'experimental')
Architecture: amd64 (x86_64)



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

Bug#517925: ITP: libio-socket-socks-perl -- IO::Socket::Socks

[Pierre Neyron]

Package: wnpp
Severity: wishlist
Owner: Pierre Neyron pierre.ney...@free.fr

* Package name: libio-socket-socks-perl
  Version : 0.1
  Upstream Author : Ryan Eatmon reat...@mail.com
* URL : http://search.cpan.org/~reatmon/IO-Socket-Socks-0.1/
* License : Same as Perl
  Programming Lang: Perl
  Description : IO::Socket::Socks

IO::Socket::Socks connects to a SOCKS v5 proxy, tells it to open a
connection to a remote host/port when the object is created.  The
object you receive can be used directly as a socket for sending and
receiving data from the remote host.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (990, 'stable'), (200, 'testing'), (100, 'unstable'), (10, 
'experimental')
Architecture: amd64 (x86_64)



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

Bug#517027: ITP: liblwp-protocol-socks-perl -- adds support for the socks protocol and proxy facility to perl LWP

[Pierre Neyron]

Package: wnpp
Severity: wishlist
Owner: Pierre Neyron pierre.ney...@free.fr

* Package name: liblwp-protocol-socks-perl
  Version : 1.1
  Upstream Author : Sheridan C. Rawlins sc...@cornell.edu
* URL : http://search.cpan.org/~scr/LWP-Protocol-socks-1.1/
* License : Same as Perl
  Programming Lang: Perl
  Description : adds support for the socks protocol and proxy facility to 
perl LWP

Perl module to add to Perl LWP the capability to talk through a socks proxy.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (990, 'stable'), (200, 'testing'), (100, 'unstable'), (10, 
'experimental')
Architecture: amd64 (x86_64)



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

Bug#463779: using 2.6.27-rc6 debian rc linux kernel pkg, battery status = 133%

[Pierre Neyron]

Hi,

Using 2.6.27-rc6,
I got a 133% battery level indication in gkrellm, whereas acpi -b reports:
Battery 0: Full, 100%, design capacity 4700 mAh

Best regards,
Pierre



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

Bug#498837: ITP: libsort-naturally-perl -- Natural sort - sort lexically except for numerical parts

[Pierre Neyron]

Package: wnpp
Severity: wishlist
Owner: Pierre Neyron [EMAIL PROTECTED]


* Package name: libsort-naturally-perl
  Version : 1.02
  Upstream Author : Sean M. Burke  [EMAIL PROTECTED]
* URL : http://search.cpan.org/dist/Sort-Naturally
* License : same as Perl (Artistic or GPL-1+)
  Programming Lang: Perl
  Description : Natural sort - sort lexically except for numerical parts

Sort::Naturally exports two Perl functions, nsort and ncmp, which implement the
idea of natural sorting algorithm. With that natural sorting, numeric
substrings are compared numerically, but other word-characters are compared
lexically.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable'), (100, 'stable'), (10, 
'experimental')
Architecture: i386 (i686)



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

Bug#497409: ITP: libtest-taint-perl - perl lib to test tainting

[Pierre Neyron]

Package: wnpp
Severity: wishlist

* Package name : libtest-taint-perl
Version : 1.0.4
Upstream Author : Andy Lester [EMAIL PROTECTED]
* URL : http://search.cpan.org/dist/Test-Taint/
I debianized the package already. Everything is there:
http://oar.imag.fr/debian/misc/
* License : Same as Perl
From the README file:
Copyright 2004, Andy Lester, All Rights Reserved.
You may use, modify, and distribute this package under the same terms as
Perl itself.

Description : Perl library to test tainting
Test::Taint is an utility script to use along with
Test::More for instance in order to test tainting of Perl packages.

--
Pierre Neyron



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

Bug#484176: #484176: patch

[Pierre Neyron]

Dear David,

As I am very interested by the vblade package, I prepared a patch for 
the new upstream version (v16):
It fixes bugs #484176 (new upstream version) and #436481 (vbladed option 
management wrt the -m switch).

Besides, bug #423408 was fixed in the upstream version.

Please find below the interdiff between the 2 versions :

diff -u vblade-14/debian/changelog vblade-16/debian/changelog
--- vblade-14/debian/changelog
+++ vblade-16/debian/changelog
@@ -1,3 +1,12 @@
+vblade (16-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * New upstream release (Closes: #484176, #423408).
+  * vbladed: checking for 4 or more arguments rather than exactly 4, so 
that

+-m switchs are accepted (Closes: #436481)
+
+ -- Pierre Neyron [EMAIL PROTECTED]  Tue, 03 Jun 2008 22:47:17 +0200
+
vblade (14-1) unstable; urgency=low

  * New upstream release.  Main changes are:
diff -u vblade-14/vbladed vblade-16/vbladed
--- vblade-14/vbladed
+++ vblade-16/vbladed
@@ -7,7 +7,7 @@
# protect ourselves against the most common way or
# calling vbladed: without arguments.  While at it, we guard
# ourselves against wrong number of parameters.
-if [ $# -ne 4 ]
+if [ $# -lt 4 ]
then
echo usage: ./vblade shelf slot ethn device 2
exit 1


Thanks for your work on that package.
Best regards,

Pierre



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