Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-12-01 Thread Colin King (gmail) 

Hi Balint,


On 16/11/2023 18:55, Bálint Réczey wrote:

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 17:46):


Hi Balint,


Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:

--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
   prefix=/usr
   exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/

   Name: libtypec
   Description: USB-Type C and USB Power Delivery class devices
   Version: 0.4.0

   Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec



I think this patch application did not work out as intended, please
check the patched file.

The symbols file's first line is also still off and now the symbos
have debian package revisions.

Those are issues automatically detected by Lintian. I suggest running
lintian on the built binary packages' .changes file or populating the
packaging repository on Salsa where CI runs include lintian and many
other checks.


I ran lintian but I didn't see the errors, I used:

lintian --profile=debian --pedantic libtypec_0.4-3_source.changes

perhaps there are some extra lintian flags or config settings that I'm 
missing. Any suggestions?


Colin





Cheers,
Balint


Ah, good idea. I've refreshed package with this change. Also updated the
.symbols file and uploaded a -4 to mentors.

Colin

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-11-16 Thread Colin King (gmail) 

Hi Balint,


Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:

--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
  prefix=/usr
  exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/

  Name: libtypec
  Description: USB-Type C and USB Power Delivery class devices
  Version: 0.4.0

  Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec



Ah, good idea. I've refreshed package with this change. Also updated the 
.symbols file and uploaded a -4 to mentors.


Colin

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-11-16 Thread Colin King (gmail) 

Hi again Balint,

On 16/11/2023 11:35, Bálint Réczey wrote:

Hi Colin,

Thanks for the quick response.
Please check my other observations, too, in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58


You mentioned:

"The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch."

I'm not quite sure what is incorrect here, this file is patched already 
via debian/patches/0001-fix-libtypec-libdir.patch


For an i386 build, the .pc file in usr/share/pkgconfig contains:

prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/i386-linux-gnu
includedir=${prefix}/include/i386-linux-gnu
..

For a x86-64 build, the .pc file in usr/share/pkgconfig contains:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include/x86_64-linux-gnu
..

For an arm64 build, the .pc file in usr/share/pkgconfig contains:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/aarch64-linux-gnu
includedir=${prefix}/include/aarch64-linux-gnu
..

..so I'm a bit confused. Do you mind clarifying for me.

Colin

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-11-16 Thread Colin King (gmail) 

On 15/11/2023 13:47, Bálint Réczey wrote:

Hi Colin,

There are a few upstream source files licensed under GPL.
Please update debian/copyright to cover all the used licenses.


Updated and uploaded -3 to mentors

Thanks for the prompt review feedback. Much appreciated.

Colin



You can run 'cme update dpkg-copyright' in the source directory or any 
other tool from https://wiki.debian.org/CopyrightReviewTools 
<https://wiki.debian.org/CopyrightReviewTools> to help with the manual 
labor.


Cheers,
Balint

On 2023. Nov 15., Wed at 10:27, Bálint Réczey <mailto:bal...@balintreczey.hu>> wrote:


Hi Colin,

    Colin King (gmail) mailto:colin.i.k...@gmail.com>> ezt írta (időpont: 2023.
nov. 14., K, 17:58):
 >
 > Hi Balint,
 >
 > I've uploaded 0.4.0-2 with the suggested fixes.
 >
 > reply inlined below:
 >
 > On 09/11/2023 16:23, Bálint Réczey wrote:
     > > Hi Colin,
 > >
 > > Colin King (gmail) mailto:colin.i.k...@gmail.com>> ezt írta (időpont: 2023.
 > > nov. 7., K, 15:18):
 > >>
 > >> Hi Balint,
 > >>
 > >> Thanks for responding with the review. I was waiting for the
upstream
 > >> project to release a 0.4 with some minor fixes before
