Re: compiled binary file in source package
On 10.02.2018 00:43, Ben Finney wrote: > David Rabel <david.ra...@noresoft.com> writes: >> On 09.02.2018 00:44, Ben Finney wrote: >>> Is the compiled binary file generated entirely from sources that are >>> all in the upstream source distribution? >> >> Yes, it's genereated from the sources. Allthough I cannot technically >> verify that. > > That will be a necessary part of the Debian packaging work: you'll need > to ensure the build process of the work from its source, in a way that > others can also replicate from your packaging. > > In other words: When you omit the bundled file from the source package, > and re-generate the equivalent from the source files, that will > demonstrate whether or not there are significant differences in the > original bundled file. > The binary in the source package does not equal the binary I generate when building the package 'bit for bit'. Still I don't really think that the upstream put any different binary inside the package. But since I cannot verify it (or it's not worth the effort), I just want to delete the binary. >>> Is the compiled binary file needed at all — can it be removed without >>> detriment for generating the Debian package from source? >> >> It can be removed, yes. It is recompiled during the build processs >> anyways. > > Do you know that the file is re-compiled from entirely DFSG-compliant > source? > Yes. > If the answer is no, then (that part of) the work is not free software, > so removing it would justify a ‘+dfsg.1’ suffix on the re-packed source. > > If the answer is yes, and there are no other DFSG problems, the > re-packed source should probably get ‘+ds.1’ suffix. > Thanks. I will use +ds.1 then. David signature.asc Description: OpenPGP digital signature
Re: compiled binary file in source package
On 09.02.2018 00:44, Ben Finney wrote: > David Rabel <david.ra...@noresoft.com> writes: > >> I am maintaining jugglinglab. The upstream source package contains a >> compiled binary file. What is the cleanest solution to get rid of it? > > Is the compiled binary file generated entirely from sources that are all > in the upstream source distribution? Yes, it's genereated from the sources. Allthough I cannot technically verify that. > Is the compiled binary file needed at all — can it be removed without > detriment for generating the Debian package from source? It can be removed, yes. It is recompiled during the build processs anyways. > Probably the best option is to re-pack the source to exclude that file > <URL:https://pkg-perl.alioth.debian.org/howto/repacking.html>. Yes, that's sounds good. Which suffix is best-fitting? +dfsg ? I'm uncertain, since the file is very probably free software. I just don't want to have precomiled binary files inside the source package. David signature.asc Description: OpenPGP digital signature
piuparts - installation and purging test
Hi there, I am maintaining vim-lastplace. A few days ago I saw on my Debian Maintainer Dashboard that piuparts was failing at the installation and purging test. Today I wanted to fix this, but the message was gone. So piuparts now succeeds on piuparts.d.o . But when I run piuparts on my local machine, it still fails at the installation and purging test. I had a look at the test and have no idea what it fails. Are there any known issues like that? Yours David signature.asc Description: OpenPGP digital signature
compiled binary file in source package
Hi there, I am maintaining jugglinglab. The upstream source package contains a compiled binary file. What is the cleanest solution to get rid of it? Story behind that: When I started packaging jugglinglab in 2016 I just deleted the file with a patch. This is unclean and for example sbuild refuses to build the package, because it does a dh_clean before which also deletes the binary and then complains that the patch cannot delete a file that isn't there. But back then I was in contact with the upstream maintainer and hoping that he would just delete the file, so I could get rid of that workaround. But he suddenly stopped answering my emails. So, after more than a year, I think he won't answer. So I have to come up with another solution. I just don't have an idea, what is the best way to do that. Can you help me? Yours David signature.asc Description: OpenPGP digital signature
Re: Packaging for Debian with different gpg-keys and emali-addresses
On 01.03.2017 00:18, Ben Finney wrote: > David Rabel <ra...@b1-systems.de> 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 do Debian packaging with different gpg keys and email >> addresses? And how would I do it? > > Different from what? Sorry, the meaning was lost in translation. ;) "Different" seems to be the wrong word here. "Various" fits better, I think. > Can you explain with an example of what the different things would be, > and what you'd use them for? I am already packaging with my private key / email: david.ra...@noresoft.com [0] Now I wanted to also do some packaging with this key / email, because I do not have access to my private key / email from this computer: ra...@b1-systems.de And of course I would like to do this as one "identity" in Debian, having only one QA page and so on. Yours David [0] https://qa.debian.org/developer.php?login=david.rabel%40noresoft.com=yes -- David Rabel Linux Consultant & Trainer Tel.: +49-1511-5908566 Mail: ra...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Packaging for Debian with different gpg-keys and emali-addresses
Hi there, is it possible to do Debian packaging with different gpg keys and email addresses? And how would I do it? Yours David PS: Please CC me, if you answer to this mail, as I am subscribed to Debian mentors anymore. -- David Rabel Linux Consultant & Trainer Tel.: +49-1511-5908566 Mail: ra...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Bug#833105: RFS: vim-lastplace/3.0.2-1 [ITP]
Hi, On 02.08.2016 08:40, Gianfranco Costamagna wrote: > I fully agree here, just a few questions about *where* to put this package. > http://www.vim.org/scripts/ > I think I don't understand. > what about adding it as a patch to the current vim-scripts package? > https://packages.qa.debian.org/v/vim-scripts.html > > you might want to join the team and ask to comaintain it here maybe > Yes, this also came to my mind and I asked about it on their mailing list. James McCoy answered: "Individual packages are fine. Given the current state of vim-scripts, that's probably better. I've been delaying updating vim-scripts because of various problems in vim-addon-manager that I know will be encountered if those scripts are updated. I need to get vim-addon-manager fixed first." [1] So, I am not sure. Maybe it is an option to add it to vim-scripts once James has reworked vim-addon-manager and vim-scripts. Cheers, David [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825665#26 signature.asc Description: OpenPGP digital signature
Bug#833105: RFS: vim-lastplace/3.0.2-1 [ITP]
Hi, On 01.08.2016 22:35, Gianfranco Costamagna wrote: > it is good, just called "3.0.2-2" > > please use -1 as versioning and dput -f on mentors until it gets accepted. > Ah ok, sorry. :-) I removed the package and uploaded it again as 3.0.2-1 . > last thing: how do I enable such extension? In the vim-policy[1] by the vim package team they recommend to use vim-addon-manager. That means, install the debian package vim-addon-manager (which is recommended by the vim-lastplace package) and then execute "vim-addons install lastplace" . This copies the appropriate files from /usr/share/vim/addons/ to ~/.vim/ for that user. There is also a way to "activate" an addon system wide via "vim-addons -w install lastplace", which copies the files to /var/lib/vim/addons . This seems to be a little inconvenient, but with multiple addons installed and multiple users of which everyone wants to configure which addon to use, it is probably the cleanest solution. I have seen that for example the vim-tabular package handles this via preinst and postinst scripts to "activate" the addon system-wide by default. The user can still disable it by "vim-addons disable vim-tabular". Handling it this way is however discouraged by [1]. But maybe in our case it makes sense to do it like this as well. Because if someone installs a package with exactly one vim addon he or she probably wants it to be enabled by default. (Unlike for example when installing the package vim-scripts, which contains multiple vim addons.) But in the Debian New Maintainers' Guide they say "As a novice maintainer, you should avoid any manual editing of maintainer scripts because they are problematic.", so maybe it is good as it is right now. :-D Regards, David [1] https://pkg-vim.alioth.debian.org/vim-policy.txt signature.asc Description: OpenPGP digital signature
Bug#833105: RFS: vim-lastplace/3.0.2-1 [ITP]
Hi Gianfranco, On 01.08.2016 10:38, Gianfranco Costamagna wrote: > 1) please use for debian copyright the same license as upstream if possible > > (this makes easier to forward patches) Done. > > 2) I'm not sure about the directories and installation path > > │ ├── vim-lastplace > │ │ ├── DEBIAN > │ │ │ ├── control > │ │ │ └── md5sums > │ │ └── usr > │ │ └── share > │ │ ├── doc > │ │ │ └── vim-lastplace > │ │ │ ├── changelog.Debian.gz > │ │ │ ├── copyright > │ │ │ ├── README.Debian > │ │ │ └── README.md > │ │ └── vim > │ │ ├── addons > │ │ │ ├── doc > │ │ │ │ └── lastplace.txt > │ │ │ │ └── vim-lastplace.txt > │ │ │ └── plugin > │ │ │ └── lastplace.vim > │ │ │ └── vim-lastplace.vim > │ │ └── registry > │ │ └── vim-lastplace.yaml > You are right, this was wrong (although it worked somehow). I wanted to copy and rename vim-lastplace.txt and vim-lastplace.vim to lastplace.txt and lastplace.vim and not too create another subfolder. I fixed this by using dh-exec now (which I found in the man page of dh_install). Is this what you meant? > > apt-get install check-all-the-things > > # check if these can be switched to https:// > $ grep -rF http: . > I was able to change all but vim.org . I created a patch for this with dquilt. I wrote an email to the people behind vim.org to ask if there is really no https version accessible. And if so if they are planning to change that. > > I will probably enjoy the package if you can fix/look at the above! > Thank you very much! That would be great. :-) I uploaded a new revision of the package to mentors.debian.net, hopefully fixing all the issues. Regards, David signature.asc Description: OpenPGP digital signature
Bug#833105: RFS: vim-lastplace/3.0.2-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "vim-lastplace" * Package name: vim-lastplace Version : 3.0.2-1 Upstream Author : Greg Dietsche * URL : https://github.com/dietsche/vim-lastplace * License : MIT Section : editors It builds those binary packages: vim-lastplace - Vim script to reopen files at your last edit position To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vim-lastplace Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vim-lastplace/vim- lastplace_3.0.2-1.dsc More information about vim-lastplace can be obtained from https://mentors.debian.net/package/vim-lastplace. Changes since the last upload: * Initial release (Closes: #825665) Regards, David Rabel
