Wookey writes:
> On 2024-05-24 16:39 +0200, David Given wrote:
>> I'm try to put together a package for a big, complex application. One of
>> its dependencies isn't in Debian yet. What do I do?
>
> Package the dependency first.
>
>> - package up the dependency and somehow get both packages sponso
On Sun, 26 May 2024 at 04:58, Wookey wrote:
> On 2024-05-24 16:39 +0200, David Given wrote:
>
[...]
> > - package up the dependency and get it sponsored first... meaning that
> I'll
> > be trying to get a library added which has no users.
>
> This is what I do. All packages have no users before
On 2024-05-24 16:39 +0200, David Given wrote:
> I'm try to put together a package for a big, complex application. One of
> its dependencies isn't in Debian yet. What do I do?
Package the dependency first.
> - package up the dependency and somehow get both packages sponsored at the
> same time (ho
Unfortunately they're all external libraries. Right now I'm just trying to
make it build (it uses a new version of gradle...) and am making a list of
the libraries one at a time as I find them. Nothing's particularly complex;
examples are Phidias (https://github.com/rotty3000/phidias) and jungrapht
Hi David,
Le ven. 24 mai 2024 à 17:06, David Given a écrit :
> I'm try to put together a package for a big, complex application. One of
> its dependencies isn't in Debian yet. What do I do?
>
> - package up the dependency and somehow get both packages sponsored at the
> same time (how?);
> - pac
On Fri, 2024-05-24 at 16:39 +0200, David Given wrote:
> I'm try to put together a package for a big, complex application. One of its
> dependencies isn't in Debian yet. What do I do?
>
> - package up the dependency and somehow get both packages sponsored at the
> same time (how?);
> - package up
On 2024-05-04 03:44 +, james smith wrote:
> I am trying to package ly[1] I got everything up to the rules part, I am
> stuck thinking on how to edit/make the makefile, if you have any tips or
> tools that can make this a easier process, I would be much grateful
Any editor will do - note that t
On Sat, May 04, 2024 at 03:44:45AM +, james smith wrote:
> I am trying to package ly[1] I got everything up to the rules part, I am
> stuck thinking on how to edit/make the makefile, if you have any tips or
> tools that can make this a easier process, I would be much grateful
You don't normally
Hi Ryan,
On Wed, Jun 21, 2023 at 03:07:24PM -0500, Ryan Pavlik wrote:
> I'm not sure if uscan can do it,
I did get it working but it's exceedingly cludgy. I have to use mode=git
for the second component since uscan can't just download master.tar.gz
AFACT (it's at a static location not linked fro
I'm not sure if uscan can do it, but for meshlab, as they don't tag the
submodule when they release the main project, I have a script that updates
the submodule commit using the github API. It's more clunky than I'd like,
but I am not sure exactly how to fix this. It parses the version out of
debia
On Tue, 2023-06-13 at 16:48 +0200, Daniel Gröber wrote:
> I'm working on packaging prjtrellis[1] which has a git submodule that is
> required for building. My plan is to use dpkg-source's multi upstream
> tarball support to do this.
This appears to be the repo of the submodule:
https://github.co
Hello,
On 2023-01-17 15:04, David Kalnischkies wrote:
I would suggest talking to maintainers of similar packages, they can
probably give you more practical advice in this matter.
I maintain a couple of similar header-only packages. Developers
unwilling to provide stable API are a challenge, b
Hi,
On Sun, Jan 15, 2023 at 01:21:59PM +, Matthew Fennell wrote:
> I'm looking into whether it is feasible to package EnTT [1], a header-only C++
> library with breaking API changes every few releases / months.
As I use it in a private toy-project I can certify that it is breaking
API (and AB
Got access to salsa.debian.org today! Woot!
Hopefully one of the VoIP packaging group will get back to me re below in
the next few weeks.
Thanks.
On Thu, 30 Dec 2021, 09:01 Gavin Henry, wrote:
> Thanks all for the help and pointers everyone.
>
> I've managed to build SentryPeer (
> https://gi
Thanks all for the help and pointers everyone.
I've managed to build SentryPeer (
https://github.com/SentryPeer/SentryPeer/tree/debian-packaging/debian). I'm
just going through debuild now to clean up lintian issues and pbuilder runs
for missing depends.
Suprisingly enjoyable and "dh" in the rule
> Dear Gavin Henry,
Hi Chris!
> I didn't follow your whole discussion, but if you have time I would highly
> appreciate if you could put all this information together at a well-findable
> place (maybe: extend https://wiki.debian.org/UpstreamGuide ?)
>
> Reason:
> I'm probably going to search fo
On Wed, 29 Dec 2021 at 13:51, Robin Gustafsson wrote:
>
> On Wed, Dec 29, 2021 at 2:03 PM Gavin Henry wrote:
> >>
> >> > Is it best practice to have:
> >> >
> >> > 1. debian folder in your main repo
> >> > 2. debian folder branch in main repo
> >> > 3. Separate repo for this
> >>
> >> A separate
On Wed, Dec 29, 2021 at 2:03 PM Gavin Henry wrote:
>>
>> > Is it best practice to have:
>> >
>> > 1. debian folder in your main repo
>> > 2. debian folder branch in main repo
>> > 3. Separate repo for this
>>
>> A separate repo hosted on salsa.debian.org.
>
> Thanks. That's for an official package
>
> > Is it best practice to have:
> >
> > 1. debian folder in your main repo
> > 2. debian folder branch in main repo
> > 3. Separate repo for this
>
> A separate repo hosted on salsa.debian.org.
>
Thanks. That's for an official package, or?
>
>
> > #DEBHELPER#
> >
> One of the first google hits:
>
> https://manpages.debian.org/bullseye/debhelper/debhelper.7.en.html
Thanks. I see it now. With quotes "#DEBHELPER#" didn't show up, but:
Automatic generation of Debian install scripts
Some debhelper commands will automatically generate p
Hi Gavin,
On Wed, Dec 29, 2021 at 12:35 PM Gavin Henry wrote:
> [...]
> Is it best practice to have:
>
> 1. debian folder in your main repo
> 2. debian folder branch in main repo
> 3. Separate repo for this
A separate repo hosted on salsa.debian.org.
On Wed, Dec 29, 2021 at 12:37 PM Gavin Henry
Am 29.12.2021 um 12:36 teilte Gavin Henry mit:
Hi,
What's this for, when it looks like this was written manually? Google
shows nothing:
https://salsa.debian.org/dns-team/bind9/-/blob/debian/main/debian/bind9.postinst#L35
#DEBHELPER#
One of the first google hits:
https://manpages.debian.org
What's this for, when it looks like this was written manually? Google
shows nothing:
https://salsa.debian.org/dns-team/bind9/-/blob/debian/main/debian/bind9.postinst#L35
#DEBHELPER#
Thanks.
This is exactly what I wanted to see :-)
https://salsa.debian.org/dns-team/bind9/-/blob/debian/main/debian/bind9.postinst
Is it best practice to have:
1. debian folder in your main repo
2. debian folder branch in main repo
3. Separate repo for this
Thanks.
Hello Gavin,
>
> Le 2021-12-28 à 19 h 14, Gavin Henry a écrit :
> > I was given this advice from Arthur, a Debian developer, but I can't
> > find some of the finer details I'm looking for:
> >
>
> In addition to the developer reference and the other documentation, you
> can get some inspiration fro
Hello Gavin,
Le 2021-12-28 à 19 h 14, Gavin Henry a écrit :
I was given this advice from Arthur, a Debian developer, but I can't
find some of the finer details I'm looking for:
In addition to the developer reference and the other documentation, you
can get some inspiration from packages wit
I was given this advice from Arthur, a Debian developer, but I can't find
some of the finer details I'm looking for:
---
I recommend looking at https://wiki.debian.org/UpstreamGuide to some
pointers about how to make it easy to ensure your software can be
easily packaged in Debian.
If you're
On Thu, 01 Jul 2021 00:46:45 +0200, David Kalnischkies wrote:
> On Wed, Jun 30, 2021 at 09:26:35PM +, Peymaneh Nejad wrote:
> > Intuitively I would just replace the existing folder with my own packaging
> If you use source package format "3.0 (quilt)" (which you should anyhow)
> this is done a
Hi,
On Wed, Jun 30, 2021 at 09:26:35PM +, Peymaneh Nejad wrote:
> Intuitively I would just replace the existing folder with my own packaging
If you use source package format "3.0 (quilt)" (which you should anyhow)
this is done automatically for you.
See man dpkg-source → SOURCE PACKAGE FORMA
Ansgar wrote:
>
> Still, having to first install some other package from some third-party
> repository as proposed here for the systemd-genie package before being
> able to use or build software is not very user-friendly and also makes it
> harder to find sponsors interested in reviewing and uplo
Andrey Rahmatullin wrote on Thursday, August 20, 2020 3:08 AM:
> On Thu, Aug 20, 2020 at 02:15:07AM +, Paul Wise wrote:
> > > I'm currently working on packaging a .NET Core utility for contrib
> >
> > I note that .NET is Free Software these days, so you should be able to
> > package both for m
There's also Mono, which is already in Debian but has some limitations
(e.g. C# features newer than version 6 may not be available).
https://lists.debian.org/debian-cli/ has been mostly-inactive for years.
On Thu, Aug 20, 2020 at 02:15:07AM +, Paul Wise wrote:
> > I'm currently working on packaging a .NET Core utility for contrib
>
> I note that .NET is Free Software these days, so you should be able to
> package both for main instead of using contrib.
>
> https://en.wikipedia.org/wiki/.NET_Cor
On Thu, 2020-08-20 at 11:40 +0500, Andrey Rahmatullin wrote:
> On Thu, Aug 20, 2020 at 12:09:08AM +0200, gregor herrmann wrote:
> > libdbd-oracle-perl is such an example; it's in contrib because it's
> > free software itself but needs oracle software which is not even in
> > Debian. Typically someo
On Thu, Aug 20, 2020 at 12:09:08AM +0200, gregor herrmann wrote:
> > > > > Are these acceptable caveats for a source package in contrib,
> > > > No, the package still needs to be built without network, using only its
> > > > contents and packages from Debian.
> > > > You also need to produce a pack
On Wed, Aug 19, 2020 at 11:04 AM Alistair J R Young wrote:
> I'm currently working on packaging a .NET Core utility for contrib
I note that .NET is Free Software these days, so you should be able to
package both for main instead of using contrib.
https://en.wikipedia.org/wiki/.NET_Core
https://g
On Wed, 19 Aug 2020 22:14:36 +0500, Andrey Rahmatullin wrote:
> On Wed, Aug 19, 2020 at 02:31:10PM +, Alistair J R Young wrote:
> > > > Are these acceptable caveats for a source package in contrib,
> > > No, the package still needs to be built without network, using only its
> > > contents and
On Wed, Aug 19, 2020 at 02:31:10PM +, Alistair J R Young wrote:
> > > Are these acceptable caveats for a source package in contrib,
> > No, the package still needs to be built without network, using only its
> > contents and packages from Debian.
> > You also need to produce a package that can
Andrey Rahmatullin wrote:
> > Are these acceptable caveats for a source package in contrib,
> No, the package still needs to be built without network, using only its
> contents and packages from Debian.
> You also need to produce a package that can be installed with apt and usable
> after that, a
Note that you replied to my email in private and I can't reply back as
your server blacklisted my IP.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Wed, Aug 19, 2020 at 10:31:43AM +, Alistair J R Young wrote:
> I'm currently working on packaging a .NET Core utility for contrib (ITP here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968331; current version of
> the package here: https://mentors.debian.net/package/systemd-genie/
> I created the current package with the tools installed under Buster
> using dh_make and the Lintian on Buster seems to be happy, except to the
> jquery stuff of course. Maybe this leads to the outdated versions.
It does indeed.
> Currently I provide this for people installing PyCA on their curr
Hej Robin,
thanks for all the advice. It is some time ago, since I created my last
Debian Package and a lot has changed.
I created the current package with the tools installed under Buster
using dh_make and the Lintian on Buster seems to be happy, except to the
jquery stuff of course. Maybe this
Hi Sven,
I'm a new contributor myself and cannot sponsor the package nor answer
all of your questions, but I can offer some suggestions.
> Currently there is a Lintian error, due to the fact, that PyCA
> itself ships an own version of jquery
This would not be allowed in Debian. Firstly, the jQue
On Tue, Oct 15, 2019 at 4:06 PM Paul wrote:
> Rather than starting work on version 1.23 I am thinking I will open
> source my project and get it bundled with Debian. I would appreciate
> some advice on how I should proceed. I have been reading
> https://www.debian.org/doc/manuals/developers-refere
On Tue, Oct 15, 2019 at 05:33:08PM +1000, supp...@masteroftactics.org wrote:
> Hi,
>
> Rather than starting work on version 1.23 I am thinking I will open source
> my project and get it bundled with Debian. I would appreciate some advice on
> how I should proceed. I have been reading
> https://www
Nico Schlömer wrote:
> I'm starting to package Stellar, a tet mesh optimizer [1].
> The package is very basic, but still things are failing. I don't know why.
> 1. The gitlab-ci build [2] fails with
> ```
> Checking cache for default...
> FATAL: file does not exist
> Failed to extract cache
> `
On Thu, Aug 01, 2019 at 09:43:20AM -0400, Nico Schlömer wrote:
> > No idea about that but "gbp:error: Non-native package 'stellar' has
> invalid version '1.0'" is a valid problem.
>
> Fair enough. What does it mean? How to fix it?
It means that a non-native package must have a version that include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thanks Andrey for the reply.
> No idea about that but "gbp:error: Non-native package 'stellar' has
invalid version '1.0'" is a valid problem.
Fair enough. What does it mean? How to fix it?
> Have you ever built this package yourself? I'm sure the
On Thu, Aug 01, 2019 at 03:00:14PM +0200, Nico Schlömer wrote:
> The package is very basic, but still things are failing. I don't know why.
Even though it's very basic it still contains at least two fatal problems
and some lesser ones.
> 1. The gitlab-ci build [2] fails with
> ```
> Checking cache
On Sun, Jul 14, 2019 at 09:54:40AM +0100, Rebecca N. Palmer wrote:
> > If a remote has a branch this doesn't mean your repo has the same branch.
> Is this intended as agreement with my "rename upstream/master with git
> branch -u" proposal? Or is it a suggestion to delete Salsa/master and
> force-
Andrey Rahmatullin wrote:
If a remote has a branch this doesn't mean your repo has the same branch.
Is this intended as agreement with my "rename upstream/master with git
branch -u" proposal? Or is it a suggestion to delete Salsa/master and
force-push upstream/master over it (i.e. rewrite hi
On Sat, Jul 13, 2019 at 02:41:18PM +0100, Rebecca N. Palmer wrote:
> (b) How do I deal with branch/tag name conflicts between upstream and
> packaging?
They shouldn't happen.
> There are at least two ways conflicts can happen by accident:
>
> (i) gbp defaults to naming the packaging branch 'mast
Hi,
On Sun, Sep 09, 2018 at 12:09:00PM +0200, Birger Schacht wrote:
> i'm trying to package a software using git and importing upstream
> releases from git tags. There are files in the git tree that have to be
> removed to make the package dfsg compliant (what would normally happen
> through repac
On Sun, Sep 9, 2018 at 6:09 PM, Birger Schacht wrote:
> i'm trying to package a software using git and importing upstream
> releases from git tags. There are files in the git tree that have to be
> removed to make the package dfsg compliant (what would normally happen
> through repackaging).
The
On Tue, May 22, 2018 at 11:01:00AM -0500, Alberto Leiva wrote:
> } } So I have ended up with a means to create two packages; one for the
> } } modules and one for the clients.
> }
> } Should be easy to combine them into one package.
Should be easy to combine them into one source package.
> }
> The debian/rules should install all the files into debian/.
I haven't managed to pull this off yet (I haven't really tried much,
mind you, because I've struggled patching a few other cracks), but I'm
wondering now if attempting this is really a good idea.
For one thing, `man dh_dkms` has this c
On Tue, May 15, 2018 at 7:31 AM, Alberto Leiva wrote:
> I'm trying to package a couple of kernel modules that come with a few
> userspace clients to interact with them.
...
> So I have ended up with a means to create two packages; one for the
> modules and one for the clients.
Should be easy to c
Hello,
>suggestions and uploaded to mentors[1]. There was a sponsor in 2016, but
>he is not responding now. Can anyone look into this package!. Thank you.
done now
G.
On Mon, Sep 18, 2017 at 10:01:58PM -0700, Mike Ingle wrote:
> Is there a mentor available to help me get Confidant Mail into the Debian
> repository?
> This should not be too difficult, as I already have a .deb package working,
> and the program is pure python 2.7
Please follow https://mentors.debi
Den 2017-05-23 kl. 02:42, skrev Paul Wise:
I note that PythonQt is orphaned, so you may want to adopt it:
I thought about it, but since I'm inexperienced regarding packaging for
Debian, that wasn't the first thing I wanted to suggest. It also depends
on the outcome of my first contributions
On Tue, May 23, 2017 at 4:56 AM, Erik Lundin wrote:
> We're using PythonQt built for Qt 5 at work, and I have been looking at the
> possibility to package it for Debian. Here is what I have found so far:
I note that PythonQt is orphaned, so you may want to adopt it:
https://packages.qa.debian.or
On 01.03.2017 00:18, Ben Finney wrote:
> David Rabel writes:
>
>> PS: Please CC me, if you answer to this mail, as I am subscribed to
>> Debian mentors anymore.
>
> To participate, please subscribe so that we don't all have to violate
> convention to do that.
Ok, I did.
>> is it possible to d
David Rabel writes:
> PS: Please CC me, if you answer to this mail, as I am subscribed to
> Debian mentors anymore.
To participate, please subscribe so that we don't all have to violate
convention to do that.
> is it possible to do Debian packaging with different gpg keys and email
> addresses?
Thanks for the tips on this. I am brand new to packaging Debian products. The
product I am working on packaging is
https://github.com/keepassxreboot/keepassxc. My main goal with packaging it is
because I am a big fan of it and I keep my systems clean so I want a pure
Debian package that I can i
On 02/26/2017 04:52 PM, The Wanderer wrote:
> On 2017-02-26 at 10:47, Ghislain Vaillant wrote:
>
>> On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote:
>>
>>> I am packaging a gui that has dependencies for qt and such. How do
>>> I go about ensuring that X is available as well? Do I list that as
On 2017-02-26 at 10:47, Ghislain Vaillant wrote:
> On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote:
>
>> I am packaging a gui that has dependencies for qt and such. How do
>> I go about ensuring that X is available as well? Do I list that as
>> a dependency as well. The upstream maintainers d
On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote:
> I am packaging a gui that has dependencies for qt and such. How do I go about
> ensuring that X is available as well? Do I list that as a dependency as well.
> The upstream maintainers don’t call it out specifically but it is understood.
> L
Dear Matt,
libqt5gui5 is already depending on the needed X libraries, so unless
your app is doing something tricky, you don't need to care about this.
But we can tell more if we see the application in question...
Regards,
Zoltan Gyarmati
https://zgyarmati.de
On 02/26/2017 04:15 PM, matt jones
Dear Matt,
libqt5gui5 is already depending on the needed X libraries, so unless
your app is doing something tricky, you don't need to care about this.
But we can tell more if we see the application in question...
Regards,
Zoltan Gyarmati
https://zgyarmati.de
On 02/26/2017 04:15 PM, matt jones
On 6 February 2017 at 12:25, Narcis Garcia wrote:
> Very far from the number of libs/tools that cannot unmask something like
> Alexander Wirt formorer formorer de at anywhere of a page.
>
Probably this mentors mailing list isn't the right place for this discussion.
__
I'm using this express-made address because personal addresses aren't
masked enough at this list's archives. Mailing lists service
administrator should fix this.
El 06/02/17 a les 11:16, Alexander Wirt ha escrit:
> On Mon, 06 Feb 2017, Narcis Garcia wrote:
>
>> __
>> I'm using t
On Mon, 06 Feb 2017, Narcis Garcia wrote:
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this list's archives. Mailing lists service
> administrator should fix this.
> El 06/02/17 a les 10:42, Alexander Wirt ha escrit:
> > On Mon, 06 Feb 201
__
I'm using this express-made address because personal addresses aren't
masked enough at this list's archives. Mailing lists service
administrator should fix this.
El 06/02/17 a les 10:42, Alexander Wirt ha escrit:
> On Mon, 06 Feb 2017, Narcis Garcia wrote:
>
>> __
>> I'm using t
On Mon, 06 Feb 2017, Narcis Garcia wrote:
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this list's archives. Mailing lists service
> administrator should fix this.
We don't intend to. Debian is an open Distribution and we believe in being
__
I'm using this express-made address because personal addresses aren't
masked enough at this list's archives. Mailing lists service
administrator should fix this.
El 05/02/17 a les 21:25, Gianfranco Costamagna ha escrit:
> Hi,
>
>
>
>> You are expected to set that bit on the file and c
Hi,
>You are expected to set that bit on the file and commit it. Gitlab has
>nothing to do with this.
stuff like github now allows to modify files and commit them from the web
interface
(without having to checkout the repo).
I'm not sure about gitlab interface, but I don't think you can chmod
On Sun, Feb 05, 2017 at 07:29:21PM +0100, Narcis Garcia wrote:
> Another warning I don't know how to solve in GitLab:
> "dpkg-buildpackage: warning: debian/rules is not executable; fixing that"
> I don't find in GitLab CMS the way to set executable bit to a file.
You are expected to set that bit on
Oh good! With the tab fix completes deb generation! Thank your patience
Adrey!
A warning that can be pointing to the lack of target file problem:
"dpkg-genchanges: warning: package ntfsundelete-tree in control file but
not in files list"
file "files" contains:
ntfsundelete-tree admin extra
Anothe
On Sun, Feb 05, 2017 at 10:17:59AM +0100, Narcis Garcia wrote:
> I'm not kidding. With the default dh $@ only line, outputs an error message.
I've explained why. You were not using the tab character. Either the
instructions you are using don't mention that or you missed that part
(also, d/rules is
__
I'm using this express-made address because personal addresses aren't
masked enough at this list's archives. Mailing lists service
administrator should fix this.
El 04/02/17 a les 21:09, Andrey Rahmatullin ha escrit:
> On Sat, Feb 04, 2017 at 09:02:20PM +0100, Narcis Garcia wrote:
d
On Sat, Feb 04, 2017 at 09:02:20PM +0100, Narcis Garcia wrote:
> >> dpkg-buildpackage continues now, when my "rules" file has this only
> >> content:
> >>
> >> #!/usr/bin/make -f
> >> clean:
> >> binary:
> >> binary-arch:
> >> binary-indep:
> >> build:
> >> build-arch:
> >> build-indep:
> > Which,
__
I'm using this express-made address because personal addresses aren't
masked enough at this list's archives. Mailing lists service
administrator should fix this.
El 04/02/17 a les 20:37, Andrey Rahmatullin ha escrit:
> On Sat, Feb 04, 2017 at 06:57:56PM +0100, Narcis Garcia wrote:
>> dpk
On Sat, Feb 04, 2017 at 06:57:56PM +0100, Narcis Garcia wrote:
> dpkg-buildpackage continues now, when my "rules" file has this only content:
>
> #!/usr/bin/make -f
> clean:
> binary:
> binary-arch:
> binary-indep:
> build:
> build-arch:
> build-indep:
Which, of course, doesn't do anything useful.
dpkg-buildpackage continues now, when my "rules" file has this only content:
#!/usr/bin/make -f
clean:
binary:
binary-arch:
binary-indep:
build:
build-arch:
build-indep:
Now I'm at this point:
(...)
dpkg-genchanges >../ntfsundelete-tree_1.0.0-1_amd64.changes
dpkg-genchanges: warning: package n
On Sat, Feb 04, 2017 at 04:55:13PM +0100, Narcis Garcia wrote:
> wget --no-check-certificate -O ntfsundelete-tree_1.0.0.orig.tar
> https://git.actiu.net/libre/ntfsundelete-tree/repository/archive.tar?ref=master
This is not an orig.tar.
> I don't know what is the minimal expected to be in "debian/
I'm now trying with the following*:*
rm -fr /tmp/deb ; mkdir /tmp/deb ; cd /tmp/deb
wget --no-check-certificate -O ntfsundelete-tree_1.0.0.orig.tar
https://git.actiu.net/libre/ntfsundelete-tree/repository/archive.tar?ref=master
tar xf ntfsundelete-tree_1.0.0.orig.tar
cd ntfsundelete-tree-master*
[2017-01-28 22:43] wf...@niif.hu (Ferenc Wágner)
> Dmitry Bogatov writes:
> > - freshly rebuilt with doxygen at build time documentation again
> >contain minified JS file and Lintian again complains about it.
> > Help or experience sharing are welcome.
>
> See https://sources.debian.net/src/
Dmitry Bogatov writes:
> During my work on bglibs, I discovered following:
>
> - new upstream release (2.03) include doxygen documentation into tarball
> - unlike previous packageed release (1.06) it contains minified JS file
> - Lintian warns about source package, containing prebuilt document
Dear Narcis,
I am an upstream maintaining a Debian package. Frankly, I think you're
overcomplicating things. In particular, I strongly recommend ignoring
git-buildpackage, simply because it was not designed with your situation
in mind.
I suggest using a single branch, and building with dpkg-bui
On Tue, Dec 20, 2016 at 07:14:17PM +0100, Narcis Garcia wrote:
> You mean I really need to maintain 2 branches of code (master*+*debian)?
I didn't say that, you can put debian/ into your upstream sources.
> Then I imagine these are my steps to do:
> $ wget --no-check-certificate -O ntfsundelete-tr
You mean I really need to maintain 2 branches of code (master*+*debian)?
Then I imagine these are my steps to do:
$ wget --no-check-certificate -O ntfsundelete-tree_1.0.0.orig.tar
https://git.actiu.net/libre/ntfsundelete-tree/repository/archive.tar?ref=master
$ tar xf ntfsundelete-tree_1.0.0.orig
On Tue, Dec 20, 2016 at 04:48:30PM +0100, Narcis Garcia wrote:
> Currently, I'm editing files directly with GitLab web interface.
> For the moment, I only want "packaging from git":
> Git -> Packaging helper (single direction sense)
Well, you don't really need helpers, you can just checkout the deb
Currently, I'm editing files directly with GitLab web interface.
For the moment, I only want "packaging from git":
Git -> Packaging helper (single direction sense)
Thanks.
__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.
On Tue, Dec 20, 2016 at 03:25:20PM +0100, Adam Borowski wrote:
> It also suffers from treating quilt as a god rather than an abomination
> it is. Using version control checked into another version control is a
> disaster.
gbp-pq
--
WBR, wRAR
signature.asc
Description: PGP signature
On 20/12/16 15:25, Adam Borowski wrote:
On Tue, Dec 20, 2016 at 11:00:20AM +0100, Narcis Garcia wrote:
Hello, I'm trying to maintain a small project in my public Git, and to
have an easy way to build a package for Debian OS obtaining a good/clean
result.
Even just using git directly without
On Tue, Dec 20, 2016 at 11:00:20AM +0100, Narcis Garcia wrote:
> Hello, I'm trying to maintain a small project in my public Git, and to
> have an easy way to build a package for Debian OS obtaining a good/clean
> result.
> After this, I will try to deploy my APT repository or contact some
> sponsor
I made a single file in ShellScript. To walk to Debian inclusion,
somebody suggested me to publish it in a control version system (as
Git). I've deployed this GitLab instance and now I only want to sure
this is packageable.
At this point, I prefer a single branch (master?) if it's possible, to
use
On 20/12/16 13:21, Andrey Rahmatullin wrote:
On Tue, Dec 20, 2016 at 01:10:03PM +0100, Alec Leamas wrote:
I have been struggling with this myself. My current approach
- One separate branch for the debian packaging
- In that branch, add the release branch as a git submodule
- In the debi
On Tue, Dec 20, 2016 at 01:10:03PM +0100, Alec Leamas wrote:
> I have been struggling with this myself. My current approach
>
> - One separate branch for the debian packaging
> - In that branch, add the release branch as a git submodule
> - In the debian branch, check in and tag the pristin
1 - 100 of 927 matches
Mail list logo