re-uploading to
 > >> mentors.
 > >>
 > >> I've addressed the issues you found as below:
 > >
 > > Please see my observations below.
 > >
 > >> On 22/10/2023 22:38, Bálint Réczey wrote:
 > >>> Hi Colin,
 > >>>
 > >>> I've checked the second upload at [1].
 > >>> As you can see in the Lintian warnings there is a .git
directory which
 > >>> is not ideal for a source package.
 > >>> I suggest using the most widely used git-buildpackage based
workflow
 > >>> where the gbp command takes care of exporting the source package
 > >>> without the .git dir from the packaging repository.
 > >>> I'd be happy to set up a packaging repo for you at
 > >>> https://salsa.debian.org/debian/libtypec
<https://salsa.debian.org/debian/libtypec> and add you as a maintainer
 > >>> as described in [2]
 > >
 > > I still hold up my offer about setting up a git repo for
packaging on
 > > Salsa. That comes with the benefit of automated fixes from Debian
 > > Janitor and I could also comment on changes right where they
happened.
 >
 > Thank you for your kind offer; I definitely think this is a good
idea,
 > please can you set this up for me. Much appreciated!

I've created the repo at https://salsa.debian.org/debian/libtypec
<https://salsa.debian.org/debian/libtypec> and
added you as a maintainer.
I've also set up CI, thus when you push your branches the pipelines
will start.

You may already be familiar with
https://dep-team.pages.debian.net/deps/dep14/
<https://dep-team.pages.debian.net/deps/dep14/> , but if not, please
check it before pushing your packaging repository.

...

 > > I think my comment here was misleading, sorry for that.
 > > Shipping *.pc is desired, shipping it in the .../libtypec.pc/
dir as a
 > > result of specifying .../libtypec.pc as the target dir in the
.install
 > > file was not desired. It was even patched to have the right
content.
 > > Please ship the .pc file in the -dev package.
 >
 > Fixed.

The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch.

...

 > > * As you switched back to use upstream's 0.4.0 SO version the
.symbols
 > > file became wrong  not matching the shipped SO version. Please fix
 > > that and also switch to the libtypec0 package name since it
needs to
 > > match upstream's major SO version
 >
 > Fixed.

The .symbols file's first line should be:
  libtypec.so.0 libtypec0 #MINVER#

See deb-symbols(5) for more details.

 > .
 > >
 > > * I'd recommend asking upstream to switch to semantic SO versioning
 > > instead of using the project's version and switching to major
version
 > > 1 when the API stabilized.
 >
 > Good idea. Will do when API changes and stabilizes.

Great!

Cheers,
Balint

 > Colin
 >
 > >
 > > Cheers,
 > > Balint
     > >
 > >> Kind regards,
 > >>
 > >> Colin
 > >>
 > >>
 > >>>

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-11-14 Thread Colin King (gmail) 

Hi Balint,

I've uploaded 0.4.0-2 with the suggested fixes.

reply inlined below:

On 09/11/2023 16:23, Bálint Réczey wrote:

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 7., K, 15:18):


Hi Balint,

Thanks for responding with the review. I was waiting for the upstream
project to release a 0.4 with some minor fixes before re-uploading to
mentors.

I've addressed the issues you found as below:


Please see my observations below.


On 22/10/2023 22:38, Bálint Réczey wrote:

Hi Colin,

I've checked the second upload at [1].
As you can see in the Lintian warnings there is a .git directory which
is not ideal for a source package.
I suggest using the most widely used git-buildpackage based workflow
where the gbp command takes care of exporting the source package
without the .git dir from the packaging repository.
I'd be happy to set up a packaging repo for you at
https://salsa.debian.org/debian/libtypec and add you as a maintainer
as described in [2]


I still hold up my offer about setting up a git repo for packaging on
Salsa. That comes with the benefit of automated fixes from Debian
Janitor and I could also comment on changes right where they happened.


Thank you for your kind offer; I definitely think this is a good idea, 
please can you set this up for me. Much appreciated!





Other observations regarding the packaging:

* There is debian/install and also there are binary package specific
*.install files which is slightly confusing.
 I suggest dropping debian/install.


