Packaging from Git

[Narcis Garcia]

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 for Debian official repository.

I'm executing this but I don't identify the problem:

$ cd /tmp
$ rm -fr ntfsundelete-tree
$ export GIT_SSL_NO_VERIFY=1
$ git clone https://git.actiu.net/libre/ntfsundelete-tree
$ cd ntfsundelete-tree
$ git-buildpackage
gbp:error: upstream/1.0.0 is not a valid treeish

Can the Git content be bad? Lack of files? Unnecessary files? Bad structure?

Thanks.
-- 


__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.

Re: Packaging from Git

[Narcis Garcia]

Maintaining debian-branch, upstream-branch and pristine-tar... Does it
mean that I'll need to replicate "master" branch to those 3 sub-branches
each time I wan to apply an update?

Same for each upstream/ subdirectories?


__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.
El 20/12/16 a les 11:17, Andrey Rahmatullin ha escrit:
> On Tue, Dec 20, 2016 at 11:00:20AM +0100, Narcis Garcia wrote:
>> Can the Git content be bad? Lack of files? Unnecessary files? Bad structure?
> Yes.
> gbp requires a special repo structure, see
> file:///usr/share/doc/git-buildpackage/manual-html/gbp.intro.html#GBP.REPOSITORY
> 

Re: Packaging from Git

[Narcis Garcia]

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 an easy tool (if it's possible) that makes Debian packages from this
very simple source.

I've chosen git-buildpackage only because it seemed a simple tool to
package from online sources.
I leave sophistications and "pro" deployments for the future, to not
become crazy today.



__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.
El 20/12/16 a les 13:21, Andrey Rahmatullin ha escrit:
> On Tue, Dec 20, 2016 at 12:57:21PM +0100, Narcis Garcia wrote:
>> Maintaining debian-branch, upstream-branch and pristine-tar... Does it
>> mean that I'll need to replicate "master" branch to those 3 sub-branches
>> each time I wan to apply an update?
> Working with the upstream git repo is covered at
> file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL
> You have the upstream code in the upstream branch and the upstream+debian
> code in the master branch and you use the upstream tags.
> 
>> Same for each upstream/ subdirectories?
> Those are not subdirs but tags, and if you use the upstream repo directly
> you should use the upstream tags directly, by configuring gbp.
> 
> 
> Note that it will be much harder for you to learn the workflows when
> working with just one repo for your code and your packaging. Usual
> workflows assume that you are not the author of the code you are
> packaging.
> 

Re: Packaging from Git

[Narcis Garcia]

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.
El 20/12/16 a les 15:25, Adam Borowski ha escrit:
> 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 for Debian official repository.
>>
>> I'm executing this but I don't identify the problem:
>> $ git-buildpackage
>> Can the Git content be bad? Lack of files? Unnecessary files? Bad structure?
> 
> Note that "packaging with git" is very distinct from "packaging with
> git-buildpackage".  The latter, despite the name, is merely one of many
> possible workflows, and a very idiosyncratic one.  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.
> 
> Even just using git directly without any helpers is, IMO, much better -- you
> can conveniently transfer patches both ways between your and upstream
> repository, at every point you get an appropriate form for modification --
> you can just hack on the code (with something quilt-based you need to
> finalize patches after every incremental edit), etc.
> 
> Another option, much liked by everyone I hear, is dgit -- I only looked at
> its very first iteration, though, with no tuits to check out a modern
> version yet so I can't give meaningful advice, but a git-using workflow
> that's not based on quilt can't possibly be worse than gbp :)
> 
> 
> Meow!
> 

Re: Packaging from Git

[Narcis Garcia]

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.tar

$ cd cd ntfsundelete-tree*

$ dpkg-buildpackage

parsechangelog/debian: warning: debian/changelog(l3): badly
formatted trailer line
LINE:  -- Narcis Garcia   Sat Dec 17 16:48:00 UTC
2016
parsechangelog/debian: warning: debian/changelog(l3): found eof
where expected more change data or trailer
dpkg-buildpackage: source package ntfsundelete-tree
dpkg-buildpackage: source version 1.0.0-1
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: error: unable to determine source changed by


__
I'm using this express-made address because personal addresses aren't masked 
enough at lists.debian.org archives.

El 20/12/16 a les 16:59, Andrey Rahmatullin ha escrit:
> 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 debian
> branch and run dpkg-buildpackage, if you have an orig.tar ready. But to
> correctly make the orig.tar you'll need to use git archive and
> pristine-tar.
>

Re: Build-Depends vs Depends

[Narcis Garcia]

Build-Depends should not make any effect during package installation
process, because it's a dependency only for package-building process.



__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.
El 30/12/16 a les 05:31, Taylor Kline ha escrit:
> What is the difference? How are they treated differently during the
> apt installation process? Thanks :)
> 

Re: Packaging from Git

[Narcis Garcia]

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*
export LANG=en ; export PERL_BADLANG=0
dpkg-buildpackage

And last output is:

dpkg-buildpackage: source package ntfsundelete-tree
dpkg-buildpackage: source version 1.0.0-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Narcis Garcia 
dpkg-buildpackage: host architecture amd64
dpkg-buildpackage: warning: debian/rules is not executable; fixing that
 dpkg-source --before-build 
ntfsundelete-tree-master-5565fb581c3d494e81c74074333f20d9b2a1df23
 fakeroot debian/rules clean
