Re: BuildProfileSpec example equivalence question

Hi Timo, Quoting Timo Röhling (2024-10-16 10:00:25) > >> The third example on https://wiki.debian.org/BuildProfileSpec is: > >I now changed the example to one that is actually used in the wild. > >I hope I didn't mess up the wording. Hope this makes things > >clearer. > The final sentence in the

Re: BuildProfileSpec example equivalence question

Hi Josch, * Johannes Schauer Marin Rodrigues [2024-10-16 * 09:21]: The third example on https://wiki.debian.org/BuildProfileSpec is: I now changed the example to one that is actually used in the wild. I hope I didn't mess up the wording. Hope this makes things clearer. The final sentence in

Re: BuildProfileSpec example equivalence question

Hi Feri, Quoting Ferenc Wágner (2024-10-12 19:39:27) > The third example on https://wiki.debian.org/BuildProfileSpec is: > > Build-Depends: foo > > In this case, the source package would build depend on foo if either > both, nocheck and cross are active or if the profile nocheck is

BuildProfileSpec example equivalence question

Hi, The third example on https://wiki.debian.org/BuildProfileSpec is: Build-Depends: foo In this case, the source package would build depend on foo if either both, nocheck and cross are active or if the profile nocheck is active. [...] This is fully consistent with the defini

Re: Question about library package splitting

Hi Guillem, first of all, many thanks for your answer! And sorry for my late reply... On Sat, Sep 07, 2024 at 02:46:13AM +0200, Guillem Jover wrote: > On Fri, 2024-09-06 at 11:32:55 +0200, Ervin Hegedüs wrote: > > I think ideally upstream would be modified so that this decision can > be made s

Re: Question about library package splitting

Hi! On Fri, 2024-09-06 at 11:32:55 +0200, Ervin Hegedüs wrote: > Here comes the problem: libmodsecurity3 has two types of collection stores: > in-memory and LMDB. It's VERY important: you MUST decide the type of > choosed backend in compilation time, later you can't change it in runtime! I think

Question about library package splitting

Hi there, There is a package in Debian: modsecurity. This is a library and provides a -dev and a runtime packages (libmodsecurity-dev, libmodsecurity3t64). ModSecurity is an open source WAF (Web Application Firewall) "engine". You can write rules (in a special language called "SecLang") and contr

Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)

Am Tue, Apr 09, 2024 at 01:03:10PM + schrieb Stefano Rivera: > > I have also noticed that the young people we manage to recruit are > > usually not interested too much in the boring gruntwork of maintaining > > important core packages (like adduser and sudo) but instead want to do > > "new" thi

Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)

Hi Marc (2024.04.08_16:48:13_+) > I have also noticed that the young people we manage to recruit are > usually not interested too much in the boring gruntwork of maintaining > important core packages (like adduser and sudo) but instead want to do > "new" things. But, otoh, what would Debian be

Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)

[I'm skipping most of this email because I haven't generally been keeping up with the thread, but thought it might be worth pointing out one thing.] On Mon, Apr 08, 2024 at 06:48:13PM +0200, Marc Haber wrote: > On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote: > > Before uploading I u

Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)

On Monday, April 8, 2024 12:48:13 PM EDT Marc Haber wrote: > > > "we replace exim with postfix as the default MTA", > > > > A, this question always makes me wonder: If our default MTA is exim > > why do I have such a hard time to find documents abou

About Package Maintenance (was: Question to all candidates: What are your technical goals)

