Re: How to use multiple upstream tarballs in Debian source packages: quid GIT ?
Hi, On Thu, Nov 13, 2014 at 6:48 PM, Jerome BENOIT wrote: > Hello Forum, > > in order to add some missing sample material, I add a second source to the > upstream source tarball, > then I followed the multiple upstream tarballs in Debian source packages > approach [1]. > This approach is currently used for spamassassin [2]. > > What is the GIT part of this approach ? AFAIK, there is none; there's an open bug filed against git-buildpackage for multi tarball support (#561071) which has not seen progress in a fairly long time, and I don't think any of the other git helpers support multiple tarballs. If you want a workaround that lets you work with unmodified tarballs, I suggest one of two options: - keep only debian/* in git and ignore everything else (which sidesteps the issue) - consider wrapping upstream's tarballs in a single orig tarball (e.g. freetype [1]) Regards, Vincent [1] http://sources.debian.net/src/freetype/2.5.2-2/ (or apt-get source freetype) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczd_taxfza7xhotuncfyln5ei-rjzlazdpdxk07u9otda3...@mail.gmail.com
How to use multiple upstream tarballs in Debian source packages: quid GIT ?
Hello Forum, in order to add some missing sample material, I add a second source to the upstream source tarball, then I followed the multiple upstream tarballs in Debian source packages approach [1]. This approach is currently used for spamassassin [2]. What is the GIT part of this approach ? Thanks in advance, Jerome [1] http://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/ [2] https://packages.debian.org/source/sid/spamassassin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54656d7d.5050...@rezozer.net
Re: Making "entry-point" nee "gift" a real BTS tag
To avoid devolving in a naming the bike-shed discussion, anyone who has a strong opinion, please manually vote in https://debian.titanpad.com/24 and I'll tabulate them 24 hours from now. If you want a different option than the two I've listed, please add it at the top with a new letter. [Hopefully this will work; I reserve the right to veto if silliness occurs.] -- Don Armstrong http://www.donarmstrong.com If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114013354.gf4...@rzlab.ucr.edu
Bug#769487: RFS: docbook-to-man/1:2.0.0-33 [ITA, upload to experimental]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "docbook-to-man" * Package name: docbook-to-man Version : 1:2.0.0-33 Upstream Author : Fred Dalrymple * URL : http://www.oasis-open.org/docbook/tools/dtm/ * License : MIT Section : text lintian: OK pbuilder: OK piuparts: OK It builds those binary packages: docbook-to-man - converter from DocBook SGML into roff man macros To access further information about this package, please visit the following URL: http://mentors.debian.net/package/docbook-to-man Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/docbook-to-man/docbook-to-man_2.0.0-33.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: docbook-to-man (1:2.0.0-33) experimental; urgency=low * New maintainer (Closes: #549475). * Bump up Policy to 3.9.6, no changes needed. * debian/copyright: now follows https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ * Adds patch to fix https://bugs.debian.org/716055 (Closes: #716055). * debian/control: Adds paragraph to suggest more up-to-date tools for new projects. * debian/control: Uses canonical VCS URLs. * debian/patches/*: Fixes header of some patches to add description and other fields (converted from dpatch header). -- Maxime Chatelle Thu, 13 Nov 2014 22:51:53 +0100 Regards, Maxime Chatelle -- Maxime Chatelle (xakz) gpg: 5111 3F15 362E 13C6 CCDE 03BE BFBA B6E3 24AE 0C5B pgpLUDS5ic01I.pgp Description: PGP signature
Re: Depends on exact version
Hi Daniel,
On 13.11.2014 11:29, Daniel Lintott wrote:
On 12/11/14 22:40, Andreas Cadhalpun wrote:
What should work better is '>= ${source:Upstream-Version}'.
However, that is not enough to guarantee that the upstream versions
always match. One could then have e.g.:
gns3= 1.1-1
gns3-gui= 1.1-1
gns3-server = 1.2-1
If you want to prevent that, you can add appropriate Breaks:
gns3-server:
Breaks: gns3-gui (< ${source:Upstream-Version})
gns3-gui:
Breaks: gns3-server (< ${source:Upstream-Version})
I presume this should << since < is deprecated?
Of course. ;)
Would this also need breaks on the greater than side.
No. Assume you have:
gns3= 1.1-1
gns3-gui= 1.1-1
gns3-server = 1.1-1
Then you install gns3-gui (= 1.2-1). This breaks gns3-server (<< 1.2)
and thus gns3-server gets updated as well.
You might want to add similar Breaks for gns3 as well, so that it also
gets updated.
What I'm trying to ensure is that the upstream versions match, the
checks in the gui (that check server version) aren't worried about
Debian revision.
If it's possible to do this, without having to change the breaks
manually each time it would definitely be preferably!
That should work with above dependency relations.
Best regards,
Andreas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54652f00.3070...@googlemail.com
Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]
On 14 November 2014 00:59, Stéphane Aulery wrote: > Le mercredi 12 novembre 2014 à 03:54:05, Don Armstrong a écrit : >> >> This is the last chance for someone to object to entry-point as the tag >> name. If I hear no objections, I'll put this in place on Friday, around >> 18:00 UTC. > >apprenticeship >gateway >initiation >mentoring >mentee-task >traineeship >participate >field-taking >practice >newcomers >stepping >launching-pad > > Better ideas? As a member of the target audience for this tag, and an (Australian) English speaker, from the great suggestions made so far I would choose one of these tags: "apprentice" "initiation" "mentored" "newcomer" "trainee". Any of these convey the desired meaning more clearly in my opinion. My clear favourite is "newcomer", because it has the essential information with a friendly tone, and I have a nice personal reaction compared than the others. It feels inviting, like this: "OK, if that bug is tagged newcomer, and I am a newcomer, then *both* Debian and I think it is a good place to start ... [so a collaborative feeling arises instantly!] ... so now let's look into the details and begin work!" -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMPXz=qde_7-c_yosuhs8s3kwsyxihmddfnasegrdvpuyi0...@mail.gmail.com
[Fwd: Re: ITP? Sponsors of eudev, consolekit2, uselessd?]
Hi, Seems like I sent my question to the wrong list. Please Cc: replies, I'm not subscribed (yet) --- Begin Message --- Am 13.11.2014 um 19:17 schrieb Svante Signell: Hi, Hi, I'm currently looking into packaging eudev, consolekit2, uselessd for Debian. If doing so, is anybody interested in sponsoring uploads of these packages? It would be great to know, before digging into the details. If you wish, please reply to me privately. the correct list for such requests is debian-mentors@lists.debian.org, much fun and luck! -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5464fa56.80...@debian.org --- End Message ---
Bug#769445: RFS: berkeley-abc/1.01+20141105hg5b5af75+dfsg-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "berkeley-abc" * Package name: berkeley-abc Version : 1.01+20141105hg5b5af75+dfsg-1 Upstream Author : Berkeley Logic Synthesis and Verification Group * URL : http://www.eecs.berkeley.edu/~alanmi/abc/ * License : Berkeley (MIT-similar license) Section : electronics It builds those binary packages: berkeley-abc - ABC - A System for Sequential Synthesis and Verification The packaging can be checked out with git from here: git://anonscm.debian.org/debian-science/packages/berkeley-abc.git Changes since the last upload: New upstream version Regards, Ruben Undheim -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+ChNyVNOrpoi-7p8XtMjBjdsrGwMMzivP45HE17N0Uz3C=w...@mail.gmail.com
Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]
Le mercredi 12 novembre 2014 à 03:54:05, Don Armstrong a écrit : > > This is the last chance for someone to object to entry-point as the tag > name. If I hear no objections, I'll put this in place on Friday, around > 18:00 UTC. I am looking for an idea in a nutshell. I'm not English so it's hard for me: apprenticeship gateway initiation mentoring mentee-task traineeship participate field-taking practice newcomers stepping launching-pad Better ideas? -- Stéphane Aulery -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113135932.ga2...@free.fr
Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]
On 2014-11-13 12:43, Stéphane Aulery wrote: > I'm sorry my English is poor and I can hardly do better. I wanted to > summarize the main ideas of the second paragraph on page [1] which I > find very good. The maintainer should know the first glance by reading > the description if it can offer the bug without having to read another > page. Another formulation: > > entry-point > This bug has a known solution but the maintainer thinks it is > an ideal task for new contributors who wish to get involved in > Debian, or who wish to improve their skills. This gateway is a > complement more accessible to mentors.debian.net. > > The maintainer is committed to providing assistance to new > contributors and been able to upload an updated package in a > timely manner. Bugs of any difficulty can be offered. I like this version the much! > [1] https://wiki.debian.org/qa.debian.org/GiftTag -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c0ecb2a52d989b5b5c453de36e3fa...@kvr.at
Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]
Le jeudi 13 novembre 2014 à 11:51:51, Christian Kastner a écrit :
> On 2014-11-13 09:42, Stefano Zacchiroli wrote:
> >
> > I don't think we should include the initial part about "maintainer can
> > easily solve...", as it does seems a bit patronizing ("that's easy for
> > me, but I won't do it because..."). My take: just include the part about
> > being a good entry point (hence the name) for new contributors and scrap
> > the rest.
>
> Perhaps the choice of words could be improved, but I always understood
> the "easy" part as "this issue has a more or less clear solution" (and
> it's just a question of who will put resources into it), as opposed to
> an RFH bug, for which a solution is beyond the capabilities of the
> maintainer. Mentees might find this distinction helpful -- tasks can be
> less intimidating when a correct solution is known.
>
> What do you think of the following?
I'm sorry my English is poor and I can hardly do better. I wanted to
summarize the main ideas of the second paragraph on page [1] which I
find very good. The maintainer should know the first glance by reading
the description if it can offer the bug without having to read another
page. Another formulation:
entry-point
This bug has a known solution but the maintainer thinks it is
an ideal task for new contributors who wish to get involved in
Debian, or who wish to improve their skills. This gateway is a
complement more accessible to mentors.debian.net.
The maintainer is committed to providing assistance to new
contributors and been able to upload an updated package in a
timely manner. Bugs of any difficulty can be offered.
[1] https://wiki.debian.org/qa.debian.org/GiftTag
--
Stéphane Aulery
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141113114310.ga2...@free.fr
Re: Depends on exact version
> binNMUs will cause a few of the binary packages to have a different > debian revision than the rest of the binary packages and the source > packages. > > We have a lintian check for this, I think. Is it not-binnmuable-all-depends-any? I should've remembered that one, because I use the fix that is suggested there. Regards, Roger
Re: Depends on exact version
On Wed, 12 Nov 2014, Henrique de Moraes Holschuh wrote:
> On Wed, 12 Nov 2014, Roger Light wrote:
> > Could you try ${binary:Version} instead?
>
> (= ${binary:Version}) can break binNMUs. Be careful.
binNMUs will cause a few of the binary packages to have a different
debian revision than the rest of the binary packages and the source
packages.
We have a lintian check for this, I think.
One seldom known detail is that the source package version is just a
*default* value for the binary package versions. You can override it
during build. It is not just binNMUs.
This is a valid scenario:
source package foo builds binary packages foo_data, foo_dt2, foo and
dt2.
source package: foo 1.2.3+setone-1
foo_data:all 1.2.3-1
foo_dt2:all setone-1
foo:i386: 1.2.3-1
foo:arm64: 1.2.3-1+b1
dt2:i386: setone-1
dt2:arm64: setone-1+b1
All built from the same source, but both dt2 and foo were subject to a
binNMU later. dt2 and foo have separate versioning.
This is not usual, but it is both valid and supported.
Here's a real life example: package hplip used to do this when hplip and
hpijs started being packaged together by upstream. It took a while and
several releases before upstream moved hpijs to the same version
numbering as hplip.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141113110346.gd19...@khazad-dum.debian.net
Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]
On 2014-11-13 09:42, Stefano Zacchiroli wrote:
> On Wed, Nov 12, 2014 at 07:42:33PM +0100, Stéphane Aulery wrote:
>> entry-point
>> The maintainer can easily solve this bug by himself, but he
>> wants to take it to new contributors who wish to get involved
>> in Debian. Bugs of any difficulty can be offered in order to
>> attract and increase skill.
>
> I don't think we should include the initial part about "maintainer can
> easily solve...", as it does seems a bit patronizing ("that's easy for
> me, but I won't do it because..."). My take: just include the part about
> being a good entry point (hence the name) for new contributors and scrap
> the rest.
Perhaps the choice of words could be improved, but I always understood
the "easy" part as "this issue has a more or less clear solution" (and
it's just a question of who will put resources into it), as opposed to
an RFH bug, for which a solution is beyond the capabilities of the
maintainer. Mentees might find this distinction helpful -- tasks can be
less intimidating when a correct solution is known.
What do you think of the following?
entry-point
-The maintainer can easily solve this bug by himself, but he
-wants to take it to new contributors who wish to get involved
-in Debian. Bugs of any difficulty can be offered in order to
-attract and increase skill.
+This bug has a known solution but the maintainer requests
+someone else implement it. This is an ideal task for new
+contributors who wish to get involved in Debian, or who
+wish to improve their skills.
The maintainer is committed to providing assistance to new
contributors. This gateway is a complement more accessible to
mentors.debian.net.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1624917a9dcf44b56d5641b80c2bc...@kvr.at
Re: Depends on exact version
On 12/11/14 23:32, Henrique de Moraes Holschuh wrote:
> On Wed, 12 Nov 2014, Roger Light wrote:
>> Could you try ${binary:Version} instead?
>
> (= ${binary:Version}) can break binNMUs. Be careful.
>
Indeed, I am keen to try and avoid any breakages like that. I also don't
think the above would work for this for example:
GUI 1.1-1 and Server 1.1-1 = OK
GUI 1.1-2 and Server 1.1-4 = OK
GUI 1.1-1 and Server 1.2-1 = Not OK
Regards
Daniel
signature.asc
Description: OpenPGP digital signature
Re: Depends on exact version
On 12/11/14 22:40, Andreas Cadhalpun wrote:
> [...]
>
> You require the exact upstream version (1.1).
> This can't work, because there will always be the Debian revision added
> (1.1-1~exp1).
>
I had a suspicion that this was why, but wasn't sure.
> What should work better is '>= ${source:Upstream-Version}'.
>
> However, that is not enough to guarantee that the upstream versions
> always match. One could then have e.g.:
> gns3= 1.1-1
> gns3-gui= 1.1-1
> gns3-server = 1.2-1
>
> If you want to prevent that, you can add appropriate Breaks:
> gns3-server:
> Breaks: gns3-gui (< ${source:Upstream-Version})
> gns3-gui:
> Breaks: gns3-server (< ${source:Upstream-Version})
>
I presume this should << since < is deprecated? Would this also need
breaks on the greater than side.
What I'm trying to ensure is that the upstream versions match, the
checks in the gui (that check server version) aren't worried about
Debian revision.
If it's possible to do this, without having to change the breaks
manually each time it would definitely be preferably!
Regards Daniel
signature.asc
Description: OpenPGP digital signature
Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]
On Wed, Nov 12, 2014 at 03:54:05PM -0800, Don Armstrong wrote:
> Excellent; thanks. I'm going to make these gender-neutral, and then I'll
> commit them.
>
> This is the last chance for someone to object to entry-point as the tag
> name. If I hear no objections, I'll put this in place on Friday, around
> 18:00 UTC.
I'm fine with entry-point. However, about its description:
On Wed, Nov 12, 2014 at 07:42:33PM +0100, Stéphane Aulery wrote:
> entry-point
> The maintainer can easily solve this bug by himself, but he
> wants to take it to new contributors who wish to get involved
> in Debian. Bugs of any difficulty can be offered in order to
> attract and increase skill.
I don't think we should include the initial part about "maintainer can
easily solve...", as it does seems a bit patronizing ("that's easy for
me, but I won't do it because..."). My take: just include the part about
being a good entry point (hence the name) for new contributors and scrap
the rest.
Cheers.
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: changes file issue when packaging for backports
On Thu, 13 Nov 2014, quidame wrote: > Oops, > > not Priority: but Urgency: > > quidame wrote: > > Hi, > > > > I try to backport bilibop_0.4.22 source package (native). If only changes > > from 0.4.22 to 0.4.22~bpo70+1 are copied in to the changes file, lintian > > complains with the 'backports-changes-missing' error tag [1]. If I add > > -v0.4.21 dpkg-genchanges, the resulting changes file says: > > > > Priority: medium > > [...] > > Closes: 750507 756086 > > > > This overrides the priority of thr bpo package (low, in wheezy-backports); > > medium is the priority of 0.4.22 in unstable. It claims to close two bugs > > that are already closed in 0.4.22; more, one of these bugs id specific to > > jessie/sid, and the bugfix is reverted in the bpo. should I edit the changes > > file to modify Priority: field and modify or remove Closes: field ? Or > > replave > > -v0.4.21 option by something more relevant (shortened changelog entry > > for 0.4.22) ? Or can I let it go 'as is' ? Priority and closed bugs are not relevant for backports. So just ignore them and the right version for -v. Alex -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113084223.ga20...@lisa.snow-crash.org