make: *** No rule to make target `clean'.  Stop.
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2

I don't know what is the minimal expected to be in "debian/rules" file.
I've read this:

https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules

But there isn't any example better or more complete than content I
already have:

|#!/usr/bin/make -f %: dh $@|

__
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 20/12/16 a les 16:59, Andrey Rahmatullin ha escrit:
> 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 debian
> branch and run dpkg-buildpackage, if you have an orig.tar ready. But to
> correctly make the orig.tar you'll need to use git archive and
> pristine-tar.
>

Re: Packaging from Git

[Narcis Garcia]

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 ntfsundelete-tree in control file but
not in files list
dpkg-genchanges: including full source code in upload
dpkg-genchanges: error: cannot fstat file ../ntfsundelete-tree: No such
file or directory
dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2

debian/files only content:
ntfsundelete-tree admin extra

The file "ntfsundelete-tree" is located at the base path (out of debian/)

__
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 17:40, Andrey Rahmatullin ha escrit:
> 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/rules" file.
>> I've read this:
>>
>> https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
> Start with reading https://www.debian.org/doc/manuals/maint-guide/
> 
>> But there isn't any example better or more complete than content I
>> already have:
>>
>> |#!/usr/bin/make -f %: dh $@|
> This should be three lines, not one. And your current d/rules contains 4
> spaces instead of a tab in the dh $@ line.
> 

Re: Packaging from Git

[Narcis Garcia]

__
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:
>> 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.
> 

Yes it does: avoids error messages. I don't understand the syntax is
possible to use there if I only want to install 1 file (ShellScript).

Re: Packaging from Git

[Narcis Garcia]

__
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:
>>>> 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.
>>>
>>
>> Yes it does: avoids error messages. 
> I hope you are kidding.
> 
>> I don't understand the syntax is possible to use there if I only want to
>> install 1 file (ShellScript).
> Just use the usual dh $@ syntax and use dh_install(1) to install your
> file.
> 

I'm not kidding. With the default dh $@ only line, outputs an error message.
I've tried not to append the command dh_install ntfsundelete-tree to
build: section and results the same.

I'm trying at least to get a successful end of dpkg-buildpackage,
although not installing anything, any file. First I want to avoid errors
(and warnings if possible), and next I'll try some useful action.

I don't find any "hello world" example to package a simple script.

Re: Packaging from Git

[Narcis Garcia]

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

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.


El 05/02/17 a les 11:22, Andrey Rahmatullin ha escrit:
> 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 a Makefile and it's useful to know the basic syntax of
> Makefiles).
> 
>> I've tried not to append the command dh_install ntfsundelete-tree to
>> build: section and results the same.
> You should use dh(1) instead of trying to write targets manually.
> 
>> I don't find any "hello world" example to package a simple script.
> That's because in the packaging world a hello world example is a software
> project with a proper and correctly written build system (in a simplest
> case that's a Makefile with all and install targets, the latter supporting
> $(DESTDIR)) and not just a file that the user is supposed to put into the
> file system manually. If you don't have a build system you need to do more
> work in the packaging system.
> 

Re: Packaging from Git

[Narcis Garcia]

__
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 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 from the 
> web
> interface
> 
> G.
> 

About executable attribute for files:
I'm trying to use only FOSS, not Github.
I'm currently not uploading files to Gitlab CMS through Git but I write
them directly through the web interface and editor.

Re: Packaging from Git

[Narcis Garcia]

__
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 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
> able to be able to contact distributors and not to hide them. 
> 
> Alex - Debian Listmaster
>  
> 

Mask and hide are two different measures.
A simple masking example, without hiding any data:
http://llista.gilug.org/pipermail/usuaris/2017-January/005484.html

Re: Packaging from Git

[Narcis Garcia]

__
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 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 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
>>> able to be able to contact distributors and not to hide them. 
>>>
>>> Alex - Debian Listmaster
>>>  
>>>
>>
>> Mask and hide are two different measures.
>> A simple masking example, without hiding any data:
>> http://llista.gilug.org/pipermail/usuaris/2017-January/005484.html
> I can show you a dozen libs that unmasks those things. 
> 
> Alex
>  
> 

Very far from the number of libs/tools that cannot unmask something like
Alexander Wirt formorer formorer de at anywhere of a page.

Cleaning packaging files with Lintian

[Narcis Garcia]

I have this error from Lintian output:
E: ntfsundelete-tree: maintainer-address-malformed Narcis Garcia


How can I better mask e-mail address in control file?

Thanks.
-- 


__
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.

Directories tree in package

[Narcis Garcia]

I'm currently building ntfsundelete-tree package with the main file
specified at debian/install:
ntfsundelete-tree usr/sbin

- If I specify more files by this way, will do APT uninstaller remove
empty directories of those files?
eg.:
icon.png usr/share/ntfsundelete-tree

- Is this specification compatible with RPM (when porting with Alien)?

- How to do for empty directories creation?
-- 


__
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.

binary-without-manpage

[Narcis Garcia]

I (only) created the file "debian/ntfsundelete-tree.8" (without
referring it anywhere), and I get this Lintian warning:
W: ntfsundelete-tree: binary-without-manpage usr/sbin/ntfsundelete-tree

Where do I need to register the manpage file presence to be installed?
Can I do this at "debian/install" file (with what well-known path)?


Thanks.
-- 


__
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.

copyright-contains-dh_make-todo-boilerplate

[Narcis Garcia]

This Lintian result is an error*:*
E: ntfsundelete-tree: copyright-contains-dh_make-todo-boilerplate

And I don't find any documentation about this message. This is the
copyright file:
https://git.actiu.net/libre/ntfsundelete-tree/blob/master/debian/copyright


-- 


__
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.

Re: copyright-contains-dh_make-todo-boilerplate

[Narcis Garcia]

Sorry; I used DuckDuckGo.
I had seen that page, but didn't identify which paragraphs is referred to.
Hilmar solution worked. Thanks.


__
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 09/02/17 a les 12:10, Andrey Rahmatullin ha escrit:
> On Thu, Feb 09, 2017 at 11:30:25AM +0100, Narcis Garcia wrote:
>> And I don't find any documentation about this message.
> lintian-info -t 
> 
> Or you could google it and find
> https://lintian.debian.org/tags/copyright-contains-dh_make-todo-boilerplate.html
> which is the same thing.
> 

Re: binary-without-manpage

[Narcis Garcia]

Thanks, I have now a clean Lintian result.
In documentation, some files seem to be optional, some simply required,
and some files or methods seem to be required only one of various (and
didn't see if one or all)

Let's see now if DFSG requires my program to be presented as current or
in a different way!


__
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 09/02/17 a les 12:10, Andrey Rahmatullin ha escrit:
> On Thu, Feb 09, 2017 at 10:26:02AM +0100, Narcis Garcia wrote:
>> I (only) created the file "debian/ntfsundelete-tree.8" (without
>> referring it anywhere), and I get this Lintian warning:
>> W: ntfsundelete-tree: binary-without-manpage usr/sbin/ntfsundelete-tree
>>
>> Where do I need to register the manpage file presence to be installed?
>> Can I do this at "debian/install" file (with what well-known path)?
> https://www.debian.org/doc/manuals/maint-guide/dother.html#manpages
> 

Re: copyright-contains-dh_make-todo-boilerplate

[Narcis Garcia]

__
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 09/02/17 a les 12:43, Andrey Rahmatullin ha escrit:
> On Thu, Feb 09, 2017 at 12:15:58PM +0100, Narcis Garcia wrote:
>> Sorry; I used DuckDuckGo.
>> I had seen that page, 
> Yet you said "I don't find any documentation about this message"
> 
> 
>> but didn't identify which paragraphs is referred to.
> The description mentions words "Please also look if..."
> 

My fault.
After not understanding that page explanations, I confused this case
with other rare undocumented messages, and didn't return to this page again.

ntfsundelete-tree for Debian

[Narcis Garcia]

Hello, how can I find somebody that can includes this software to Debian
official?

https://git.actiu.net/libre/ntfsundelete-tree

Thanks.

-- 


__
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.

Get current Standards-Version

[Narcis Garcia]

When checking files with Lintian, it shows:
W: ntfsundelete-tree source: out-of-date-standards-version 3.9.0
(current is 3.9.4)

Independently of what Lintian says, how can I detect Standards-Version
used in any Debian-like OS?

Thanks.

-- 


__
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.

Re: Get current Standards-Version

[Narcis Garcia]

__
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 16/02/17 a les 11:20, Gianfranco Costamagna ha escrit:
> Hello,
> 
>> W: ntfsundelete-tree source: out-of-date-standards-version 3.9.0
>> (current is 3.9.4)
> 
> 
> (this really depends on lintian version you are using, don't blindly trust 
> it!)
>> Independently of what Lintian says, how can I detect Standards-Version
>> used in any Debian-like OS?
> 
> 
> https://tracker.debian.org/pkg/debian-policy
> G.
> 

I've found now that lintian only looks version number with higher
datetime from:
/usr/share/lintian/data/standards-version/release-dates

Regards.

Re: Adding a new package to Debian

[Narcis Garcia]

Did you contact with Robert Luberda, the package maintainer for "super"?
Anyway, a more specific name should be better than "super", such as
"super-aa" or "android-analyzer".


__
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 16/02/17 a les 21:23, Iban Eguia ha escrit:
> Dear fellow members of the Debian mentoring community.
> 
> I am one of the maintainers of SUPER Android Analyzer
> , an application to check an Android APK
> application for vulnerabilities. The software has lots of potential and
> has been added to some software distributions. We recently received a
> request  for
> SUPER to be included in a Debian-based distribution, and even if we
> provide packages built for Debian, we noticed that there already was a
> package named `super` in the Debian repositories.
> 
> We first thought of changing our package name to something other than
> `super`, but we then noticed that the package had not been updated in
> more than 9 years, and we thought it would make sense to ask if it was
> possible to replace it in Debian by our package. As a summary, our
> package is written in Rust and currently requires java-jre as a
> dependency, since it also packages some Java projects we currently use
> for the analysis. All the project and dependencies we redistribute are
> licensed under GPLv3.
> 
> I am new to packaging, and I did't know where to ask, or if this was
> even possible, so I'm asking this in the mentoring list. Any help is
> much appreciated, thanks in advance.
> 
> Best regards,
> 
> Iban Eguia
> 
> 

Re: someone knows about https://archive.debian.net/

[Narcis Garcia]

__
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 22/04/17 a les 13:31, PICCORO McKAY Lenz ha escrit:
> 
> 2017-04-22 0:38 GMT-04:00 Paul Wise  >:
> 
> On Fri, Apr 21, 2017 at 10:02 PM, PICCORO McKAY Lenz wrote:
> 
> work on it. It is only for obsolete insecure Debian releases, we
> 
> the currrent debian "secure" "fashion" "modern" debian release DOES NOT
> FIT AND WORK ON MY MACHINE AND MANY MORE due does not have support for
> frame grabber capture devices REMOVED IN KERNEL 2.6.18
>  
> 
> strongly recommend you upgrade to a supported release and use
> 
> UPGRADE i'm tyred to hear about that .. and when people upgrade many
> thing "does not supported" but the hardware ARE GOOD AND WORKING WITH
> OLD RELEASE!
> 
> how stupid are feeling my people when grab a version and some note said
> "the devices X will not be supported due are older"...
> 
>  
> 
> packages.debian.org  instead. squeeze
> and lenny should *definitely* not
> be used any longer. What is blocking your upgrade to
> wheezy/jessie/stretch?
> 
> --
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise 
> 
> 

Please calm down Piccoro.
I also hope that snapshot.debian.org works for many time for this same
purpose, because some old machines can still be useful as they were
useful several years ago. Now i586-based computers will be unsupported
(it's ok) but I hope downloadable disks and repositories for versions
that cover i586 remain functional for many years in the future.

The purpose of a computer is not always to launch latest Firefox or run
a public web/mail server. A computer is often used for other old-fashion
tasks not vulnerable to attacks.
Not all people is "all day" thinking and working to defend themselves
from other's attacks, and for some people in the real world has much
more sense to reuse old hardware.

Re: someone knows about https://archive.debian.net/

[Narcis Garcia]

I've tried successfully to make a Debian 5 (Lenny) install and use this
repository:
http://snapshot.debian.org/archive/debian-archive/20160313T130328Z/debian/
lenny main

All works fine, as I suppose should work for any other version.


__
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 23/04/17 a les 14:44, PICCORO McKAY Lenz ha escrit:
> oh umm this are out of the main threat.. i want to use
> the archive.debian.net  interface, that's
> all, i only have help from someone to restore, but i refuse that u
> said.. u are wrong, at the moment o wheeze, ejabbed was many years
> outdated!!!
> 
> so if the problemof the out service was the certificate, common, provide
> a http nude way.. crackers, please, repositories are signed! and in case
> of pre-etch older systems dont use https as today!
> its the most common solution, easy, simple and withpout problem...
> 
> and, about ejabberd case: many users asked to contribute with packages,
> but well.. and in other words:
> 2017-04-23 4:30 GMT-04:00 Philipp Huebner  >:
> 
> I must protest! Have you checked the facts lately?
> 
> https://tracker.debian.org/pkg/ejabberd
> 
> 
> I have ported ejabberd 16.09 all the way back to Wheezy (via
> backports-sloppy).
> 
> so ok, lest see, its not in the main.. so most novice users not have
> that and not know.. 
> 
> well as suceded to me, i installed similar case bugreport from onther
> (not from main).. due are not in main.. bugreport are broken due if u
> install from backport deendences are not good property set:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859309#10
> 
> 
> and its not the only case, there's many many... 
> 
> 
> If you are running a public server on a Debian release older than
> Wheezy, that is a severe security problem to every participant on
> the net and should be shut down immediately.
> It's also totally your own fault then that you have only an ancient
> ejabberd version available. You cannot expect a current release of
> any software to be present in an obsolete Debian release.
> 
> it's nonsense said the outdated software are bad 
> 
> bad its the non-patched software.. the poor tested software, so dont
> said ilogic things...
> 
> so today systemd have two problems, two open bugs in debian track (now
> archived due no have solutions) such as example the killing process
> problem, this problem raised once again was switched... but anyway,
> debian swict event contrubute to the effors of the other proyects..
> systemd was poor tested.. but most ditribution was swichted..
> 
> please how we can trust in software with some "dirty" practices, like
> merge udev to force usage of systemd? i remenber the problem.. but here
> we are---
> 
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
> 
> 2017-04-23 4:30 GMT-04:00 Philipp Huebner  >:
> 
> Hi
> 
> Am 22.04.2017 um 16:35 schrieb PICCORO McKAY Lenz:
> [...]
> 
> debian have many out (very out) to date packages like ejabberd..
> and u
> tell me about "security" please! theres a issue related to slim,
> due bad
> integrtion with pam and systemd, see it
> 
> [...]
> 
> debian have many out (very out) to date packages like ejabberd..
> and u
> tell me about "security" please!
> 
> 
> 
> I must protest! Have you checked the facts lately?
> 
> https://tracker.debian.org/pkg/ejabberd
> 
> 
> I have ported ejabberd 16.09 all the way back to Wheezy (via
> backports-sloppy).
> 
> ejabberd 16.09 is the latest release before a series of major code
> refactorings introducing a ton of new bugs and regressions.
> It is still quite a recent release which can be configured to be
> 100% compliant with current XMPP compliance suites (XEP-0387).
> 
> ejabberd 17.04 is already available in experimental and will be
> available for Jessie and Stretch once stretch-backports and
> jessie-backports-sloppy are open.
> 
> If you are running a public server on a Debian release older than
> Wheezy, that is a severe security problem to every participant on
> the net and should be shut down immediately.
> It's also totally your own fault then that you have only an ancient
> ejabberd version available. You cannot expect a current release of
> any software to be present in an obsolete Debian release.
> 
> Regards,
> -- 
>  .''`.   Philipp Huebner  >
> : :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
> `. `'`
>   `-
> 
> 

Snapshot... ISOs?

[Narcis Garcia]

I'm looking for some ancient versions to be installed from bootable
disc/CD/etc.:

3.0 woody
2.1 slink
2.0 hamm
1.3 bo
1.2 rex
1.1 buzz

Does anybody where can I download installable ISOs from?


[The purpose is to compare packages versions & dependencies evolution]

-- 


__
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.

Re: Snapshot... ISOs?

[Narcis Garcia]

__
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 24/04/17 a les 09:09, Andrey Rahmatullin ha escrit:
> On Mon, Apr 24, 2017 at 09:04:42AM +0200, Narcis Garcia wrote:
>> I'm looking for some ancient versions to be installed from bootable
>> disc/CD/etc.:
>>
>> 3.0 woody
>> 2.1 slink
>> 2.0 hamm
>> 1.3 bo
>> 1.2 rex
>> 1.1 buzz
>>
>> Does anybody where can I download installable ISOs from?
> http://cdimage.debian.org/cdimage/archive/
> http://cdimage.debian.org/cdimage/archive/older-contrib/
> 

Thanks;
With 3.0 and 3.1 versions I'm trying now to make use of "jigdo" tool to
recompose ISO files uting a snapshot.debian.org "mirror".

Re: Snapshot... ISOs?

[Narcis Garcia]

__
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 24/04/17 a les 09:09, Andrey Rahmatullin ha escrit:
> On Mon, Apr 24, 2017 at 09:04:42AM +0200, Narcis Garcia wrote:
>> I'm looking for some ancient versions to be installed from bootable
>> disc/CD/etc.:
>>
>> 3.0 woody
>> 2.1 slink
>> 2.0 hamm
>> 1.3 bo
>> 1.2 rex
>> 1.1 buzz
>>
>> Does anybody where can I download installable ISOs from?
> http://cdimage.debian.org/cdimage/archive/
> http://cdimage.debian.org/cdimage/archive/older-contrib/
> 

Here:
http://cdimage.debian.org/cdimage/archive/older-contrib/2.2/
lacks of a file I have: debian-2.2-i386-cd4-non-us.iso

Re: Snapshot... ISOs?

[Narcis Garcia]

El 24/04/17 a les 10:05, Narcis Garcia ha escrit:
> __
> 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 24/04/17 a les 09:09, Andrey Rahmatullin ha escrit:
>> On Mon, Apr 24, 2017 at 09:04:42AM +0200, Narcis Garcia wrote:
>>> I'm looking for some ancient versions to be installed from bootable
>>> disc/CD/etc.:
>>>
>>> 3.0 woody
>>> 2.1 slink
>>> 2.0 hamm
>>> 1.3 bo
>>> 1.2 rex
>>> 1.1 buzz
>>>
>>> Does anybody where can I download installable ISOs from?
>> http://cdimage.debian.org/cdimage/archive/
>> http://cdimage.debian.org/cdimage/archive/older-contrib/
>>
> 
> Thanks;
> With 3.0 and 3.1 versions I'm trying now to make use of "jigdo" tool to
> recompose ISO files uting a snapshot.debian.org "mirror".
> 

On woody-i386-1_NONUS (3.0_r0)
"Aaargh - 345 files could not be downloaded"

On woody-i386-7 (3.0_r0)
"Aaargh - 53 files could not be downloaded..."

On woody-i386-6 (3.0_r0)
"Aaargh - 38 files could not be downloaded..."

On woody-i386-5 (3.0_r0)
"Aaargh - 57 files could not be downloaded..."

On woody-i386-4 (3.0_r0)
"Aaargh - 52 files could not be downloaded..."

On woody-i386-3 (3.0_r0)
"Aaargh - 61 files could not be downloaded..."

On woody-i386-2 (3.0_r0)
"Aaargh - 78 files could not be downloaded..."

On woody-i386-1 (3.0_r0)
"Aaargh - 131 files could not be downloaded..."

... No problem with debian-30r6-dvd-i386-binary-1_NONUS.iso because it
was the simple file downloadable (no jigdo/torrent).

Fwd: TAG: durruter -- NAT/PAT routing helper

[Narcis Garcia]

https://bugs.debian.org/863487


 Missatge reenviat 
Assumpte: TAG: durruter -- NAT/PAT routing helper
Data: Sat, 27 May 2017 19:04:13 +0200
De: Narcis Garcia 
A: sub...@bugs.debian.org

Package: wnpp
Severity: ITP
Copyright: (GNU GPL) 2012-2017 Narcis Garcia

Dear mentors,
I am looking for a sponsor for my package "durruter"

Durruter is a command-line wizard to manage iptables entries like in a
hardware router web interface. Forward ports and ranges from multiple
interfaces, allow internet traffic from multiple nets to multiple
network interfaces.

Works with Debian GNU/Linux since 3.1 upto 9.0

Complete information and personal sources & packages repository:
https://www.actiu.net/durruter/

Thanks for your consideration.

Re: Fwd: TAG: durruter -- NAT/PAT routing helper

[Narcis Garcia]

__
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 28/05/17 a les 13:18, Andrew Shadura ha escrit:
> Control: retitle -1 RFP: durruter -- NAT/PAT routing helper
> 
> On 28/05/17 13:14, Andrew Shadura wrote:
>> On 27/05/17 22:24, Narcis Garcia wrote:
>>> Dear mentors,
>>> I am looking for a sponsor for my package "durruter"
>>>
>>> Durruter is a command-line wizard to manage iptables entries like in a
>>> hardware router web interface. Forward ports and ranges from multiple
>>> interfaces, allow internet traffic from multiple nets to multiple
>>> network interfaces.
>>>
>>> Works with Debian GNU/Linux since 3.1 upto 9.0
>>>
>>> Complete information and personal sources & packages repository:
>>> https://www.actiu.net/durruter/
>>>
>>> Thanks for your consideration.
>>
>> I think you slightly misunderstood what the sponsorship is about. You're
>> supposed to present a near-ready source package you think is ready to be
>> uploaded to Debian unstable. Then your package goes through a review
>> process, you improve it if needed, and then the sponsor uploads it when
>> you both agree no further improvement is needed at the moment.
> 
> So far this doesn't look like a sponsorship request, but a request for
> packaging. I’m thus retitling the bug to match that.
> 
> Should you be interested in going through the process I have described
> above, change this bug into an ITP (Intent to Package), prepare the
> package and file another bug, a request for sponsorship (RFS) so that
> your packaging is reviewed and potentially uploaded.
> 

Thanks for fixing this; I read Debian wiki references but I still not
understand what's exactly the different task between a sponsor (TAG/ITP)
and a packager~uploader (RFP).
Who can I resquest now to re/package and upload to unstable repository?

Re: TAG: durruter -- NAT/PAT routing helper

[Narcis Garcia]

__
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 28/05/17 a les 22:18, Arturo Borrero Gonzalez ha escrit:
> On 27 May 2017 at 22:24, Narcis Garcia  wrote:
>>
>> Durruter is a command-line wizard to manage iptables entries like in a
>> hardware router web interface. Forward ports and ranges from multiple
>> interfaces, allow internet traffic from multiple nets to multiple
>> network interfaces.
> 
> Hi Narcis,
> 
> I already replied to you in private about this.
> 
> I would rather base this software in nftables than in iptables.
> 
> Note that iptables is being replaced by nftables: a new, modern technology.
> 

nftables is too complicated to be scriptable (how to analyze listings?).
If you try Durruter, you'll see that it walks in opposite direction than
nftables: simple tool for simple administration.

Durruter is like a clone of consumer's router interface (web interface)
to forward TCP/UDP ports.

Depends xxx <- Version: 3:20161105-1

[Narcis Garcia]

Hello, I'm trying to build a package that depends on another one
(iputils-ping), but the other's version in Debian is marked with a
notation I don't know:
3:20161105-1

- Which is this software's version? 3?
- What is the best formula for "control" file in my new package, having
present that any version is useful for me since 3:20020927 from
Debian-Sarge or older if there was?

Depends: iputils-ping (>= 3)
Depends: iputils-ping (>= 20020927)
Depends: iputils-ping (>= 3:20020927)

Thanks.
-- 


__
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.

Re: Depends xxx <- Version: 3:20161105-1

[Narcis Garcia]

__
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 09/06/17 a les 14:01, James Cowgill ha escrit:
> Hi,
> 
> On 09/06/17 12:54, Narcis Garcia wrote:
>> Hello, I'm trying to build a package that depends on another one
>> (iputils-ping), but the other's version in Debian is marked with a
>> notation I don't know:
>> 3:20161105-1
>>
>> - Which is this software's version? 3?
> 
> This is documented in debian-policy:
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
> 
> The upstream version is "20161105". The epoch is "3" and is used to
> change the version scheme at a later date.
> 
>> - What is the best formula for "control" file in my new package, having
>> present that any version is useful for me since 3:20020927 from
>> Debian-Sarge or older if there was?
>>
>> Depends: iputils-ping (>= 3)
>> Depends: iputils-ping (>= 20020927)
>> Depends: iputils-ping (>= 3:20020927)
> 
> The last one is the only one which will do what you want. However, it's
> not worth it to specify dependency versions which only matter for
> prehistoric Debian releases, so the best thing to do would just be:
> 
> Depends: iputils-ping
> 
> Thanks,
> James
> 

Okay, I didn't want that this lintian error affected Depends and/or
Recommends too:
https://lintian.debian.org/tags/depends-on-build-essential-package-without-using-version.html

RFP/RFS: vinca -- Reverse VNC for remote support

[Narcis Garcia]

https://bugs.debian.org/865583


 Missatge reenviat 
Assumpte: RFP: vinca -- Reverse VNC for remote support
Data: Thu, 22 Jun 2017 23:39:02 +0200
De: Narcis Garcia 
A: sub...@bugs.debian.org

Package: wnpp
Severity: RFP
Copyright: (GNU GPL) 2008-2017 Narcis Garcia

Dear mentors,
I am looking for a sponsor to upload my package "vinca"

You can publish the utility to be downloaded and executed by people who
you want to assist to (or your customers). Vinca will care of searching
and installing VNC requirements to launch immediately a connection to
your public IP or name.

Works with Debian GNU/Linux since 3.1 upto 9.0

Complete information and personal sources & packages repository:
https://www.actiu.net/vinca/

Thanks for your consideration.

Re: RFP: vinca -- Reverse VNC for remote support

[Narcis Garcia]

I'm understanding the "package it by yourself", if it only means to
publish somewhere a .deb package or it's related to doing this in some
Debian host.
If it's the first, the project has already a public binaries repository
(at repos.actiu.net/libre).

I suspect I need to be a maintainer if I want to offer this package to
Debian repositories.

Another topic: Why is this bug closed (done)?
https://bugs.debian.org/865583


__
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 23/06/17 a les 12:05, Gianfranco Costamagna ha escrit:
> 
>> Assumpte: RFP: vinca -- Reverse VNC for remote support
> 
> 
> this is an RFP, not RFS, so please try to persuade somebody
> maybe on -devel to package it, if you really think this is an important tool.
> 
> Otherwise package it by yourself and convert/open a real RFS bug.
> 
> Mentors is about helping people becoming maintainers, not for doing
> the packaging work :)
> 
> G.
> 

installing GUI launchers and mimes

[Narcis Garcia]

I'm observing how is transmission-gtk packaged and it seems that it's
not enough with including files as
./usr/share/applications/xxx.desktop
./usr/share/mime/packages/xxx.xml

but postinst script should run update-menus and update-mime (or
update-mime-database) if available.
It seems also that there are (or were) some need to write profiles as
/usr/share/menu/PackageName
/usr/lib/mime/packages/PackageName
(time ago the first was at /usr/lib/menu/) to be located by update-menus
program.

Packaging my program, how can I deal better with this, in most
compatible way as possible (with other distros and with old Debian
versions)?

[Note that I write my own postinst script]
-- 


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: installing GUI launchers and mimes

[Narcis Garcia]

A question about my way before packaging: Is a good practice to use this
in postinst script?

echo "..." > /tmp/MyType.xml
xdg-mime install --mode system /tmp/MyType.xml
echo "..." > /tmp/My-Program.desktop
xdg-desktop-menu install --mode system /tmp/My-Program.desktop


El 30/07/17 a les 10:30, Narcis Garcia ha escrit:
> I'm observing how is transmission-gtk packaged and it seems that it's
> not enough with including files as
> ./usr/share/applications/xxx.desktop
> ./usr/share/mime/packages/xxx.xml
> 
> but postinst script should run update-menus and update-mime (or
> update-mime-database) if available.
> It seems also that there are (or were) some need to write profiles as
> /usr/share/menu/PackageName
> /usr/lib/mime/packages/PackageName
> (time ago the first was at /usr/lib/menu/) to be located by update-menus
> program.
> 
> Packaging my program, how can I deal better with this, in most
> compatible way as possible (with other distros and with old Debian
> versions)?
> 
> [Note that I write my own postinst script]
> 

Re: installing GUI launchers and mimes

[Narcis Garcia]

El 30/07/17 a les 10:52, Andrey Rahmatullin ha escrit:
> On Sun, Jul 30, 2017 at 10:30:46AM +0200, Narcis Garcia wrote:
>> I'm observing how is transmission-gtk packaged and it seems that it's
>> not enough with including files as
>> ./usr/share/applications/xxx.desktop
>> ./usr/share/mime/packages/xxx.xml
>>
>> but postinst script should run update-menus and update-mime (or
>> update-mime-database) if available.
> update-menus is only for the menu files, not for desktop files.
> update-mime and update-mime-database are run via triggers, not maintainer
> scripts.
> 

Do you mean that with only having at the package:
./usr/share/applications/xxx.desktop
./usr/share/mime/packages/xxx.xml
triggers are automatically run?

With xdg-desktop-menu x.desktop the Categories variable altready
determines menu placement. Without this command, triggers already update
the menu?

Why transmission-gtk/postinst calls update-menus and update-mime ? Is it
some kind of compatibility measure?

Thanks.

Re: installing GUI launchers and mimes

[Narcis Garcia]

__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 31/07/17 a les 03:23, Charles Plessy ha escrit:
> Le Sun, Jul 30, 2017 at 11:55:20AM +0200, Narcis Garcia a écrit :
>>
>> Do you mean that with only having at the package:
>> ./usr/share/applications/xxx.desktop
>> ./usr/share/mime/packages/xxx.xml
>> triggers are automatically run?
> 
> Hello Narcis,
> 
> yes they will:
> 
>   $ grep usr/share/applications /var/lib/dpkg/triggers/File 
>   /usr/share/applications mime-support/noawait
>   /usr/share/applications desktop-file-utils
>   /usr/share/applications gnome-menus/noawait
> 
>   $ grep usr/share/mime/packages /var/lib/dpkg/triggers/File 
>   /usr/share/mime/packages shared-mime-info
> 
> See /usr/share/doc/dpkg-dev/triggers.txt.gz for (a lot of) details.
> 
>> Why transmission-gtk/postinst calls update-menus and update-mime ? Is it
>> some kind of compatibility measure?
> 
> The short answer is: "because transmission-gtk/postinst is generated by 
> debhelper
> fia dh_installmenu".
> 
>   $ cat /var/lib/dpkg/info/transmission-gtk.postinst
>   #!/bin/sh
>   set -e
>   # Automatically added by dh_installmenu
>   if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ]; 
> then
>   update-menus
>   fi
> 
> I am not sure why this is still needed while there is already a dpkg trigger
> doing the work.
> 
> Anyway, as noted elsewhere, the Debian menu system is being phased out.
> 
> Have a nice day,
> 

Thanks, this is really useful information.
I suppose "Debian menu system" is not the same as what xdg-desktop-menu
manages (?) because it currently works perfectly to manually install any
launcher on any desktop on any distro.

Re: installing GUI launchers and mimes

[Narcis Garcia]

__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 31/07/17 a les 03:23, Charles Plessy ha escrit:
> Le Sun, Jul 30, 2017 at 11:55:20AM +0200, Narcis Garcia a écrit :
>>
>> Do you mean that with only having at the package:
>> ./usr/share/applications/xxx.desktop
>> ./usr/share/mime/packages/xxx.xml
>> triggers are automatically run?
> 
> Hello Narcis,
> 
> yes they will:
> 
>   $ grep usr/share/applications /var/lib/dpkg/triggers/File 
>   /usr/share/applications mime-support/noawait
>   /usr/share/applications desktop-file-utils
>   /usr/share/applications gnome-menus/noawait
> 
>   $ grep usr/share/mime/packages /var/lib/dpkg/triggers/File 
>   /usr/share/mime/packages shared-mime-info
> 
> See /usr/share/doc/dpkg-dev/triggers.txt.gz for (a lot of) details.
> 

When no trigger seem to be in the system (I'm thinkng on other or older
distros), I'll try to use these two commands in postinst:
update-desktop-database
update-mime-database /usr/share/mime

I suppose these will cover most cases for this and other programs:
https://git.actiu.net/libre/xhash

Re: installing GUI launchers and mimes

[Narcis Garcia]

At user level there is this command to set an application as default for
a file type:
$ xdg-mime default MyProgram.desktop my/type
(not useful for system wide action)

System wide defaults I see that are registered at some of these files:
/usr/share/applications/mimeapps.list
/usr/share/applications/defaults.list
/usr/local/share/applications/mimeapps.list
/usr/local/share/applications/defaults.list

Is there a better way to setup this than writing directly to one of
these files?

Re: "License": public-domain

[Narcis Garcia]

In my humble opinion, Lintian should mark a warning when detecting this.
This could make some developers and/or packagers to reconsider chosen
license.




__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 13/09/17 a les 17:46, Don Armstrong ha escrit:
> On Wed, 13 Sep 2017, Nico Schlömer wrote:
>> I sometimes see in d/copyright
>>
>>> Copyright: John Doe
>>> License: public-domain
>>
>> e.g., [1]. However, these two statements contradict each other: public
>> domain means exactly the _absence_ of copyright [2].
> 
> The Copyright: field in this case is usually indicating who holds any
> residual copyright or author's rights in a jurisdiction which does not
> completely support public domain (PD). It also indicates who the
> individual was who dedicated the work to the PD.
> 
>> Specifically, public domain is _not_ open source [3].
> 
> PD works are not necessarily open source in all jurisdictions, but they
> can satisfy the DFSG in many.
> 
>> Since Debian is usually quite careful when it comes to legal issues,
>> I'm wondering what the official view point is here.
> 
> The official viewpoint is that the software must meet the requirements
> of the DFSG. Generally, a CC0-style PD dedication is viewed as
> sufficient for all jurisdictions, and can satisfy the DFSG if source is
> available.
> 
> Finally, I'm unaware of a case where a jurisdiction has upheld a
> copyright claim to a work which has been dedicated to the public domain
> everywhere. This is a potential theoretical source of problems, but
> there's enough actual problems with copyright and licensing for us to
> concentrate our limited time on them instead.
> 
>> Should there be a lintian error if the "license" is public domain and
>> a copyright holder is specified?
> 
> No.
> 
>> Should "public-domain" perhaps be prohibited in general?
> 
> Definitely not.
> 
> 

Re: Package recommended and upgrade/dist-upgrade

[Narcis Garcia]

As Far As I Know: Not by default behaviour, but you can configure.

APT parameter to override this: --with-new-pkgs
Directive for /etc/apt/apt.conf : APT::Get::Upgrade-Allow-New



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 17/10/17 a les 19:55, Alex ARNAUD ha escrit:
> Dear all,
> 
> I'm one of the maintainers of a downstream Debian repository.
> We install a meta-package to install the most part of the package from
> the repository.
> Most of the users would like to be able to uninstall packages that are
> not fully required without uninstalling the meta-package.
> 
> I've seen that it is possible to mark package as "recommended" so it
> will be installed at the first installation.
> 
> If I mark a new package as recommended on a new release, does this
> package will be installed on upgrade on the user system ?
> Otherwise, is there a way to install a new package on upgrades that
> could be remove by the user without to uninstall the package that
> recommends it ?
> 
> Best regards.

Re: I want to get started in open source/free software

[Narcis Garcia]

GnuZilla/Icecat is a software that many people expects to be packaged
for Debian:
https://bugs.debian.org/637348


El 10/03/18 a les 09:21, mitch ha escrit:
> I have some spare time and an interest in development but not much
> experience. I do know basic c and have a degree in IST. I have a dated
> book Debain System by martin f. kraft. I'm somewhat interested in trying
> to package and maintain a program called gnaural. I don't know if its
> still being actively developed but might have an interest in programming
> for it. I believe it has a gpl license. Would this be a good project? If
> not I'm open to trying to tackle something in the list maintained by
> debian.
> 

Re: I want to get started in open source/free software

[Narcis Garcia]

El 10/03/18 a les 09:51, Andrey Rahmatullin ha escrit:
> On Sat, Mar 10, 2018 at 09:26:53AM +0100, Narcis Garcia wrote:
>> GnuZilla/Icecat is a software that many people expects to be packaged
>> for Debian:
>> https://bugs.debian.org/637348
> I wouldn't recommend packaging Mozilla software for someone inexperienced.
> Also, packaging yet another firefox but with some defaults changed for
> arguably political reasons may not be a good idea at all.
> And please don't top-post.
> 

Where are defaults for Mozilla Firefox decided before Debian packaging?
M.Firefox behaviour about privacy and security is not a small matter.



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: How can i make my innovative software a part of debian project ?

[Narcis Garcia]

This can be helpful for you:
https://mentors.debian.net/intro-maintainers

El 21/03/18 a les 13:15, Erkam Murat Bozkurt ha escrit:
> I have developed a new software as a result of a scientific research and
> a want to share my study as an open-source software. This software
> offers a new and useful method for C/C++ multi-thread computing. More
> specificity, it acts as an autonomous management system for the thread
> synchronization tasks. Not surprisingly, application development with
> the this software is much more easy than classical C/C++ threading
> libraries thanks to the its autonomous management system. This software
> also includes a nice and useful GUI (Graphical User Interface ) and
> therefore, it is easy to use.
> 
> 
> The copyright application for the software has been performed in 12
> March 2018 to US copyright office and the software is ready to use. I
> have developed this software in order to prove my coding skills and I
> want to ask you that how can i make my own software a part of the debian
> project. Finally, I want to publish my software with BCD -3 clause
> license. Is this license proper for the debian system ?
> 
> 
> Thank you for your interest and best regards.
> 
> Erkam Murat Bozkurt
> 
> M.Sc in Control Systems Engineering
> 
> 

Re: Need to manage my incoming

[Narcis Garcia]

El 27/03/18 a les 13:29, Mel Mac ha escrit:
> I need guidance with appxmanifest ?
> 

$ apt-cache search appx
libwordnet-querydata-perl - Perl interface to WordNet database