This is the continuation of a thread from debian-vote, that originated from a question about technical goals to the DPL candidates (https://lists.debian.org/debian-vote/2024/04/msg4.html). I will try to quote generously to deliver context. On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas

Re: Question regarding uscan check on UDD

On Tue, Jan 02, 2024 at 10:22:29PM -0800, Xiyue Deng wrote: > I noticed a discrepancy of the uscan @ANY_VERSION@ substitute string on > UDD and locally on my bookworm system. That's because UDD is running on bullseye, not on bookworm, with bullseye-backports' version of devscripts (which really re

Re: Question regarding uscan check on UDD

Xiyue Deng writes: > Hi, > > I noticed a discrepancy of the uscan @ANY_VERSION@ substitute string on > UDD and locally on my bookworm system. For example, for magit-popup, > UDD reports error[1] while testing locally it worked for me. On further > inspection, it turns out that the @ANY_VERSION@

Question regarding uscan check on UDD

Hi, I noticed a discrepancy of the uscan @ANY_VERSION@ substitute string on UDD and locally on my bookworm system. For example, for magit-popup, UDD reports error[1] while testing locally it worked for me. On further inspection, it turns out that the @ANY_VERSION@ expands to a different regexp:

Re: a naive question about EOL encoding in Debian

On Sat, 18 Mar 2023 at 20:45:37 +0100, Patrice Duroux wrote: > I am facing ^M (\r) character in the .build output file using sbuild > on my system (Sid). > For instance: > > $ file timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build > timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build: ASCII text,

Re: a naive question about EOL encoding in Debian

On Sat, Mar 18, 2023 at 08:45:37PM +0100, Patrice Duroux wrote: > Hi, > > I am facing ^M (\r) character in the .build output file using sbuild > on my system (Sid). > For instance: > > $ file timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build > timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build:

a naive question about EOL encoding in Debian

Hi, I am facing ^M (\r) character in the .build output file using sbuild on my system (Sid). For instance: $ file timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build: ASCII text, with very long lines (307), with CRLF, CR, LF line terminators It s

Demands Question Demandon

Chers amis, dear friends, kara amikoj, exist package for anarkist on Debian, il existe un paquet anarchiste pour Debian, ekzitas pakon pri anarkisno ĉe Debian. Is-it possible to create a package for freemasonry(history,time,calendar...)? Est-il possible de créer un paquet sur la franc-maçonnerie

Re: Question about source tarballs for packaging

On Sun, 2021-10-10 at 21:40 +, Joshua Peisach wrote: > I'm packaging the V programming language for Debian. However, V is  bit > weird at the moment. It's not really ready for stable production/use. > so for a while it will live in experimental. Currently the way building > it works is that th

Re: Question about source tarballs for packaging

Hi Joshua, Quoting Joshua Peisach (2021-10-10 23:40:54) > we will have to build on weekly tags rather than the current '0.2.4' > tag. Here is the issue. uscan and gbp aren't happy with the tag > because by all means, it isn't a number. One option is to track git commits organized by date, using

Re: Question about source tarballs for packaging

On Sun, Oct 10, 2021 at 09:40:54PM +, Joshua Peisach wrote: > This doesn't really matter; the above means that we will have to build > on weekly tags rather than the current '0.2.4' tag. Here is the issue. > uscan and gbp aren't happy with the tag because by all means, it isn't a > number. Not

Question about source tarballs for packaging

Hello everyone, I'm packaging the V programming language for Debian. However, V is bit weird at the moment. It's not really ready for stable production/use. so for a while it will live in experimental. Currently the way building it works is that there is a repo that is the compiler translated

Re: Question Re: Advertising in Packages

> "Paul" == Paul Wise writes: Paul> On Mon, Aug 16, 2021 at 2:22 AM Antonio Russo wrote: >> "Can one advertise non-free services in a Debian package? Is >> doing so a violation of some Debian policy? Paul> There is no specific rule against this, but I feel that Paul> cul

Re: Question Re: Advertising in Packages

feel that culturally > Debian generally doesn't like this. > > > The details are filed against firefox[-esr], #992208 [1] (which was > > summarily closed without very much discussion). The non-free > > services in question are Amazon, YouTube, Facebook, Reddit, and

Re: Question Re: Advertising in Packages

On Sun, 2021-08-15 at 20:16 -0600, Antonio Russo wrote: > I have a question that I originally posed in debian-vote, but was > directed here instead: > >    "Can one advertise non-free services in a Debian package? Yes. I guess this would be up to the maintainer to decide what i

Re: Question Re: Advertising in Packages

On Mon, 16 Aug 2021 08:04:53 +, "Andrew M.A. Cater" wrote: >On Sun, Aug 15, 2021 at 09:14:18PM -0600, Antonio Russo wrote: >> I feel like if we are forced to rebrand Debian's browser to ensure user >> freedoms, then we simply must do so. I'd rather support Firefox/Mozilla, >> but I don't thin

Re: Question Re: Advertising in Packages

g so a violation of some Debian policy? > > > > There is no specific rule against this, but I feel that culturally > > Debian generally doesn't like this. > > +1 > > > > >> The details are filed against firefox[-esr], #992208 [1] (which was > >> summ

Re: Question Re: Advertising in Packages

feel that culturally > Debian generally doesn't like this. +1 > >> The details are filed against firefox[-esr], #992208 [1] (which was >> summarily closed without very much discussion). The non-free services in >> question are Amazon, YouTube, Facebook, Reddit, and Twitt

Re: Question Re: Advertising in Packages

e details are filed against firefox[-esr], #992208 [1] (which was > summarily closed without very much discussion). The non-free services in > question are Amazon, YouTube, Facebook, Reddit, and Twitter. I'd like to see those removed too, but ... I expect removing these might violate

Re: Question Re: Advertising in Packages

Hi, On 2021-08-15 10:16 p.m., Antonio Russo wrote: > Hello, > > I have a question that I originally posed in debian-vote, but was directed > here instead: > >"Can one advertise non-free services in a Debian package? > Is doing so a violation of some Debian poli

Question Re: Advertising in Packages

Hello, I have a question that I originally posed in debian-vote, but was directed here instead: "Can one advertise non-free services in a Debian package? Is doing so a violation of some Debian policy? Again, if this is the wrong venue, I'm sorry. The details are filed again

Re: Kernel building question (Is -j8 safe and correct?)

On Sun, 2021-06-13 at 15:07 +0200, Philipp Hahn wrote: [...] > > 3. If both of the above are true, why isn't something like that suggested > > on [1]? > > Debian does not know your specifics and thus does not use parallel build > by default. > Debian *does* use parallel builds by default. But

Re: Kernel building question (Is -j8 safe and correct?)

On Fri, 2021-06-11 at 19:34 -0600, Antonio Russo wrote: > Hello, > > I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's > irrelevant). > I'm following [1], and the critical command > > $ fakeroot make -f debian/rules.gen binary-arch_i386_none_real > > does not suggest

Re: Kernel building question (Is -j8 safe and correct?)

Hello Anionio, Am 12.06.21 um 03:34 schrieb Antonio Russo: I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's irrelevant). I'm following [1], and the critical command $ fakeroot make -f debian/rules.gen binary-arch_i386_none_real does not suggest using -j8 (or -jnumb

Kernel building question (Is -j8 safe and correct?)

Hello, I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's irrelevant). I'm following [1], and the critical command $ fakeroot make -f debian/rules.gen binary-arch_i386_none_real does not suggest using -j8 (or -jnumber_of_cores). 1. Is it safe to add -j8 ? 2. Will this

Re: Question about generated dependencies

On Fri, Feb 12, 2021 at 12:24:02AM +0200, Peter Pentchev wrote: > On Thu, Feb 11, 2021 at 10:50:35PM +0200, Boian Bonev wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Hi All, > > > > While playing with glibc 2.33 (I made a couple of changes on the 2.31-9 > > and built it l

Re: Question about generated dependencies

On Thu, Feb 11, 2021 at 10:50:35PM +0200, Boian Bonev wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi All, > > While playing with glibc 2.33 (I made a couple of changes on the 2.31-9 > and built it locally), I stumbled upon the following generated > dependency in libnih1: > > $

Question about generated dependencies

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi All, While playing with glibc 2.33 (I made a couple of changes on the 2.31-9 and built it locally), I stumbled upon the following generated dependency in libnih1: $ apt info libnih1 Package: libnih1 Version: 1.0.3-11 Priority: optional Section:

Re: autopkgtest question: pass on local but fail on salsa-ci

Hi Inaki, On Fri, 29 May 2020 14:10:10 +0200 Inaki Malerba wrote: > This issue should be workarounded on the pipeline since [0]. Try > retrying the job, it should work. Cool, that's really nice, thanks! -- Hideki Yamane

Re: autopkgtest question: pass on local but fail on salsa-ci

Hi Hideki, El 28/5/20 a las 16:17, Hideki Yamane escribió: > > Thanks for your reply :) > > On Tue, 26 May 2020 16:55:17 +0200 > Joël Krähemann wrote: >> Just looked at it, thought I am not using gitlab for CI. Might be you >> have to permit output to stderr. > > > On Tue, 26 May 2020 22:10:

Re: autopkgtest question: pass on local but fail on salsa-ci

Thanks for your reply :) On Tue, 26 May 2020 16:55:17 +0200 Joël Krähemann wrote: > Just looked at it, thought I am not using gitlab for CI. Might be you > have to permit output to stderr. On Tue, 26 May 2020 22:10:17 +0200 Johannes Schauer wrote: > https://bugs.debian.org/cgi-bin/bugreport

Re: autopkgtest question: pass on local but fail on salsa-ci

Quoting Hideki Yamane (2020-05-26 15:48:47) > Hi, > > autopkgtest on salsa-ci question, I've built mecab package and test > it with autopkgtest on local machine. Then pushed to salsa, however, > it failed on salsa-ci pipeline at autopkgtest. > https://salsa.debian.org/n

Re: autopkgtest question: pass on local but fail on salsa-ci

/master/doc/README.package-tests.rst regards, Joël On Tue, May 26, 2020 at 4:20 PM Hideki Yamane wrote: > > Hi, > > autopkgtest on salsa-ci question, I've built mecab package and test > it with autopkgtest on local machine. Then pushed to salsa, however, > it failed

autopkgtest question: pass on local but fail on salsa-ci

Hi, autopkgtest on salsa-ci question, I've built mecab package and test it with autopkgtest on local machine. Then pushed to salsa, however, it failed on salsa-ci pipeline at autopkgtest. https://salsa.debian.org/nlp-ja-team/mecab/-/jobs > autopkgtest [12:39:33]: test command1: perl

Re: Question for alioth-lists.debian.net status

Shengjing Zhu, > Instead of the lintian issue, the real issue which is underneath > is, what's the status of alioth-lists.debian.net? > > Is it still a short term service[1], or the admin plans to make > it long term? The difference is whether people should look for a > new home. It has been 2 ye

Re: Question for alioth-lists.debian.net status

On Sat, Apr 25, 2020 at 00:51:34 +0800, Shengjing Zhu wrote: > And another question for DSA is, whether the lists.alioth.debian.org > address is expected to work, as long as the alioth-lists.debian.net > exists? > I don't see a reason to break it. Cheers, Julien

Question for alioth-lists.debian.net status

her people should look for a new home. It has been 2 years but there are still many active users on it. And some teams haven't planned to migrate. And another question for DSA is, whether the lists.alioth.debian.org address is expected to work, as long as the alioth-lists.debian.net exists? Tha

Re: Another question for a license

On 08/12/2019 13:27, JungHwan Kang wrote: Hi, forks. I appreciate your previous answer to my question about the open-source licenses. May I ask another question? 1. Is it no matter who releases his Linux distribution under his license for commercially?     the distribution is made of

Another question for a license

Hi, forks. I appreciate your previous answer to my question about the open-source licenses. May I ask another question? 1. Is it no matter who releases his Linux distribution under his license for commercially? the distribution is made of modified and unmodified packages from upstream. 2

Re: [confirmation] Summary: Git Packaging Round 2 [plus weak vs strong team ownership question/proposal]

I think we have enough confirmations to move forward. There are a couple. of last call comments/question that need answers, and then as facilitator, I'll write up a d-d-a post. I'd like to see a round 3 focusing on branch format and stuff. Before proposing a timeline for that, I reco

Re: [confirmation] Summary: Git Packaging Round 2 [plus weak vs strong team ownership question/proposal]

Hi, I confirm the summary seems fair and reasonable with one question/proposal (see below in line). Sam Hartman writes: > * Exploring what current social conventions are around pushing to other > people's repositories in the debian group on salsa and documenting > them. This

Re: Question about embedded Lua

Hello, On 7/25/19 10:27 AM, Kyle Edwards wrote: > 2. Pick a single version of Lua and stick with it forever, missing out > on the benefits of newer versions but retaining backwards compatibility This is the strategy that we've taken for php-luasandbox (uses lua 5.1), used by MediaWiki. The advice

Re: Question about embedded Lua

On Thu, 2019-07-25 at 09:45 -0700, Russ Allbery wrote: > Tobias Frost writes: > > > > > I think there is another option, as embedding lua is a bad idea for > > the > > reason you have already quoted: There are currently two (three with > > experimental) lua versions available in Debian, so you s

Re: Question about embedded Lua

Tobias Frost writes: > I think there is another option, as embedding lua is a bad idea for the > reason you have already quoted: There are currently two (three with > experimental) lua versions available in Debian, so you should run one of > those. This is especially true if the to-embedded-libra

Re: Question about embedded Lua

Hi Kyle, On Thu, Jul 25, 2019 at 10:27:42AM -0400, Kyle Edwards wrote: > Hi all, > > As per Debian policy, programs and libraries are generally not allowed > to embed their own copies of libraries that are present in another > package, in order to avoid duplication of code and to enable security

Question about embedded Lua

Hi all, As per Debian policy, programs and libraries are generally not allowed to embed their own copies of libraries that are present in another package, in order to avoid duplication of code and to enable security updates by updating shared libraries. In general, this is a good rule, but I'm won

Re: buster backports question/status

s do not create the structures apt is checking later on if a given target-release is sensible – that is a feature since 0.8.15.3 (2011) btw → #407511. I think we will end up creating the structures again for other reasons so that error will disappear for this edgecase – but I have to second the que

Re: buster backports question/status

On Wed, Jul 10, 2019 at 11:29:01 +0200, olivier sallou wrote: > Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin a > écrit : > > > On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote: > > > So, am I doing something wrong? > > You tried to install a package (what package? they don't e

Re: buster backports question/status

Le mer. 10 juil. 2019 à 11:35, Andrey Rahmatullin a écrit : > On Wed, Jul 10, 2019 at 11:29:01AM +0200, olivier sallou wrote: > > I tried a package that is not in backports, it was just for test (for an > > automation tool I use) > > It should fail with a *package not found* , but should not fail

Re: buster backports question/status

On Wed, Jul 10, 2019 at 11:29:01AM +0200, olivier sallou wrote: > I tried a package that is not in backports, it was just for test (for an > automation tool I use) > It should fail with a *package not found* , but should not fail about > buster-backports being non available. I don't think the faili

Re: buster backports question/status

On 2019/07/10 11:29, olivier sallou wrote: > > > Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin > a écrit : > > On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote: > > So, am I doing something wrong? > You tried to install a package (what pac

Re: buster backports question/status

Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin a écrit : > On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote: > > So, am I doing something wrong? > You tried to install a package (what package? they don't exist) from a > repo that doesn't exist. > I tried a package that is not in

Re: buster backports question/status

On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote: > So, am I doing something wrong? You tried to install a package (what package? they don't exist) from a repo that doesn't exist. -- WBR, wRAR signature.asc Description: PGP signature

buster backports question/status

Hi, it may be a silly question, but doing some tests on a Debian buster, I got errors trying to install a package from buster-backports. I added to sources.list.d info to set buster-backports but i get this error: E: The value 'buster-backports' is invalid for APT::Default-Release

Re: Question about Debian build infrastructure

Am Mittwoch, den 12.06.2019, 14:02 +0800 schrieb Paul Wise: > On Wed, Jun 12, 2019 at 1:21 AM Benjamin Drung wrote: > > > * I had to patch reprepro to support multiple versions: > > https://github.com/profitbricks/reprepro > > I think it would be very helpful to a lot of derivative distros and >

Re: Question about Debian build infrastructure

On Wed, 12 Jun 2019, Vincent Bernat wrote: > It's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623 > > Maintainer doesn't seem to be interested or have no time to consider the > patch since many years. Another sticking point with reprepro is the lack of Acquire-by-hash support: https://bu

Re: Question about Debian build infrastructure

❦ 12 juin 2019 14:02 +08, Paul Wise : >> * I had to patch reprepro to support multiple versions: >> https://github.com/profitbricks/reprepro > > I think it would be very helpful to a lot of derivative distros and > small or private apt repositories if this patch could be merged > upstream and mad

Re: Question about Debian build infrastructure

On Wed, Jun 12, 2019 at 1:21 AM Benjamin Drung wrote: > * I had to patch reprepro to support multiple versions: > https://github.com/profitbricks/reprepro I think it would be very helpful to a lot of derivative distros and small or private apt repositories if this patch could be merged upstream a

Re: Question about Debian build infrastructure

Hi, Am Donnerstag, den 06.06.2019, 14:32 -0400 schrieb Kyle Edwards: > Hello all, > > I have been preparing Ubuntu releases for CMake on our own APT > repository for several months now. We did this by preparing our own > repository infrastructure - we have a machine that builds packages, > and >

Re: Question about Debian build infrastructure

On 2019-06-10 13:09:52 -0400 (-0400), Kyle Edwards wrote: > On Mon, 2019-06-10 at 16:56 +, Jeremy Stanley wrote: [...] > > 6. To allow for easier manual verification of key transitions, > > always sign new keys with their predecessors when creating them. > > We haven't signed the new key at th

Re: Question about Debian build infrastructure

On Mon, 2019-06-10 at 16:56 +, Jeremy Stanley wrote: > 2. Don't place all your trust key revocation, instead plan a > rotation schedule so that even if a key falls into the wrong hands > it's more likely users will smell something fishy when they see it > used to sign new artifacts after expira

Re: Question about Debian build infrastructure

On 2019-06-10 11:18:35 -0400 (-0400), Kyle Edwards wrote: [...] > If you're using GPG on the published repository, how does your > repository server handle its signing GPG key? Does someone have to type > in a password every time it wants to publish a package, or is it > unattended, with either an

Re: Question about Debian build infrastructure

On Sat, 2019-06-08 at 02:25 +0200, Matthias Klumpp wrote: > Am Do., 6. Juni 2019 um 20:33 Uhr schrieb Kyle Edwards > : > > > > > > Hello all, > > > > I have been preparing Ubuntu releases for CMake on our own APT > > repository for several months now. We did this by preparing our own > > reposit

Re: Question about Debian build infrastructure

On Sat, 08 Jun 2019 at 02:25:44 +0200, Matthias Klumpp wrote: > Am Do., 6. Juni 2019 um 20:33 Uhr schrieb Kyle Edwards > : > > 2. According to https://wiki.debian.org/BuilddSetup, there seems to be > > a distinction between the build broker (wanna-build) and the build > > workers (buildd). Do eithe

Re: Question about Debian build infrastructure

Am Do., 6. Juni 2019 um 20:33 Uhr schrieb Kyle Edwards : > > Hello all, > > I have been preparing Ubuntu releases for CMake on our own APT > repository for several months now. We did this by preparing our own > repository infrastructure - we have a machine that builds packages, and > a machine that

Question about Debian build infrastructure

Hello all, I have been preparing Ubuntu releases for CMake on our own APT repository for several months now. We did this by preparing our own repository infrastructure - we have a machine that builds packages, and a machine that hosts an Aptly instance and pushes the repository to our web server.

Re: Question regarding patching in 4.9 kernel

f this patch is supported on Linux 4.9 or > this patch is supported only from 4.11? This is a wrong place to ask though, as this question is not related to Debian. -- WBR, wRAR signature.asc Description: PGP signature

Re: Question regarding patching in 4.9 kernel

Hi Ben, I am trying to manually back port to Linux 4.9 since in the link I don’t see a patch provided for 4.9 version. The last version that has this patch is 4.11, wanted to know if back port of this patch is supported on Linux 4.9 or this patch is supported only from 4.11? Sent from my iPho

Re: Question regarding patching in 4.9 kernel

[Note Reply-to: debian-kernel.] On Wed, 2018-09-26 at 18:00 +, Harish Venkatraman wrote: > Hi, > > I want the following patch to be back ported to 4.9 kernel. Can you > please let me know if it can be back ported to 4.9 kernel? > > https://github.com/torvalds/linux/commit/63a6fff353d01da5a22

Question regarding patching in 4.9 kernel

Hi, I want the following patch to be back ported to 4.9 kernel. Can you please let me know if it can be back ported to 4.9 kernel? https://github.com/torvalds/linux/commit/63a6fff353d01da5a22b72670c434bf12fa0e3b8 Thanks

Question about Configuration Management covered at kali.training

Hi there, My new book Configuration Management: Standard Requirements is out, get it here: https://www.dropbox.com/s/86hqr1454ovgdqw/CM_Configuration_Management.pdf?dl=0 My goal is to get in front of anyone who will benefit from it. - perhaps you will be able to help more people

Question about dpkg-maintscript-helper dir_to_symlink, prior-version, and backports

Hi, I have a question. Let's say I have a package performing a dir_to_symlink conversion from version 2.0, so I specify "prior-version" as 2.0~. Now let's say that I backport version 3 to Wheezy, whose version of dpkg-maintscript-helper doesn't support dir_to_symlink

Re: question about build profile nocheck

Hi, Wookey and Chris, Many thanks for the detailed answer and the links! على الأربعاء 1 تشرين الثاني 2017 ‫23:19، كتب Wookey: > On 2017-11-01 21:46 -0400, Afif Elghraoui wrote: [...] >> Am I mistaken? > > Yes. Somewhat discussed in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568897 >

Re: question about build profile nocheck

Hi Afif, Wookey already replied with an excellent answer, but surely: > ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) > override_dh_auto_test: > commands... > commands... > else > override_dh_auto_test: > endif … is better written as: override_dh_auto_test: ifeq (,$(find

Re: question about build profile nocheck

On 2017-11-01 21:46 -0400, Afif Elghraoui wrote: > Hello, > > The BuildProfileSpec on the wiki [1] defines the `nocheck` profile as: > > > > No test suite should be run, and build dependencies used only for that > purpose should be ignored. Builds that set this profile must also add > `nocheck`

question about build profile nocheck

Hello, The BuildProfileSpec on the wiki [1] defines the `nocheck` profile as: > No test suite should be run, and build dependencies used only for that purpose should be ignored. Builds that set this profile must also add `nocheck` to `DEB_BUILD_OPTIONS` ``` I understand this as saying that the

Re: Question about dpkg Re: X facts about Debian - some fact checking and looking for ideas.

at bottom :- On 30/08/2017, Colin Watson wrote: > On Tue, Aug 29, 2017 at 11:26:55PM +0530, shirish शिरीष wrote: >> I was under the impression that due to rpm brokeness Debian and >> thereafter dpkg came into being. > > This is entirely wrong. The first entry in dpkg's changelog was in > 1994, a

Re: Question about dpkg Re: X facts about Debian - some fact checking and looking for ideas.

On Tue, Aug 29, 2017 at 11:26:55PM +0530, shirish शिरीष wrote: > I was under the impression that due to rpm brokeness Debian and > thereafter dpkg came into being. This is entirely wrong. The first entry in dpkg's changelog was in 1994, and rpm's first release was in 1997. Please spend at least

Re: Question about dpkg Re: X facts about Debian - some fact checking and looking for ideas.

On 2017-08-29 23:26:55 +0530 (+0530), shirish शिरीष wrote: [...] > From the wikipedia page it seems the motivation came from SLS - a > derivative of Slackware. [...] Minor correction for you: Slackware was borne out of SLS and not the other way around: https://en.wikipedia.org/wiki/Softlandin

Question about dpkg Re: X facts about Debian - some fact checking and looking for ideas.

Dear all, Please CC me when answering or putting something on the thread. When I started using ubuntu and then later Debian one of the first tools I fell in love with was dpkg. Although nowadays we have multiple tools like apt, aptitude, one of the biggest features of dpkg (which is replicated

Re: Re: Question about offerin packages

> How is it better than fbless and fbreader, already in the archive? My reader has the full support of the 2.1 version of the specification, including the tables, links and other. But without styles. And unlike fbreader it written using GTK. I'll give you link to github https://github.com/Cact

Re: Question about offerin packages

On Sun, Dec 25, 2016 at 06:09:42PM +0300, Mihail Azarov wrote: > Hello. I wrote a book-reader for FB2 > format(https://en.wikipedia.org/wiki/FictionBook). How is it better than fbless and fbreader, already in the archive? > Tell me, how can I offer my package in the debian official repository? If

Question about offerin packages

Hello. I wrote a book-reader for FB2 format(https://en.wikipedia.org/wiki/FictionBook). Tell me, how can I offer my package in the debian official repository?

Re: Package name conflict question

My solution is patch the upstream with "sys.path.insert" function. I wonder that is there a more elegant solution to achieve this goal but without upstream patch ? -- Sun-Ze Lin (林上智) 2016-10-18 19:51 GMT+08:00 Ian Jackson : > Lars Wirzenius writes ("Re: Package name

Re: Package name conflict question

Lars Wirzenius writes ("Re: Package name conflict question"): > I don't have a solution for this. The ideal solution would be for one > or both upstream developers to rename their library. However, that's > only ideal in the long run, since it requires every program th

Re: Package name conflict question

On 2016-10-18 9:52, SZ Lin wrote: I think this situation meets the condition. The case of two programs having the same functionality but different implementations is handled via "alternatives" or the "Conflicts" mechanism. These two programs having the same functionality - implementation of R

Re: Package name conflict question

Hi Ansgar, Thanks for your reply. I think this situation meets the condition. The case of two programs having the same functionality but different > implementations is handled via "alternatives" or the "Conflicts" mechanism. These two programs having the same functionality - implementation of

Re: Package name conflict question

"SZ Lin (林上智)" writes: > Although these packages are not API-compatible, they are using the > same installation path and file name; therefore, I think "Conflict:" > section is needed. Note that Policy explicitly forbids using "Conflicts" in this case, see the first paragraph in [1]. [1]

Re: Package name conflict question

On Tue, Oct 18, 2016 at 03:36:56PM +0800, SZ Lin (林上智) wrote: > Although these packages are not API-compatible, they are using the > same installation path and file name; therefore, I think "Conflict:" > section is needed. The problem with this is that this prevents our users from having both of t

  1   2   3   4   5   6   7   8   9   10   >