Help setting dbconfig-common for MariaDB, not MySQL

Hi, please pardon my ignorance about Debian install. I'm distributing a software which could use various DBMS'es by setting a number of parameters. Example parameters are only given for MariaDB. I distribute a debian/ directory that Debian users can use to prepare a package instead of

Re: Help trying to debug an sbuild failure?

On Wed, Dec 28, 2022 at 12:10:51AM +0100, Johannes Schauer Marin Rodrigues wrote: > Note, that if you keep upgrading a Debian unstable chroot across multiple > releases, it will end up looking slightly different than a freshly > debootstrapped Debian unstable chroot. So I think there is value in

Re: Help trying to debug an sbuild failure?

Hi, Quoting Theodore Ts'o (2022-12-27 05:19:45) > On Mon, Dec 26, 2022 at 08:45:53PM +0100, Santiago Vila wrote: > > El 26/12/22 a las 20:29, Theodore Ts'o escribió: > > > I: The directory does not exist inside the chroot. > > > > This is really a problem with schroot. I guess that this will not

Re: Help trying to debug an sbuild failure?

On Mon, Dec 26, 2022 at 08:45:53PM +0100, Santiago Vila wrote: > El 26/12/22 a las 20:29, Theodore Ts'o escribió: > > I: The directory does not exist inside the chroot. > > This is really a problem with schroot. I guess that this will not work either: > > schroot -c the-chroot-name > > This

Re: Help trying to debug an sbuild failure?

El 26/12/22 a las 20:29, Theodore Ts'o escribió: I: The directory does not exist inside the chroot. This is really a problem with schroot. I guess that this will not work either: schroot -c the-chroot-name This usually works when you are in your $HOME because this file:

Help trying to debug an sbuild failure?

Hi, I'm trying to figure out an sbuild failure on my laptop. The sbuild environment from replicated from my desktop where things work perfectly well. But in my laptop, things are failing at the "Setup apt archive" step with E: Failed to change to directory ‘/<>’: Permission denied And I'm

Accepted node-help-me 4.2.0-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 16 Dec 2022 15:18:14 +0800 Source: node-help-me Architecture: source Version: 4.2.0-1 Distribution: unstable Urgency: low Maintainer: Debian Javascript Maintainers Changed-By: Ying-Chun Liu (PaulLiu) Changes: node-help-me

Accepted doublecmd-help 1.0.8-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 10 Oct 2022 21:44:22 + Source: doublecmd-help Built-For-Profiles: noudeb Architecture: source Version: 1.0.8-1 Distribution: unstable Urgency: medium Maintainer: Pascal Packaging Team Changed-By: Graham Inggs Changes

Re: Help needed for watch file after bitbucket changed download page

Hello Andreas, On 2022-09-29 14:54 4, Andreas Tille wrote: I confirm this works. However, uscan does not do the usual link to orig.tar.gz. Any idea why this is the case? I have found this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896705 But did you have signing key from Rob

Bitbucket changed download page - possibly lots of watch files affected (Was: Help needed for watch file after bitbucket changed download page)

Hi Nilesh, Am Thu, Sep 29, 2022 at 03:43:58PM +0530 schrieb Nilesh Patra: > I don't know how to go about it, but I suspect -devel might be a better list > for this since this is a general question and many package maintainers could > be using bitbucket sources. While I considered

Accepted node-help-me 4.1.0-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 18 Sep 2022 15:59:42 +0800 Source: node-help-me Architecture: source Version: 4.1.0-1 Distribution: unstable Urgency: low Maintainer: Debian Javascript Maintainers Changed-By: Ying-Chun Liu (PaulLiu) Changes: node-help-me

help with chromium

Hi, Would you like to see chromium in the bookworm release? The release managers really want to see a team maintaining it. I filed a RFH bug, there's plenty to do: https://bugs.debian.org/1016047 Please consider joining! No need to spam the list, you can just email me privately if you're

Re: Help needed with a dh_shlibs failure on non amd64 platforms

On Mon, 04 Jul 2022 at 09:29:54 +0200, Martin Quinson wrote: > All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the > package. They are added to the debian/libns3.36/DEBIAN/shlibs Independent of the dh_shlibdeps failure that was already diagnosed, if these libraries are

Re: Help needed with a dh_shlibs failure on non amd64 platforms