Fixed


* In the debian/*.install files you need to specify only the target
dir, not the target file.


Fixed


In libtypec-dev
/usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
gets shipped, which is not desired.


Fixed


I think my comment here was misleading, sorry for that.
Shipping *.pc is desired, shipping it in the .../libtypec.pc/ dir as a
result of specifying .../libtypec.pc as the target dir in the .install
file was not desired. It was even patched to have the right content.
Please ship the .pc file in the -dev package.


Fixed




* libtypec.h seems to be the same on all architectures. Does it have
to be shipped in a multiarch include location?


Fixed. Now in /usr/include and in the multiarch include location


* Binary packages in debian/control are not marked as Multi-Arch: same
* Please target experimental. The package needs to pass NEW and to
migrate to testing it will need a new source-only upload anyway.



Fixed.

Please review the 0.4 release upload and let me know if this can be
sponsored further to the changes I made.


* Both libtypec-dev.install and libtypec1.install lists
usr/lib/${DEB_HOST_MULTIARCH} and as a result both packages ship the
*.so symlink and *.so.0.4.0.
Please ship *.so.0.4.0 in the library package and the *.so symlink in
the -dev package only.


Fixed.



* As you switched back to use upstream's 0.4.0 SO version the .symbols
file became wrong  not matching the shipped SO version. Please fix
that and also switch to the libtypec0 package name since it needs to
match upstream's major SO version


Fixed.

.


* I'd recommend asking upstream to switch to semantic SO versioning
instead of using the project's version and switching to major version
1 when the API stabilized.


Good idea. Will do when API changes and stabilizes.

Colin



Cheers,
Balint


Kind regards,

Colin



Cheers,
Balint

[1] https://mentors.debian.net/package/libtypec/
[2] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
 wrote:

Hi,

I've uploaded a fixed package that addresses these issues.

Colin

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

* Package name : libtypec
  Version  : 0.3-1
* URL  : https://github.com/Rajaram-Regupathy/libtypec



 libtypec1 - generic interface for efficient USB-C port management
 libtypec-dev - Development files for an interface for USB-C port management



libtypec (0.3-1) unstable; urgency=low
.
  * Initial release (Closes: #1023477)
  * Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-11-07 Thread Colin King (gmail) 

Hi Balint,

Thanks for responding with the review. I was waiting for the upstream 
project to release a 0.4 with some minor fixes before re-uploading to 
mentors.


I've addressed the issues you found as below:

On 22/10/2023 22:38, Bálint Réczey wrote:

Hi Colin,

I've checked the second upload at [1].
As you can see in the Lintian warnings there is a .git directory which
is not ideal for a source package.
I suggest using the most widely used git-buildpackage based workflow
where the gbp command takes care of exporting the source package
without the .git dir from the packaging repository.
I'd be happy to set up a packaging repo for you at
https://salsa.debian.org/debian/libtypec and add you as a maintainer
as described in [2]

Other observations regarding the packaging:

* There is debian/install and also there are binary package specific
*.install files which is slightly confusing.
I suggest dropping debian/install.


Fixed


* In the debian/*.install files you need to specify only the target
dir, not the target file.


Fixed


   In libtypec-dev
/usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
gets shipped, which is not desired.


Fixed


* libtypec.h seems to be the same on all architectures. Does it have
to be shipped in a multiarch include location?


Fixed. Now in /usr/include and in the multiarch include location


* Binary packages in debian/control are not marked as Multi-Arch: same
* Please target experimental. The package needs to pass NEW and to
migrate to testing it will need a new source-only upload anyway.



Fixed.

Please review the 0.4 release upload and let me know if this can be 
sponsored further to the changes I made.


Kind regards,

Colin



Cheers,
Balint

[1] https://mentors.debian.net/package/libtypec/
[2] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
 wrote:

Hi,

I've uploaded a fixed package that addresses these issues.

Colin

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

   * Package name : libtypec
 Version  : 0.3-1
   * URL  : https://github.com/Rajaram-Regupathy/libtypec



libtypec1 - generic interface for efficient USB-C port management
libtypec-dev - Development files for an interface for USB-C port management



   libtypec (0.3-1) unstable; urgency=low
   .
 * Initial release (Closes: #1023477)
 * Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#955954: thermald: Depends on deprecated dbus-glib

2023-08-31 Thread Colin King (gmail) 

This issue has been reported to the upstream project:

https://github.com/intel/thermal_daemon/issues/416

..looking like it will be resolved in the next release of thermald

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-08-03 Thread Colin King (gmail) 

Hi,

I've uploaded a fixed package that addresses these issues.

Colin

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

  * Package name : libtypec
Version  : 0.3-1
  * URL  : https://github.com/Rajaram-Regupathy/libtypec



   libtypec1 - generic interface for efficient USB-C port management
   libtypec-dev - Development files for an interface for USB-C port management



  libtypec (0.3-1) unstable; urgency=low
  .
* Initial release (Closes: #1023477)
* Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-07-18 Thread Colin King (gmail) 

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

  * Package name : libtypec
Version  : 0.3-1
  * URL  : https://github.com/Rajaram-Regupathy/libtypec



   libtypec1 - generic interface for efficient USB-C port management
   libtypec-dev - Development files for an interface for USB-C port management



  libtypec (0.3-1) unstable; urgency=low
  .
* Initial release (Closes: #1023477)
* Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:


Thanks, which lintian options did you use so I can santicy check my fixes?

Colin



E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

2023-07-17 Thread Colin King (gmail) 

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libtypec":

 * Package name : libtypec
   Version  : 0.3-1
   Upstream contact : Rajaram Regupathy 
 * URL  : https://github.com/Rajaram-Regupathy/libtypec
 * License  : MIT
 * Vcs  : [fill in URL of packaging vcs]
   Section  : utils

The source builds the following binary packages:

  libtypec1 - generic interface for efficient USB-C port management
  libtypec-dev - Development files for an interface for USB-C port 
management


To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/libtypec/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libt/libtypec/libtypec_0.3-1.dsc


Changes for the initial release:

 libtypec (0.3-1) unstable; urgency=low
 .
   * Initial release (Closes: #1023477)
   * Add patch 0001-fix-libtypec-so-version.patch to fix .so name version

Regards,

Colin Ian King

Bug#1023477: ITP: libtypec: progress request

2023-07-11 Thread Colin King (gmail) 

Hi,

The ITP for this library was placed back in 5th Nov 2022; I was 
wondering if there is any progress on this?  If not, is it possible for 
me to take ownership and package this as I'm keen to ensure this is in 
Debian sooner than later.


Regards,

Colin

Bug#1038726: ITP: qatlib -- Intel(R) QuickAssist Technology hardware accelleration for security authentication and compression

2023-06-20 Thread Colin King (gmail) 

Package: wnpp
Severity: wishlist
Owner: Colin Ian King 
X-Debbugs-Cc: debian-de...@lists.debian.org, colin.i.k...@gmail.com

* Package name: qatlib
  Version : 23.02.0
  Upstream Contact: giovanni.cabi...@intel.com
* URL : https://github.com/intel/qatlib
* License : BSD-3-Clause
  Programming Lang: C, x86 assemvler
  Description : Intel(R) QuickAssist Technology hardware 
accelleration for security authentication and compression


Intel(R) QuickAssist Technology (Intel(R) QAT) provides hardware
acceleration for offloading security, authentication and compression
services from the CPU, thus significantly increasing the performance
and efficiency of standard platform solutions.

Its services include symmetric encryption and authentication, asymmetric
encryption, digital signatures, RSA, DH and ECC, and lossless data
compression.

It provides user space libraries that allow access to Intel(R) 
QuickAssist devices and expose the Intel(R) QuickAssist APIs and sample 
codes.


See also: https://wiki.debian.org/QAT

I intend to maintain this much like other Intel related Debian packages

Sincerely,

Colin Ian King

Bug#1036356: stress-ng: autopkgtest failures on 32 bit architectures

2023-05-20 Thread Colin King (gmail) 
Thanks for the update, I'm planning to make a stress-ng release that 
contains this fix before the end of next week to address this and 
several other issues.


Colin


On 19/05/2023 16:21, Benjamin Drung wrote:

Package: stress-ng
Version: 0.15.07-1
Severity: serious
Tags: patch
Justification: autopkgtest failures
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

The autopkg tests on 32 bit architectures fail. In Ubuntu, the attached
patch was applied to fix the autopkgtest:

   * Cherry-pick upstream commit "stress-pthread: use 64 bit tid_addr to fix
 stack clobbering on 32 bit platforms" and "stress-pthread: fix big endian
 tid addr for 32 bit systems" to fix test failures on 32 bit architectures
 (LP: #2019079)


Thanks for considering the patch.

Bug#1024089: ITP: accel-config -- Utility for configuring the DSA subsystem for Linux

2022-11-15 Thread Colin King (gmail) 

Hi Nick,

I hadn't realized you were going to help the Intel folks on this, so 
apologies for usurping you. I've been maintaining quite a few Intel 
packages in Debian and I picked this up since I'm a new Intel employee 
and thought it would be useful to help on the final iterations of the

packaging.

I'm 99% the way to getting this sponsored so I think I'm almost complete 
on this work item now.


Colin

On 14/11/2022 19:56, nick black wrote:

Colin Ian King left as an exercise for the reader:

Package: wnpp
Severity: wishlist
Owner: Colin Ian King 
X-Debbugs-Cc: debian-de...@lists.debian.org


Hey Colin! I'm hoping to work with the Intel folks on this, and
it seems you started the endeavor and guided it thus far. Can I
assist you in any way at the moment?

Bug#1001666: stress-ng: flaky autopkgtest

2021-12-13 Thread Colin King (gmail) 

Hi Sebastian,

thanks for reporting this. Is is OK to ask a few questions as I've never 
seen this before on a wide range of kit that I test this on.


1. Is this failure repeatable? (I'm not sure how it occurs since there 
is a SIGSEGV handler for these cases).

2. Does it fail on specific machines?
3. What CPU model is the machine it fails on?

I've tried to understand this failure, but so far I'm quite perplexed by 
it, so maybe it's a CPU specific caching behavior that I have misunderstood.


Any assistance with the questions above would be most useful,

Regards,

Colin


On 13/12/2021 21:48, Sebastian Ramacher wrote:

Source: stress-ng
Version: 0.13.08-1
Severity: important
X-Debbugs-Cc: sramac...@debian.org

The autopkgtests of stress-ng fail from time to time:
| stress-ng: 20:49:12.58 info:  [1091] unsuccessful run completed in 0.51s
| stress-ng: 20:49:12.58 fail:  [1091] cache instance 3 corrupted bogo-ops 
counter, 2 vs 0
| stress-ng: 20:49:12.58 fail:  [1091] cache instance 3 hash error in bogo-ops 
counter and run flag, 796547380 vs 0
| stress-ng: 20:49:12.58 fail:  [1091] metrics-check: stressor metrics 
corrupted, data is compromised
| cache FAILED
...
| zlib PASSED
| 42 PASSED
| 1 FAILED, cache
| 0 SKIPPED

See
https://ci.debian.net/data/autopkgtest/testing/amd64/s/stress-ng/17550292/log.gz
for a recent failure

Cheers

Bug#793303: marking this as "won't fix" and closing the bug

2015-09-07 Thread Colin King (gmail) 
Hi there, since this is not fixable, I'm marking this as won't fix.

Bug#781506: thermald: some documentation for the user

2015-09-01 Thread Colin King (gmail) 
Hi Ritesh,

does man 5 thermal-conf.xml provide enough information?

Colin