Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec
On Tue, 2024-03-12 at 11:15 -0500, Richard Laager wrote: > Control: reopen -1 > > On 2024-03-12 11:10, MOESSBAUER, Felix wrote: > > On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote: > > > This is intentional. The logging is optional and whether the > > > directory > > > exists controls this. > > > > Hi Richard, > > > > that's a quite uncommon interface. Is this at least documented > > somewhere? > > ntp.conf Okayy... I was just looking at the manpage. > > > Also the "error" should be downgraded to a "warning" at > > least. > > Didn't I do that? Right. I re-tested on a bookworm system where this issue first popped up. Anyways, thanks for the pointer. Felix > > -- Siemens AG, Technology Linux Expert Center
Bug#1055342: RFA: kas -- Setup tool for bitbake based projects
Hi Bastian, yesterday kas 4.3 was released. I just adapted the packaging and uploaded it to mentors [1]. Please check: [1] https://mentors.debian.net/package/kas/ Best regards, Felix -- Siemens AG, Technology Linux Expert Center
Bug#1055342: RFA: kas -- Setup tool for bitbake based projects
Hi, I would be willing to continue the maintenance of this package, together with the debian python team. I'm quite familiar with this component, as I contributed a lot to the upstream project. Currently I have to maintain this via a sponsor, but once I get advocated to a DM, I can also maintain it directly. Best regards, Felix Moessbauer -- Siemens AG, Technology Linux Expert Center
Bug#1063840: RFS: python-airspeed/0.6.0-1 -- Python template engine
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-airspeed": * Package name : python-airspeed Version : 0.6.0-1 Upstream contact : Steve Purcell * URL : https://github.com/purcell/airspeed * License : BSD-2-Clause * Vcs : https://salsa.debian.org/python-team/packages/python-airspeed Section : python The source builds the following binary packages: python3-airspeed - Python template engine To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-airspeed/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-airspeed/python-airspeed_0.6.0-1.dsc Changes since the last upload: python-airspeed (0.6.0-1) unstable; urgency=medium . * fix package short description * update debian standards version to 4.6.2 * add multi-arch specifier * execute tests with unittest * New upstream version 0.6.0 Regards, -- Siemens AG, Technology Linux Expert Center
Bug#1063766: RFS: librtpi/1.0.0-1 [ITP] -- realtime capable pthread locking primitives (lib)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "librtpi": * Package name : librtpi Version : 1.0.0-1 Upstream contact : Gratian Crisan * URL : https://gitlab.com/linux-rt/librtpi * License : LGPL-2.1-only * Vcs : https://salsa.debian.org/fmoessbauer/librtpi Section : libs The source builds the following binary packages: librtpi-dev - realtime capable pthread locking primitives (dev) librtpi1 - realtime capable pthread locking primitives (lib) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/librtpi/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libr/librtpi/librtpi_1.0.0-1.dsc Changes for the initial release: librtpi (1.0.0-1) unstable; urgency=medium . * Initial release. (Closes: #1063327) Regards, Felix Moessbauer -- Siemens AG, Technology Linux Expert Center
Bug#1063763: RFS: python-shtab/1.6.5-1 -- Automagic shell tab completion for Python CLI applications
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-shtab": * Package name : python-shtab Version : 1.6.5-1 Upstream contact : supp...@iterative.ai * URL : https://docs.iterative.ai/shtab/ * License : Apache-2.0 * Vcs : https://salsa.debian.org/python-team/packages/python-shtab Section : python The source builds the following binary packages: python3-shtab - Automagic shell tab completion for Python CLI applications To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-shtab/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-shtab/python-shtab_1.6.5-1.dsc Changes since the last upload: python-shtab (1.6.5-1) unstable; urgency=medium . * New upstream version 1.6.5 Regards, -- Siemens AG, Technology Linux Expert Center
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote: > Package: base-files > Version: 12.4+deb12u1 > Followup-For: Bug #1039979 > Control: tags -1 patch > > I attach a patch to change absolute symlinks to relative symlinks, which would fix this bugreport if you choose to do so. At least the /var/run directory is also created as a symlink to ../run by tmpfiles.d: /usr/lib/tmpfiles.d/var.conf from the systemd package contains: L /var/run - - - - ../run There is also a proposal to update the debian policies regarding the directory structure below /var: https://lists.debian.org/debian-policy/2023/06/msg00016.html Especially for read-only rootfs images with a dedicated (unpopulated) /var partition, a solution using tmpfiles.d would be much appreciated. But it is tricky to find out what is still missing as these directories often get created in the postinstall scripts. Best regards, Felix Moessbauer -- Siemens AG, Technology Linux Expert Center
Bug#1057643: onednn: add support for loongarch64
On Wed, 2023-12-06 at 20:35 +0800, zhangdandan wrote: > Source: onednn > Version: 2.7.4-2 > Severity: wishlist > Tags: patch > User: debian-loonga...@lists.debian.org > Usertags: loong64 > > Dear maintainers, > > The onednn source package lacks LoongArch architecture support. > We need to add loongarch64 support in d/control and source code. > > Please consider the patch I have attached. > The onednn source package was compiled successfully on my local > loong64 > rootfs environment. Hi, I just saw this patch flying by and looked into it (I'm not a maintainer for this package). The following lines are very likely not correct: ++ # For native compilation tune for the host processor ++if (CMAKE_SYSTEM_PROCESSOR STREQUAL CMAKE_HOST_SYSTEM_PROCESSOR) ++append(DEF_ARCH_OPT_FLAGS "-march=native") ++endif() We must not compile with -march=native, as this makes the build dependent on the build machine. By that it is neither portable nor reproducible anymore. Felix > And the test cases passed, for examples, > ``` > .. > 101/101 Test #101: noexcept-cpp > . > Passed 0.00 sec > 100% tests passed, 0 tests failed out of 101 > Total Test time (real) = 177.87 sec > ``` > If you have any questions, you can contact me at any time. > > thanks, > Dandan Zhang >
Bug#910727: Overlays cannot be applied to dtbs - missing DTC_FLAGS='-@'
On Sun, 12 Feb 2023 18:52:07 +0100 Nicolas Frattaroli wrote: > Hello, > > I realise this is quite an old bug, but it would still be of interest > to me to get this enabled. The -@ option will increase the size of the > compiled device tree blobs somewhat, but on the flipside, u-boot- menu's > device tree overlay functionality will actually be useful. The increase is around 30% in average. For the linux-image-6.1.0-10- arm64, we have around 30MB of dtb files (uncompressed). By that, the package would grow by 10MB (uncompressed) or even less when compressed. > > In my case, I'm interested in this for PINE64's Quartz64 lineup of ARM > devices. Since these are development boards that expose non- enumerating > protocols like I2C and SPI, the use of device tree overlays is pretty > much required to add additional modules to the board. On many (if not most) arm based boards, these device tree overlays are very useful. There are also many kernel patches about enabling the symbol support on a per-device basis. However, kernel devs seem to have some mixed feelings about that. A proposed solution is to enable this at distro level [1]. @Ben: Would it be an accepted solution to enable the DTC_FLAGS += -@ for all armhf, armmp, arm64 and riscv devices? Felix [1] https://www.spinics.net/lists/devicetree/msg622660.html > > Kind regards, > Nicolas Frattaroli > > > >
Bug#1035489: krb5-config: missing dependency to C compiler
On Thu, 2023-05-04 at 09:21 -0700, Russ Allbery wrote: > Sam Hartman writes: > > > We could represent this as a dependency or a recommends if there is > > some > > special reason that libkrb5-dev needs the dependency. krb5-config > > not > > working alone is not enough to justify a depends relationship: as I > > understand it (Russ please correct me if I'm getting this wrong > > from > > memory), the policy requirement is not that every program in a > > package > > work with the installed dependencies, but that the package as a > > whole > > work. > > Right, the requirement is that the core functionality work, but some > things may not unless Recommends and Suggests are met. But we don't > put > Recommends and Suggests of compilers on every *-dev package either, > so I > think *-dev packages are a bit of an unenumerated special case. Agree. I found this issue in a more complex dependency chain of python packages, where one package called this tool during during the build of the wheel (pip of course...). In the end, `krb5-config --cflags krb5` was called, which will definitely be consumed by a c compiler (and by that build-essential should be installed anyways). However, when looking at the manpage of krb5-config, not all options are actually related to the build environment. That's why I opened this issue, as the tool cannot be used at all in case no compiler is installed. If this is acceptable according to the debian policies, we can also close this bug. > > > I.E. I could say that we care far more about the pkgconfig .pc > > files, > > krb5-config is legacy, and so policy does not force us to depend on > > a > > compiler even though krb5-config is kind of useless without it. > > I would argue that the pkgconfig .pc files are also fairly useless > without > a compiler, just with one more step of separation. :) I could IMHO this is somehow different, as .pc files are basically just configuration and the pkg-config tool also works without having a build environment. > imagine > theoretical use cases where one wanted to inspect what flags would be > recommended without using them on that system, but I would want to > know > that someone encountered that situation in the real world before > worrying > too much about it. > > My personal experience watching folks who are new to Debian who want > to > compile something is that they encounter the missing toolchain > somewhat > randomly and attribute that to somewhat random missing dependencies > until > someone points out they should just install build-essential if > they're > going to be compiling software, and then they encode that in their > normal > practices and resolve the problem that way. This isn't the most > user-friendly setup, to be sure, but I wonder if the path is to more > prominently document that people should install build-essential or > the > equivalent if they're going to be building software, rather than > adding > individual dependencies. Agree. Felix > > If we go down the dependency route, IMO it should be handled by > debhelper > or similar machinery; I don't think libkrb5-dev is particularly > special in > this regard, so fixing this in the krb5 package feels wrong to me. > > > There does appear to be a c-compiler virtual package. > > We could depend on gcc|c-compiler. > > Oh, there is indeed, sorry. I missed that because I was looking at > the > clang package instead of the clang-16 package. >
Bug#1035489: krb5-config: missing dependency to C compiler
Package: libkrb5-dev Version: 1.20.1-1+b1 Severity: important Dear Maintainer, the krb5-config tool needs a C compiler to work at all: krb5-config /usr/bin/krb5-config: 1: cc: not found Failed to find installation architecture To reproduce, just install libkrb5-dev (e.g. in the debian:bookworm container) and call krb5-config. Once a cc is installed (e.g. gcc), the tool works properly. This bug affects at least bullseye and bookworm. Best regards, Felix Moessbauer -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkrb5-dev depends on: ii krb5-multidev 1.20.1-1+b1 libkrb5-dev recommends no packages. Versions of packages libkrb5-dev suggests: pn krb5-doc -- no debconf information
Bug#1025034: linux-image-6.0.0-0.deb11.2-amd64: snd fails on thinkpad
On Mon, 2022-11-28 at 18:00 -0500, Mark A. Hershberger wrote: > Package: src:linux > Version: 6.0.3-1~bpo11+1 > Severity: normal > > I updated to this kernel and sound stopped working. Gnome shows the > output device (when it is working) as “Speaker - Tiger Lake-LP Smart > Sound Technology Audio Controller”. Same issue here, with Lenovo Thinkpad X13. Information from dmidecode: Manufacturer: LENOVO Product Name: 20WLS4VJ07 Version: ThinkPad X13 Gen 2i With 5.19 everything works properly. > > I found a conversation about a similar bug here: > > > https://lore.kernel.org/lkml/3f207f82-e177-c833-b2b0-ca9e64a6e...@linux.intel.com/T/ The reason is well documented in this link and this has already been fixed upstream in the 6.0.x branch. Don't know if the maintainers want to update this 6.0 kernel or simply move on to 6.1. Felix > > -- System Information > Debian Release: bookworm/sid > Kernel Version: Linux gabriel 5.19.0-0.deb11.2-amd64 #1 SMP > PREEMPT_DYNAMIC Debian 5.19.11-1~bpo11+1 (2022-10-03) x86_64 > GNU/Linux >
Bug#1018459: Maintainer proposed patch to remove dep
Hi Stephan, The maintainer just release version 0.5.20 and I did update the packaging. While at it, I also added autopkgtest - as you recommended. Could you please release and upload. Thanks! Felix From: Stephan Lachnit Sent: Wednesday, August 31, 2022 10:55 AM To: Moessbauer, Felix (T CED SES-DE) Cc: 1018...@bugs.debian.org Subject: Re: Maintainer proposed patch to remove dep Hi Felix, Thank you for quickly taking care of this, please ping me again when the new version is ready to upload. Cheers, Stephan On Tue, Aug 30, 2022 at 7:24 PM Moessbauer, Felix mailto:felix.moessba...@siemens.com>> wrote: Hi, I just got into contact with the upstream maintainer. He already proposed a patch to remove this dependency and is willing to cut a new release after we tested this. Then I'll bump the version and close the bug (via Stephan). [1] https://github.com/purcell/airspeed/issues/59<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpurcell%2Fairspeed%2Fissues%2F59=05%7C01%7Cfelix.moessbauer%40siemens.com%7C330d508e90ee409ea75708da8b2e82a7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637975329116814735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=H848LaoN21rCL41g7tp9c1mFdWt3SUFPkJSDVMCPkRQ%3D=0> -- Siemens AG, Linux Expert Center Otto-Hahn-Ring 6, 81739 München, Germany
Bug#1018459: Maintainer proposed patch to remove dep
Hi, I just got into contact with the upstream maintainer. He already proposed a patch to remove this dependency and is willing to cut a new release after we tested this. Then I'll bump the version and close the bug (via Stephan). [1] https://github.com/purcell/airspeed/issues/59 -- Siemens AG, Linux Expert Center Otto-Hahn-Ring 6, 81739 München, Germany
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Hi Stephan, Thanks for the review. I changed the name of the package, renamed the project on salsa and cut the release. This one should be ready to be uploaded. PS: Looks like the repology site currently has some TLS issues. Happy Coding! Felix From: Stephan Lachnit Sent: Sunday, July 3, 2022 11:35 AM To: Moessbauer, Felix (T CED SES-DE) Cc: 1012...@bugs.debian.org Subject: Re: ITP: shtab -- generator for shell tab completion files for python projects Hi Felix, The package is looking good so far, I only request one change, namely renaming the source package from shtab to python-shtab. The reason for this prefix is that else repology.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frepology.org%2F=05%7C01%7Cfelix.moessbauer%40siemens.com%7C4fc331a448bf41d9ddef08da5cd74b31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924377004473576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=LzOv7h88VjrbLZ6L%2B32Jc0CL8PIM4xCNU68LQAWJeC8%3D=0> won't be able to map the package automatically. Cheers, Stephan On Wed, Jun 22, 2022 at 9:25 PM Stephan Lachnit mailto:stephanlach...@debian.org>> wrote: Hi Felix, I will take a look at the package sometime next week. I'm currently packing my stuff to move to Geneva, so I don't really have that much time right now. Feel free to ping though in case I forget :) Cheers, Stephan On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix mailto:felix.moessba...@siemens.com>> wrote: Dear maintainers, the initial packaging of shtab is implemented in [1] and should be ready for a review. @stephan It would be great if you could sponsor this package. We talked about that at Debian Reunion Hamburg. [1] https://salsa.debian.org/python-team/packages/shtab<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fpython-team%2Fpackages%2Fshtab=05%7C01%7Cfelix.moessbauer%40siemens.com%7C4fc331a448bf41d9ddef08da5cd74b31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924377004473576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IJNiSmE%2BPaFs4RfhI9SftWKZkaL2lD4StdeaDTXO6iE%3D=0> Best regards, Felix Moessbauer Siemens AG
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Hi Stephan, Thanks for the review. I changed the name of the package, renamed the project on salsa and cut the release. This one should be ready to be uploaded. Happy Coding! Felix From: Stephan Lachnit Sent: Sunday, July 3, 2022 11:43 AM To: Moessbauer, Felix (T CED SES-DE) Cc: 1013...@bugs.debian.org Subject: Re: Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java Hi Felix, Looking good as well. Please also rename the source to python-airspeed and do a dch -r, then I'll upload. Cheers, Stephan On Thu, Jun 30, 2022 at 9:19 AM Stephan Lachnit mailto:stephanlach...@debian.org>> wrote: Hi Felix, If there is nobody else, I can sponsor this as well. Will try to find some time on Sunday to review your work :) Cheers, Stephan On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix mailto:felix.moessba...@siemens.com>> wrote: Dear maintainers, the initial packaging for python3-airspeed is now ready at [1] and has a green salsa CI. It should be ready for a review. @Stephan: Would you like to sponsor this package as well? [1] https://salsa.debian.org/python-team/packages/airspeed<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fpython-team%2Fpackages%2Fairspeed=05%7C01%7Cfelix.moessbauer%40siemens.com%7C12c8e91803f2425eac3408da5cd8728d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924381944910507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hIHf6BGVN6PYFT%2FBhgmHAl5ksLaKuKxjMC%2BPTfYIOoA%3D=0> Best regards, Felix Moessbauer Siemens AG
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Dear maintainers, the initial packaging for python3-airspeed is now ready at [1] and has a green salsa CI. It should be ready for a review. @Stephan: Would you like to sponsor this package as well? [1] https://salsa.debian.org/python-team/packages/airspeed Best regards, Felix Moessbauer Siemens AG
Bug#1013425: ITP: airspeed -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Of course the ITP is for the python airspeed package, not for wnpp. Sorry for the noise. * Package name: airspeed Version : 0.5.19 Upstream Author : Steve Purcell mailto:st...@pythonconsulting.com>> * URL : https://github.com/purcell/airspeed * License : BSD-2-Clause Programming Lang: Python Description : Airspeed is a powerful and easy-to-use templating engine for Python that aims for a high level of compatibility with the popular Velocity library for Java. Best regards, Felix
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Dear maintainers, the initial packaging of shtab is implemented in [1] and should be ready for a review. @stephan It would be great if you could sponsor this package. We talked about that at Debian Reunion Hamburg. [1] https://salsa.debian.org/python-team/packages/shtab Best regards, Felix Moessbauer Siemens AG
Bug#1008722: Possible bugfix
Hi Sudip, > -Original Message- > From: Sudip Mukherjee > Sent: Sunday, April 10, 2022 9:10 PM > > Hi Felix, > > On Wed, Apr 6, 2022 at 1:27 PM Moessbauer, Felix > wrote: > > > > Hi Sudip, > > > > Unfortunately I found more races in the build. > > I am thinking of disabling parallel jobs while building. That should fix the > problem for now. Your thoughts ? That's probably the best strategy, until these issues are fixed upstream. We locally already use DEB_BUILD_PROFILES="parallel=1" to mitigate it. While we are at it: Please also add the missing build deps "flex" and "bison". Regards, Felix > > > -- > Regards > Sudip
Bug#1008722: Possible bugfix
Hi Sudip, Unfortunately I found more races in the build. There has to be something more general to be wrong with these Makefiles: 2022-04-06 12:14:27 - ERROR - --- debian/libtracefs1.symbols (libtracefs1_1.3.0-1_amd64) 2022-04-06 12:14:27 - ERROR - +++ dpkg-gensymbolsyDWb5y 2022-04-06 12:14:15.730437201 + 2022-04-06 12:14:27 - ERROR - @@ -114,7 +114,7 @@ 2022-04-06 12:14:27 - ERROR - tracefs_printf@Base 1.1.1 2022-04-06 12:14:27 - ERROR - tracefs_put_tracing_file@Base 0.0~git20201211.ca6a929 2022-04-06 12:14:27 - ERROR - tracefs_set_loglevel@Base 1.2.0 2022-04-06 12:14:27 - ERROR - - tracefs_sql@Base 1.3.0 2022-04-06 12:14:27 - ERROR - +#MISSING: 1.3.0-1# tracefs_sql@Base 1.3.0 2022-04-06 12:14:27 - ERROR - tracefs_synth_add_compare_field@Base 1.3.0 2022-04-06 12:14:27 - ERROR - tracefs_synth_add_end_field@Base 1.3.0 2022-04-06 12:14:27 - ERROR - tracefs_synth_add_match_field@Base 1.3.0 2022-04-06 12:14:27 - ERROR - dh_makeshlibs: error: failing due to earlier errors Also found similar issues for libtraceevent. To keep things maintainable, I'll add a dedicated bug report. Best regards, Felix -- Siemens AG, Technology, T CED SES-DE Otto-Hahn-Ring 6, 81739 München, Germany
Bug#1008722: Possible bugfix
Hi, I debugged this further and found that the problem is a partially-written tracefs-sqlhist.o file. With the patch in [1] I can no longer reproduce the bug. Still, I don't fully understand why it is required to explicitly mention the dependency to tracefs-sqlhist.c. [1] https://salsa.debian.org/fmoessbauer/libtracefs/-/commit/1312d11f371bda6ff88bac518a5347a8cf8a9105 Felix -- Siemens AG, Technology, T CED SES-DE Otto-Hahn-Ring 6, 81739 München, Germany
Bug#1008722: Additional details on the build error
> -Original Message- > From: Sudip Mukherjee > Sent: Thursday, March 31, 2022 12:07 PM > To: Moessbauer, Felix (T CED SES-DE) > Cc: Schmidt, Adriaan (T CED SES-DE) ; > 1008...@bugs.debian.org > Subject: Re: Bug#1008722: Additional details on the build error > > Hi, > > On Thu, Mar 31, 2022 at 10:57 AM Moessbauer, Felix > wrote: > > > > Hi, > > > > here are some additional details on the bug. > > I'm also not 100% sure if the patch from above actually fixes the issue. > > Looks like it is already applied. > > Yes, I checked its already applied. Can you please let me know where can I > get a > log for this failure, I could not find any failure in the buildd. Hi, we are building that locally with sbuilder. Attached you will find a log. I also just created a branch on salsa to test the fix [1]. I'll pass it through our CI and report back if that helps. In case it helps, I'll send it to the upstream list. While we are at it: I also stumbled upon similar issues in libtraceevent, but want to sort out one at a time. [1] https://salsa.debian.org/fmoessbauer/libtracefs/-/tree/felix/fix-ftbfs Felix > > > > -- > Regards > Sudip libtracefs-sbuild-error.log.gz Description: libtracefs-sbuild-error.log.gz
Bug#1008722: Additional details on the build error
Hi, here are some additional details on the bug. I'm also not 100% sure if the patch from above actually fixes the issue. Looks like it is already applied. The issue is a missing symbol: tracefs_set_loglevel@Base 1.2.0 - tracefs_sql@Base 1.3.0 +#MISSING: 1.3.0-1# tracefs_sql@Base 1.3.0 This symbol is declared in include/tracefs.h and defined in src/tracefs-sqlhist.c. The race condition results in linking tracefs-sqlhist.o without having src/tracefs-sqlhist.c compiled. This can be checked with readelf: readelf -s src/tracefs-sqlhist.o | grep tracefs_sql 94: 30fe 375 FUNCGLOBAL DEFAULT1 tracefs_sql But on some runs, it is missing. Probably because we overwrite the dep (src/Makefile): tracefs-sqlhist.o: sqlhist.tab.h Another strange thing is that the files that are generated with flex / bison are checked in, but sometimes this is not detected correctly. In case this is not detected, the build also fails because bison and flex are not added as dependencies (hence are not installed by sbuilder). We should also clarify this with upstream. Felix -- Siemens AG, Technology, T CED SES-DE Otto-Hahn-Ring 6, 81739 München, Germany
Bug#1002590: ITP: wayvnc -- VNC server for wlroots-based Wayland compositors
On Fri, 24 Dec 2021 22:00:47 +0100 Johannes Schauer Marin Rodrigues wrote: > Package: wnpp > Severity: wishlist > Owner: Johannes Schauer Marin Rodrigues > X-Debbugs-Cc: debian-de...@lists.debian.org, jo...@debian.org > > * Package name : wayvnc > Version : 0.4.1 > Upstream Author : Andri Yngvason > * URL : https://github.com/any1/wayvnc > * License : ISC > Programming Lang: C > Description : VNC server for wlroots-based Wayland compositors > > This is a VNC server for wlroots-based Wayland compositors. It attaches > to a running Wayland session, creates virtual input devices, and exposes > a single display via the RFB protocol. The Wayland session may be a > headless one, so it is also possible to run wayvnc without a physical > display attached. > > Hi, there is already a PR on the wayvnc project with a working debianzation [1]. The author of [1] also added debianizations for aml [2] and neatvnc [3] which are dependencies. Don't know if we need dedicated ITPs for them as well. Felix! [1] https://github.com/any1/wayvnc/pull/116 [2] https://github.com/any1/aml/pull/7 [3] https://github.com/any1/neatvnc/pull/61