Hello, Martin Quinson, le lun. 04 juil. 2022 09:29:54 +0200, a ecrit: > dpkg-shlibdeps -Tdebian/libns3.36.substvars > debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1 x86_64-linux-gnu is only valid for amd64. In ./debian/rules: -DCMAKE_INSTALL_RUNSTATEDIR=/run

Help needed with a dh_shlibs failure on non amd64 platforms

Hello all, I come to you because I'm puzzled with a bug I have in one of my package, and I'm seeking for help. Please CC me when answering as I'm not on this list. The package is ns3, a scientific simulator of computer networks. This package is huge, I seem to be the only active maintainer

Accepted click-help-colors 0.9.1-3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 27 Jun 2022 21:40:49 +0200 Source: click-help-colors Architecture: source Version: 0.9.1-3 Distribution: sid Urgency: medium Maintainer: Sakirnth Nagarasa Changed-By: Sakirnth Nagarasa Changes: click-help-colors (0.9.1-3

Accepted node-help-me 4.0.1-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 25 Jun 2022 09:58:53 +0800 Source: node-help-me Architecture: source Version: 4.0.1-1 Distribution: unstable Urgency: low Maintainer: Debian Javascript Maintainers Changed-By: Ying-Chun Liu (PaulLiu) Changes: node-help-me

Accepted epic4-help 1:2.0+20050315-3.1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 20 May 2022 23:00:28 +0200 Source: epic4-help Architecture: source Version: 1:2.0+20050315-3.1 Distribution: unstable Urgency: medium Maintainer: Kurt Roeckx Changed-By: Holger Levsen Changes: epic4-help (1:2.0+20050315-3.1

Help in setting up lxc for autopkgtest - autopkgtest-build-lxc fails

Following Simon's suggestion, I decided to try setting up lxc to use autopkgtest-lxc, mimicking the ci.debian.org setup. I haven't managed to do so yet, and have run into lots of problems. I'd really appreciate some advice on what to try, and them we can record advice somewhere on the Debian

Accepted node-help-me 3.0.0-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 22 Apr 2022 11:43:03 +0200 Source: node-help-me Architecture: source Version: 3.0.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Javascript Maintainers Changed-By: Yadd Closes: 1009508 Changes: node-help-me

Bug#1009331: ITP: node-gitlab-favicon-overlay -- Combine images for a favicon with the help of canvas

/favicon-overlay#read> * License : Expat Programming Lang: JavaScript Description : Combine images for a favicon with the help of canvas . Node.js is an event-based server-side JavaScript engine.

Bug#1007107: ITP: pytz-deprecation-shim -- Shims to help you safely remove pytz

-deprecation-shim * License : Apache 2.0 Programming Lang: Python Description : Shims to help you safely remove pytz pytz has served the Python community well for many years, but it is no longer the best option for providing time zones. pytz has a non-standard interface that is very easy

Re: DD(s) to help DM land some long-overdue package updates?

Le 26 février 2022 16:28:18 GMT+01:00, Reuben Thomas a écrit : >On Fri, 4 Feb 2022 at 14:30, Reuben Thomas wrote: > >> >> Having just now got the new Debian packaging building without error, I >> shall now follow the ITS procedure and see what happens! >> > >I have waited 8 days since posting

Re: DD(s) to help DM land some long-overdue package updates?

On Fri, 4 Feb 2022 at 14:30, Reuben Thomas wrote: > > Having just now got the new Debian packaging building without error, I > shall now follow the ITS procedure and see what happens! > I have waited 8 days since posting debdiffs, and had no response, so I've now filed an ITS bug: #1006481. --

Re: DD(s) to help DM land some long-overdue package updates?

progress: Santiago Vila started work on packaging recode 3.7, one of the packages I mentioned, so I did some work to help with that. That has actually taken most of my time until now. However, I have also found some time to work on the packaging of mmv. I think this is one of the clearest-cut packages i

Accepted click-help-colors 0.9.1-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 25 Jan 2022 21:29:49 +0100 Source: click-help-colors Architecture: source Version: 0.9.1-2 Distribution: sid Urgency: medium Maintainer: Sakirnth Nagarasa Changed-By: Sakirnth Nagarasa Changes: click-help-colors (0.9.1-2

Re: Help needed: C++ compile error with nix 2.5.1

* Thomas Koch , 2022-01-16, 11:23: https://github.com/NixOS/nix/issues/5923 The first bad commit is: https://github.com/nlohmann/json/commit/0e694b4060ed55df (This happens to be also the first bad commit for , so I guess it's the same issue.)

Help needed: C++ compile error with nix 2.5.1

For a C++ programmer who cares about nix in Debian: https://github.com/NixOS/nix/issues/5923 Thank you! Thomas

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, 1 Jan 2022 at 20:55, Wookey wrote: > > Hi Rebuen. I helped you with the last libpaper refurbishment in > 2012-2014. Happy to do that again, although as people have pointed out > complete rewrites are not really NMU material and we should follow the > salvage process. > > Well done for

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue wrote: > > I suggest this path: > > Send bug reports with your debdiff proposals for each package. If 8 days > after you get no reply from the maintainer, file an ITS against the > packages for which you got no reply. > > If at the end of the

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, Jan 01, 2022 at 02:48:49PM -0500, Boyuan Yang wrote: > should be the correct choice. For a specific example, I just spotted > https://bugs.debian.org/961136 the second time (last time back in May 2020); yet the bug was never pinged after it was filed. and so as many bugs it "got lost",

Re: DD(s) to help DM land some long-overdue package updates?

On 2022-01-01 19:06 +, Reuben Thomas wrote: > Here's a summary of the packages I'm trying to update. If any DD can help me > get these uploaded, I'd be most grateful, Hi Rebuen. I helped you with the last libpaper refurbishment in 2012-2014. Happy to do that again, although as peopl

Re: DD(s) to help DM land some long-overdue package updates?

e-salvaging >> should be the correct choice. For a specific example, I just spotted >> https://bugs.debian.org/961136 the second time (last time back in May 2020); >> let me know if you would like to initiate a package salvaging process on this >> certain package and I can

Re: DD(s) to help DM land some long-overdue package updates?

tted > https://bugs.debian.org/961136 the second time (last time back in May 2020); > let me know if you would like to initiate a package salvaging process on this > certain package and I can help. Thanks very much for the pointer! I was not aware of this process. It might be approp

Re: DD(s) to help DM land some long-overdue package updates?

在 2022-01-02星期日的 00:33 +0500，Andrey Rahmatullin写道： > On Sat, Jan 01, 2022 at 07:06:09PM +, Reuben Thomas wrote: > > Here's a summary of the packages I'm trying to update. If any DD can help > > me > > get these uploaded, I'd be most grateful > The packages you

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, Jan 01, 2022 at 07:06:09PM +, Reuben Thomas wrote: > Here's a summary of the packages I'm trying to update. If any DD can help me > get these uploaded, I'd be most grateful The packages you listed are not orphaned and the changes you listed don't warrant NMUs so your only o

DD(s) to help DM land some long-overdue package updates?

of one of the packages I mention, and you're reading this, please don't take this appeal as any sort of criticism! If you've not had a recent communication for me, it may just be a spam trap problem—do get in touch if you can! Here's a summary of the packages I'm trying to update. If any DD can help

Bug#1000809: ITP: qstylizer -- Python package to help with the construction of PyQt/PySide stylesheets

: Python Description : Python package to help with the construction of PyQt/PySide stylesheets This package allows for both the construction of new stylesheets and the easy modification of existing ones. This package is a dependency of the new version of Spyder (python3-spyder

Re: Help porting Ceph 16.2.6 to mips6el, mipsel and armel

Hi Simon, Thanks a lot for your help. On 11/20/21 12:55 PM, Simon McVittie wrote: > [...] > You'll notice -latomic appears *before* the various .a and .o files, but > in general, link order matters: each object on the linker command-line is > only used to satisfy the dependencie

Re: Help porting Ceph 16.2.6 to mips6el, mipsel and armel

On Sat, 20 Nov 2021 at 11:31:04 +0100, Thomas Goirand wrote: > Latest Ceph doesn't build on 3 arch: > > https://buildd.debian.org/status/package.php?p=ceph=experimental > > (plus the unofficial ports...) > > What worries me the most is mips6el, where the linker says "undefined > reference to

Re: Help porting Ceph 16.2.6 to mips6el, mipsel and armel

On Sat, Nov 20, 2021 at 11:31:04AM +0100, Thomas Goirand wrote: > What worries me the most is mips6el, where the linker says "undefined > reference to `__atomic_load_16'" (and more like this). I don't > understand because there really is a -latomic parameter to GCC when > linking, so it should be

Help porting Ceph 16.2.6 to mips6el, mipsel and armel

nd because there really is a -latomic parameter to GCC when linking, so it should be working. I'm not sure what happens with the other arch, though it's important that at least the libs can build (so that Qemu can be linked with librbd support). Help from anyone, prior to upload to Unstable to re

Accepted click-help-colors 0.9.1-1 (source all) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 11 Aug 2021 19:42:20 +0200 Source: click-help-colors Binary: python3-click-help-colors Architecture: source all Version: 0.9.1-1 Distribution: sid Urgency: medium Maintainer: Sakirnth Nagarasa Changed-By: Sakirnth Nagarasa

Accepted doublecmd-help 1.0.0-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 31 Oct 2021 08:37:43 + Source: doublecmd-help Built-For-Profiles: noudeb Architecture: source Version: 1.0.0-1 Distribution: unstable Urgency: medium Maintainer: Pascal Packaging Team Changed-By: Graham Inggs Changes

Bug#994856: ITP: harmonpy -- An algorithm to help integrate high-dimensional datasets

: Python Description : An algorithm to help integrate high-dimensional datasets Harmony is an algorithm for integrating multiple high-dimensional datasets. . harmonypy is a port of the harmony R package by Ilya Korsunsky. Harmonypy is a package to help integrate high-dimentional datasets

want help with autopkgtest for your package?

Hi, The Debian CI team would like to encourage and help more maintainers to add autopkgtest to their packages. To that effect, we now have a repository called autopkgtest-help on salsa, where we will take help requests from maintainers working on autopkgtest for their packages: https

Re: Need help with Multi-Arch in systemd

On Thu, Jul 15, 2021 at 08:08:13AM +0200, Helmut Grohne wrote: > I also proposed a solution here, which is avoiding > SystemCallArchitectures=native. Initially, that sounds like a > maintenance nightmare until you notice that it can be solved on a > technical level. We already have

Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

dropped the effort when it became clear the team wasn't interested in such tools. We considered continuing with a tool that would work for individual users reviewing their own work, but there just wasn't enough interest for that either. I'd be happy to help resurrect (the personal-use version

Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

rk, but there just wasn't enough interest for that either. I'd be happy to help resurrect (the personal-use version of) the project/effort if there's any chance I won't be working on it by myself...

Re: Need help with Multi-Arch in systemd

On 16194 March 1977, Simon McVittie wrote: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex, assigning the given section/priority, without

Re: Need help with Multi-Arch in systemd

Hi Michael, On Thu, Jul 15, 2021 at 12:22:59AM +0200, Michael Biebl wrote: > You are right. Thinking more about this, splitting out libsystemd-shared as > a Multi-Arch: same library will not help with > SystemCallArchitectures=native, which is used by the services in > systemd-{conta

Re: Need help with Multi-Arch in systemd

. You are right. Thinking more about this, splitting out libsystemd-shared as a Multi-Arch: same library will not help with SystemCallArchitectures=native, which is used by the services in systemd-{container,journal-remote,...}. So splitting out libsystemd-shared, while in theory a nice solution

Re: Need help with Multi-Arch in systemd

On Wed, 2021-07-14 at 11:59:11 +0100, Simon McVittie wrote: > On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote: > > [a separate libsystemd-shared-249 .deb] would also mean, that on every > > new upstream release, systemd would have to go through NEW > > It seems like we're rejecting a

Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

On 14.07.21 13:47, Michael Biebl wrote: Am 14.07.21 um 12:59 schrieb Simon McVittie: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex,

Re: Need help with Multi-Arch in systemd

On Wed, Jul 14, 2021 at 11:59:11AM +0100, Simon McVittie wrote: > It seems like this would also be good for src:linux, where ABI breaks > are often tied to security fixes that should enter the archive ASAP. As security updates are hand approved, accepting by NEW does not help that much. B

Re: Need help with Multi-Arch in systemd

On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote: > Asking on #debian-systemd, Marco d'Itri suggested, that we move > libsystemd-shared into a separate binary package. This would only help, if > we moved libsystemd-shared into a Multi-Arch location (which means, we'd > h

Re: Need help with Multi-Arch in systemd

* Simon McVittie [2021-07-14 11:59]: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex, assigning the given section/priority, without manual

Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

Am 14.07.21 um 13:47 schrieb Michael Biebl: Am 14.07.21 um 12:59 schrieb Simon McVittie: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex,

automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

Am 14.07.21 um 12:59 schrieb Simon McVittie: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex, assigning the given section/priority, without

Re: Need help with Multi-Arch in systemd

On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote: > [a separate libsystemd-shared-249 .deb] would also mean, that on every > new upstream release, systemd would have to go through NEW It seems like we're rejecting a good technical solution because social/organisational factors block it

Re: Need help with Multi-Arch in systemd

Helmut Grohne wrote: > So you made me thinking, can we somehow implement this with our > current spec? The most important requirements seem to be: > > * libsystemd-shared.so and /sbin/systemd need to reside in the same >binary package. > * It shall be possible to depend on

Re: Need help with Multi-Arch in systemd

Hi Michael, Michael Biebl ezt írta (időpont: 2021. júl. 9., P, 22:42): > > Hi Guillem, > > thanks for your feedback > > Am 09.07.21 um 13:46 schrieb Guillem Jover: > > If the private library has no backwards or forward compatibility (due > > to the SONAME used) the time window where the library

Re: Need help with Multi-Arch in systemd

Hi Michael, I'm not yet fully convinced that we're out of options, but let's for a moment assume we were. On Fri, Jul 09, 2021 at 10:26:43PM +0200, Michael Biebl wrote: > So, unless we get a :arch annotation that can be used for M-A:foreign > packages, maybe the best option is Given Johannes'

Re: Need help with Multi-Arch in systemd

On Fri, Jul 09, 2021 at 10:28:57AM +0200, Helmut Grohne wrote: >... > I also disagree with the need to go through NEW more than once. The new > package could quite simply be named libsystemd-private and lack a > .symbols and .shlibs file. Internal users would always use (= > ${binary:Version})

Re: Need help with Multi-Arch in systemd

> "Helmut" == Helmut Grohne writes: Helmut> Looks like this leaves us between a rock and a hard Helmut> place. None of the options seems particularly attractive to Helmut> me at this point. We seem to be in a brainstorming space here, throwing out half baked ideas because none

Re: Need help with Multi-Arch in systemd

Quoting Helmut Grohne (2021-07-09 14:24:01) > Another possibility (kudos to David Kalnischkies) would be exploiting > something I might call a loophole in the Multi-Arch spec. While we don't > currently use arch-qualified dependencies in the archive, the spec considers > them and dpkg and apt

Re: Need help with Multi-Arch in systemd

) Installed-Size: [-336-] {+1218+} systemd-timesyncd (1 binary) Installed-Size: [-209-] {+595+} I think the increase in size is significant. More importantly, I'd need help maintaining this patch going forward I acknowledge, that option 2 and 3 makes Helmut's work on cross-building harder

Re: Need help with Multi-Arch in systemd

* Michael Biebl [2021-07-09 13:24]: Let me be blunt here: I'm not willing to compromise on robustness here. Well, I have had my say and ultimately, it's your package and your decision, of course. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo

Re: Need help with Multi-Arch in systemd

Hi Michael, in your other mail, you gave a very good reason for keeping the systemd binary and libsystemd-shared.so in the same binary package. That improves my understanding of why you favour option 3. On Fri, Jul 09, 2021 at 11:31:15AM +0200, Michael Biebl wrote: > Am 09.07.21 um 10:28 schrieb

Re: Need help with Multi-Arch in systemd

md + new libsystemd-private > > > is installed. If the installation is aborted at this point, you have > > > an unbootable system. > > Helmut suggested a tightly versioned dependency, so such a state > > would never be consistent. > That tightly versioned dependenc

Re: Need help with Multi-Arch in systemd

Am 09.07.2021 um 13:01 schrieb Timo Röhling: * Michael Biebl [2021-07-09 12:29]: That tightly versioned dependency doesn't help unfortunately. There is still a time window between the new libsystemd-shared and the new systemd being unpacked. There's also a time window between files in /usr

Re: Need help with Multi-Arch in systemd

* Michael Biebl [2021-07-09 12:29]: That tightly versioned dependency doesn't help unfortunately. There is still a time window between the new libsystemd-shared and the new systemd being unpacked. There's also a time window between files in /usr/bin and files in /usr/lib being replaced

Re: Need help with Multi-Arch in systemd

an unbootable system. Helmut suggested a tightly versioned dependency, so such a state would never be consistent. That tightly versioned dependency doesn't help unfortunately. There is still a time window between the new libsystemd-shared and the new systemd being unpacked. Michael

Re: Need help with Multi-Arch in systemd

* Michael Biebl [2021-07-09 11:01]: Splitting out libsystemd-shared (once) will make PID1 very brittle. It can lead to situations where old systemd + new libsystemd-private is installed. If the installation is aborted at this point, you have an unbootable system. Helmut suggested a tightly

Re: Need help with Multi-Arch in systemd

Am 09.07.21 um 10:28 schrieb Helmut Grohne: On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote: Option 2 would be to drop Multi-Arch: foreign from systemd. This would mean, that packages like libpam-systemd/libnss-systemd can no longer be installed for a foreign architecture (even

Re: Need help with Multi-Arch in systemd

Am 09.07.21 um 10:28 schrieb Helmut Grohne: I concur with Marco here and I argue that splitting the library is my preferred solution. I confirm that you'd need to move the library for this to work. For the other points I do not follow. I think it would be ok to move the library using code inside

Re: Need help with Multi-Arch in systemd

stemd-shared into a separate binary package. This would only help, if > we moved libsystemd-shared into a Multi-Arch location (which means, we'd > have to carry a patch against upstream). It would also mean, that on every > new upstream release, systemd would have to go through NEW. &

Need help with Multi-Arch in systemd

into separate binary packages, like systemd-container. Since both systemd is marked as Multi-Arch: foreign, it can happen that we get this architecture mismatch. Asking on #debian-systemd, Marco d'Itri suggested, that we move libsystemd-shared into a separate binary package. This would only help, if we

Re: Help required to determine why some packages are being installed

Hi David, and thanks for your reply! On Thu, May 27, 2021 at 04:28:08PM +0200, David Kalnischkies wrote: > The self-inflicted joy of avoiding a transitional package (see also the > other thread about transitional packages on d-d@ I should comment) and > of too strict dependencies (just because

Re: Help required to determine why some packages are being installed

Hi, On Sun, May 16, 2021 at 10:00:29PM +0300, Dmitry Shachnev wrote: > We determined that the reason for users getting libqt5gui5-gles installed > is the qt5-default package. We removed it in October 2020 because it is no > longer needed. But the latest version of that package that ever existed

Re: Help required to determine why some packages are being installed

Hi again David and all! I want to ask for the help again. We determined that the reason for users getting libqt5gui5-gles installed is the qt5-default package. We removed it in October 2020 because it is no longer needed. But the latest version of that package that ever existed had

Re: Need Help to build debian package from source code

ome of the changes are not reflected. > > I made changes to corefile.c which are correctly reflected > But changes made to histfile.c are not reflected after installation. It's really hard for any of us to help you unless you give details of what you did, and what exactly do you aim to ach

Need Help to build debian package from source code

But changes made to histfile.c are not reflected after installation. I have followed this tutorial to create debian package. https://www.linuxfordevices.com/tutorials/debian/build-packages-from-source Could you help me with it ? Any help is appreciated. PS: I have tried with configure &

Bug#983842: ITP: srcode -- Tool that help developers to manage their codebase in an effective & productive way.

Package: wnpp Severity: wishlist Owner: Aloïs Micard * Package name: srcode Version : 0.7.2-1 Upstream Author : Aloïs Micard * URL : https://github.com/creekorful/srcode * License : GPL-3.0 Programming Lang: Go Description : Tool that help developers

Accepted doublecmd-help 0.9.10-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 19 Feb 2021 06:59:03 + Source: doublecmd-help Architecture: source Version: 0.9.10-1 Distribution: unstable Urgency: medium Maintainer: Pascal Packaging Team Changed-By: Graham Inggs Changes: doublecmd-help (0.9.10-1

Re: Need help with getting a package to build reproducibly on arm*

systemd does not build reproducibly on armhf and >>>>> arm64 (while there is no problem on amd64 and i386). >>>>> >>>>> The problem is, I have no idea what the diffoscope diff [2] means and >>>>> how I can make the package build reproducibly every

Re: Help required to determine why some packages are being installed

o satisfy > 3. not installed, but can (may) be and would satisfy > > [...] That was my understanding as well (and what you wrote below too). > That said, I find it a bit odd that only libqt5gui5-gles conflicts with > libqt5gui5. I doubt it will help apt, but it seems more honest to

Re: Help required to determine why some packages are being installed

I don't think there is a solution to your problem – assuming that is indeed this problem as I am only guessing – as at the very end its a problem of the user accepting a solution they shouldn't, but to know that you need to have specific domain knowledge. The hidden joys of Debian unstable I guess

Re: Help required to determine why some packages are being installed

Quoting Johannes Schauer Marin Rodrigues (2021-01-27 16:53:50) > Quoting Jonas Smedegaard (2021-01-27 16:15:17) > > I suspect that's not really the case - that instead apt tools might > > pick at random. > > no, apt does not pick at random. The apt solver prefers the first > alternative. With

Re: Help required to determine why some packages are being installed

Hi, Quoting Jonas Smedegaard (2021-01-27 16:15:17) > I suspect that's not really the case - that instead apt tools might pick at > random. no, apt does not pick at random. The apt solver prefers the first alternative. > It is my understanding that build daemons _ignore_ secondary entries >

Re: Help required to determine why some packages are being installed

gles > variant instead of the non-gles one by default. This causes bugs like > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976389 > > So far we couldn't reproduce the issue so we are kindly asking for > your help in order to determine what's causing this behavior. In above bug

Help required to determine why some packages are being installed

Hi! tl;dr: we the Qt maintainers need help to find out why some users upgrading from stable / reinstalling packages get libqt5quick5-gles instead of libqt5quick5. Long story: some months ago my team mate Dmitry Shachnev managed to get two flavours of Qt: the normal one with OpenGL support

Re: Need help with getting a package to build reproducibly on arm*

On Sat, 9 Jan 2021 at 00:52, Michael Biebl wrote: > Am 07.01.21 um 22:39 schrieb Michael Hudson-Doyle: > > > I'm hardly an expert in such things but it looks to me as if gcc is > > ordering things differently between the two builds: > > > > >

Re: Need help with getting a package to build reproducibly on arm*

arm64 (while there is no problem on amd64 and i386). >>>> >>>> The problem is, I have no idea what the diffoscope diff [2] means and >>>> how I can make the package build reproducibly everywhere or how I can >>>> further investigate this. >>>

Bug#979587: ITP: ts-jest -- Node.js preprocessor with source maps support to help use TypeScript with Jest

https://github.com/kulshekhar/ts-jest * License : Expat Programming Lang: JavaScript Description : Node.js preprocessor with source maps support to help use TypeScript with Jest Jest is a popular test framework for JavaScript projects. ts-jest extends jest to test projects w

Re: Need help with getting a package to build reproducibly on arm*

Am 07.01.21 um 22:39 schrieb Michael Hudson-Doyle: I'm hardly an expert in such things but it looks to me as if gcc is ordering things differently between the two builds:

Re: Need help with getting a package to build reproducibly on arm*

>>> The problem is, I have no idea what the diffoscope diff [2] means and >>> how I can make the package build reproducibly everywhere or how I can >>> further investigate this. >>> >>> Any help here is greatly appreciated as I think reprodu

Re: Need help with getting a package to build reproducibly on arm*

diff [2] means and >> how I can make the package build reproducibly everywhere or how I can >> further investigate this. >> >> Any help here is greatly appreciated as I think reproducible-builds are >> a great effort and I'd like to support that as much as

Re: Need help with getting a package to build reproducibly on arm*

ake the package build reproducibly everywhere or how I can > further investigate this. > > Any help here is greatly appreciated as I think reproducible-builds are > a great effort and I'd like to support that as much as I can. > > Regards, > Michael > > > [1] > > https://t

Re: Need help with getting a package to build reproducibly on arm*

is, I have no idea what the diffoscope diff [2] means and how I can make the package build reproducibly everywhere or how I can further investigate this. Any help here is greatly appreciated as I think reproducible-builds are a great effort and I'd like to support that as much as I can. Regards

<    1   2   3   4   5   6   7   8   9   10   >