Bug#782074: RFS: ublock/0.9.3.0-1 [ITP] -- general-purpose lightweight ads, malware, trackers blocker
I packaged version 0.9.5.0 which can be downloaded here: http://mentors.debian.net/debian/pool/main/u/ublock/ublock_0.9.5.0+dfsg1-1.dsc
Bug#782074: RFS: ublock/0.9.3.0-1 [ITP] -- general-purpose lightweight ads, malware, trackers blocker
Hi, You should probably use the RFS template on mentors, found here: http://mentors.debian.net/sponsors/rfs-howto/ublock Thanks, Thomas On 24/08/15 09:53 AM, Matthew Bekkema wrote: I packaged version 0.9.5.0 which can be downloaded here: http://mentors.debian.net/debian/pool/main/u/ublock/ublock_0.9.5.0+dfsg1-1.dsc signature.asc Description: OpenPGP digital signature
Bug#796395: marked as done (RFS: rolldice/1.14-1 ITA)
Your message dated Mon, 24 Aug 2015 17:38:43 +0100 with message-id 1440434323.79280.bpmail_high_carr...@web171804.mail.ir2.yahoo.com and subject line Re: Bug#796395: RFS: rolldice/1.14-1 ITA has caused the Debian Bug report #796395, regarding RFS: rolldice/1.14-1 ITA to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 796395: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796395 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package rolldice * Package name: rolldice Version : 1.14-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : games It builds those binary packages: rolldice - virtual dice roller To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rolldice Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rolldice/rolldice_1.14-1.dsc More information about rolldice can be obtained from https://github.com/sstrickl/rolldice Changes since the last upload: rolldice (1.14-1) unstable; urgency=medium * New upstream release (Closes: #74583, #672418) * Removed patch 01_remove_strip.diff - fixed upstream * Removed patch debian-changes-1.10-5 * Don't timestamp the man page * debian/control - Bump standards-version to 3.9.6 - Removed quilt from build-depends - Added libreadline-dev to build-depends - Updated homepage - New maintainer (Closes: #784189)) - Removed article from short description * debian/rules - Remove 'dh_clean -k' in favor of 'dh_prep' - Hardened executables - Add build-arch and build-indep targets -- Thomas Ross th0m4sr...@gmail.com Thu, 20 Aug 2015 20:55:20 -0400 Regards, Thomas Ross signature.asc Description: OpenPGP digital signature ---End Message--- ---BeginMessage--- BuiltSignedUploaded, thanks for your contribution to Debian! cheers, Gianfranco---End Message---
Re: how to use pbuilder without .dsc files?
On Monday, August 24, 2015 14:58:18 Andrey Rahmatullin wrote: On Sun, Aug 23, 2015 at 05:07:15PM -0700, Shawn Sörbom wrote: Hi, I am using pbuilder for the first time and I was wondering: How does one build a package in pbuilder if they haven't generated .dsc files? I am trying to build a package on my stable system that has dependencies which are only satisfiable in sid. I have not built this particular version yet, so there are no .dsc or .changes files. what should I do? You can pass -d to dpkg-buildpackage -S to skip installing Build-Depends. Thank you everybody, I appreciate it. I noticed that in my case, the pdebuild solution didn't work until I installed the pkg-kde-tools on my host system (it is a dependency in my case). I guess that tool is used during source build? Anyway, all of the replies were very useful (I ended up using all of the solutions at different times). Thanks, --Shawn signature.asc Description: This is a digitally signed message part.
Bug#795704: Fwd: Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Alex, I contacted Ernst (upstream dev) and he agreed to integrate the build system into his dev branch. Wonderful! Good news are good :) I think the above should solve the version string problem as well. Or if it doesn't we can use the old method based on date string. I think it should work find beacuse the date is monotonic increasing. For example, the current release is 12.11.2014. Let's assume the next release is 09.01.2015. We can use some regex replacement to tranform them into 20141211 and 20150901 respectively and this should works. I still don't follow that, you need to change the watch file to see a new release or not? I mean, it might be ok to change it to download the new release, but uscan is used to *detect* new tarballs on the remote, and in that way... I'm not sure it works... Maybe some other DDs can help us in achieving something similar (I guess some uversionmangle syntax might help there) So do I :P I always think I used too much I think and the... The original conversation is forwarded for your reference. thanks!!! Gianfranco
Re: how to use pbuilder without .dsc files?
On 24/08/15 01:18, Vincent Cheng wrote: Hi Shawn, On Sun, Aug 23, 2015 at 5:07 PM, Shawn Sörbom sh...@sorbom.com wrote: Hi, I am using pbuilder for the first time and I was wondering: How does one build a package in pbuilder if they haven't generated .dsc files? I am trying to build a package on my stable system that has dependencies which are only satisfiable in sid. I have not built this particular version yet, so there are no .dsc or .changes files. what should I do? Use pdebuild from within your unpacked source directory. Alternatively, use debuild -S to generate a source package, then pass the .dsc file to pbuilder. Regards, Vincent Alternatively, if the packaging your are working on uses git, you can use git-buildpackage [1]. [1] https://wiki.debian.org/PackagingWithGit Then, building a new iteration of your package is as simple as running: `gbp buildpackage` inside your packaging repository. Kind regards. Ghis
Bug#796395: RFS: rolldice/1.14-1 ITA
Hi again Thomas,
I've uploaded a new version to mentors fixing all the problems described
above/below.
yes, mostly done I see just some issues left:
1)
* Update debian/changelog to conform to DEP5
I guess you didn't mean changelog :p
2)
About the cmake file, please answer.
I really do not like custom makefiles, specially because they hide many
troubles.
e.g. what if the user wants something like
export CC=clang in their rules file?
this just won't work :)
3) I just wrote a cmake file, and I even noticed you don't need math.h at all
(you seem to open dev/random for your random files)
4) you have some warning in the build log
gcc -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -g -c main.c
gcc -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -g -c rolldice.c
rolldice.c: In function 'get_num_sides':
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
rolldice.c:183:43: note: declared here
int *get_num_sides(char *dice_string, int temp_int, int *res_int){
^
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
rolldice.c:183:43: note: declared here
rolldice.c: In function 'get_num_drop':
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
rolldice.c:200:42: note: declared here
int *get_num_drop(char *dice_string, int temp_int, int *res_int){
^
rolldice.c: In function 'get_num_rolls':
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
rolldice.c:211:24: note: declared here
int *get_num_rolls(int temp_int, int *res_int){
^
rolldice.c: In function 'get_mutiplier':
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
rolldice.c:221:43: note: declared here
int *get_mutiplier(char *dice_string, int temp_int, int *res_int){
^
rolldice.c: In function 'get_plus_modifier':
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
rolldice.c:232:47: note: declared here
int *get_plus_modifier(char *dice_string, int temp_int, int *res_int){
^
rolldice.c: In function 'get_minus_modifier':
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
rolldice.c:243:48: note: declared here
int *get_minus_modifier(char *dice_string, int temp_int, int *res_int){
^
gcc -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security main.o rolldice.o -g -o rolldice -Wl,-z,relro -lm
-lreadline
5)
cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
add_executable(rolldice main.c rolldice.c)
install(TARGETS rolldice DESTINATION bin)
target_link_libraries(rolldice readline)
this is the cmake file I wrote for you.
Simple, works with clang
mkdir build
cd build
export VERBOSE=1
export CC=clang
it still needs some little tweaks:
a) find readline with cmake features (and fail if readline is not found)
b) generate the man page (trivial, but I don't want to do the work
if you don't want a cmake file)
c) install the manpage (lol)
d) think about the version.h, and maybe change it in version.h.in and generate
it
from cmake
e) instead of using sed, use cmake features to configure a file (like manpage)
I can do all of them in a couple of minutes, but they are changes that might be
good if
upstreamed :)
let me know :)
cheers,
G.
Re: how to use pbuilder without .dsc files?
Hi Shawn, I am using pbuilder for the first time and I was wondering: How does one build a package in pbuilder if they haven't generated .dsc files? I'm using : 1. dget -x [http/ftp url of .dsc file] 2. cd [packageFolder-xxx] 3. 'dch -i' - to adapt the changelog 4. dpkg-source -b packageFolder-xxx (this will generate the .dsc file for your package) 5. sudo pbuilder build RecentlyGenerateddscFile Of course there are tons of options in pbuilder to customize the packaging, but this is minimal to give you a go ahead :-) Hope this helps! Regards Jaikumar On Mon, Aug 24, 2015 at 11:44 AM, Ghislain Vaillant ghisv...@gmail.com wrote: On 24/08/15 01:18, Vincent Cheng wrote: Hi Shawn, On Sun, Aug 23, 2015 at 5:07 PM, Shawn Sörbom sh...@sorbom.com wrote: Hi, I am using pbuilder for the first time and I was wondering: How does one build a package in pbuilder if they haven't generated .dsc files? I am trying to build a package on my stable system that has dependencies which are only satisfiable in sid. I have not built this particular version yet, so there are no .dsc or .changes files. what should I do? Use pdebuild from within your unpacked source directory. Alternatively, use debuild -S to generate a source package, then pass the .dsc file to pbuilder. Regards, Vincent Alternatively, if the packaging your are working on uses git, you can use git-buildpackage [1]. [1] https://wiki.debian.org/PackagingWithGit Then, building a new iteration of your package is as simple as running: `gbp buildpackage` inside your packaging repository. Kind regards. Ghis
Re: Questions before my first upload attempt
Hi Thomas So this in libburn4.install: debian/tmp/usr/lib/*/libburn.so.4* You can just say usr/lib/*/libburn.so.4* or even better usr/lib/*/libburn.so.* that way at the next soname bump you won't need to change the install files too. ($somebody might object that having the 4 makes you sure you don't miss a soname bump) debian/tmp/usr/include/libburn/libburn.h debian/tmp/usr/lib/*/libburn*.a debian/tmp/usr/lib/*/libburn.so debian/tmp/usr/lib/*/pkgconfig/libburn-1.pc not sure why you ship a static library, we usually do not build/ship them (shipping a static library is always a security nightmare) (if a static library is really needed you might consider adding another -static binary package, instead of putting in the same binary, but this is up to you) - Shall i dput -f now ? sure, mentors allows to dput, dput and dput again the same package. Only the last version is saved, even if you can see the version logs in the package view - What to do about the complaint: The uploader is not in the package's Maintainer or Uploaders fields Add myself to Uploaders ? Am i entitled ? if you are talking about the package at #679249 you might directly ask this to the maintainer I would like to add an argument buildstamped to the make run of libisoburn. Where to read about how to achieve this ? why? :) I do not get the question, this is the reason why I can't answer (not that I will have an answer) cheers, Gianfranco
Re: Questions before my first upload attempt
Hi Thomas, (please open an RFS if you need a sponsor, otherwise it might be difficult to track packages reviews and to actually have an upload) There will be no SONAME change as long as i am the upstream developer. ABI compatibility is one of the most important goals of my development. this is nice to hear! I see Jakub Wilk and Paul Wise discussing the general issue. Of course i would obey an instruction to remove the *.a libraries from *-dev.install, if the discussion comes to such a conclusion. As a man who cares about security I avoid as much as possible the static libraries (some packages might link it static even if they didn't know that, AFAICS there is no tool in lintian that spots an accidentally static linked library) but Jakub is right, the policy allows them, and Paul is also right, we should change that part :) so I guess right now it isn't a problem, maybe when and if the policy will be changed it will be lintian to tell you to strip it. Other communities put high value on not overwriting the same version of a tarball or package. Glad to see that mentors allows it for development work. also Debian doesn't allow that. However mentors is not the Debian ftp-master server, so you can play with versioning as you like, once the package is sponsored you won't be able anymore, since nobody will be able to upload a new tarball with a different hash and the same filename (maybe some admins can, but I guess they won't). He rather orphaned the packages now, to allow me to apply for sponsorship by others: #796145, #796146, #796147. nice, this speeds up things ... still waiting for my new dput -f of libburn to show up on the web site ... it's nearly two hours ago now. Shall i re-dput ? After what waiting time ? when the package disappears from here [1] it should be shown on the package page. If not, probably your upload wasn't processed correctly, so please reupload it. (usually I guess the queue is processed every 10 minutes or so) [1] ftp://mentors.debian.net/ cheers, G.
Re: Questions before my first upload attempt
Hi, Gianfranco Costamagna: (please open an RFS if you need a sponsor, otherwise it might be difficult to track packages reviews and to actually have an upload) I will do if my direct approach to already interested people yields no success. But currently i seem to have upload problems. [1] ftp://mentors.debian.net/ This is empty, 12:59 CEST. I configured dput for http, as shown in http://mentors.debian.net/intro-maintainers Strangely it said ftp and not http in its messages: - $ dput -f libburn_1.4.0-1.1_source.changes Trying to upload package to ftp-master (ftp.upload.debian.org) Checking signature on .changes gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1_source.changes. Checking signature on .dsc gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1.dsc. Uploading to ftp-master (via ftp to ftp.upload.debian.org): Uploading libburn_1.4.0-1.1.dsc: done. Uploading libburn_1.4.0.orig.tar.gz: done. Uploading libburn_1.4.0-1.1.debian.tar.xz: done. Uploading libburn_1.4.0-1.1_source.changes: done. Successfully uploaded packages. - So i now switch ~/.dput.cf to ftp and try again. - $ dput -f libburn_1.4.0-1.1_source.changes Trying to upload package to ftp-master (ftp.upload.debian.org) Checking signature on .changes gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1_source.changes. Checking signature on .dsc gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1.dsc. Uploading to ftp-master (via ftp to ftp.upload.debian.org): Uploading libburn_1.4.0-1.1.dsc: 553 Could not create file. Leaving existing libburn_1.4.0-1.1.dsc on the server and continuing NOTE: This existing file may have been previously uploaded partially. For official Debian upload queues, the dcut(1) utility can be used to remove this file, and after an acknowledgement mail is received in response to dcut, the upload can be re-initiated. Uploading libburn_1.4.0.orig.tar.gz: 553 Could not create file. Leaving existing libburn_1.4.0.orig.tar.gz on the server and continuing NOTE: This existing file may have been previously uploaded partially. For official Debian upload queues, the dcut(1) utility can be used to remove this file, and after an acknowledgement mail is received in response to dcut, the upload can be re-initiated. Uploading libburn_1.4.0-1.1.debian.tar.xz: 553 Could not create file. Leaving existing libburn_1.4.0-1.1.debian.tar.xz on the server and continuing NOTE: This existing file may have been previously uploaded partially. For official Debian upload queues, the dcut(1) utility can be used to remove this file, and after an acknowledgement mail is received in response to dcut, the upload can be re-initiated. Uploading libburn_1.4.0-1.1_source.changes: done. Successfully uploaded packages. - Could not create file and Successfully uploaded packages in one run ? Shall i try to create a Debian archive .commands file for dcut(1) ? Have a nice day :) Thomas
Re: Questions before my first upload attempt
On Mon, Aug 24, 2015 at 11:25 AM, Jakub Wilk wrote: Um, no. We have literally thousands of packages shipping static libraries (in addition to shared libraries). Policy §8.3 says: “The static library (‘libraryname.a’) is usually provided in addition to the shared version.” Due to the downsides we should probably change that part of policy and preventing the addition of new static libs is an essential part of such a change. https://wiki.debian.org/StaticLinking -- bye, pabs https://wiki.debian.org/PaulWise
Re: Questions before my first upload attempt
Hi, i wrote: Add myself to Uploaders ? Am i entitled ? Christian Kastner wrote: However: it appears that this package is team-maintained. In that case, you leave the Maintainer as-is, and add yourself to Uploaders. Adding myself to uploaders leads to new local warnings: W: libburn source: changelog-should-not-mention-nmu W: libburn source: maintainer-upload-has-incorrect-version-number 1.4.0-1.1 So for a test, i removed the the surplus .1 and the line * Non-maintainer upload. from changelog. Seems to be ok. I can run dpkg-i although the version number is now lower than the previously installed one. Unpacking libburn4 (1.4.0-1) over (1.4.0-1.1) ... IMHO, taking over this package correctly would mean to also take over the alioth project as admin by 1. Requesting to join the team 2. Having the current admin set your new account as admin 3. Removing the old admin I was already made aware that there is a repo to be taken over. (The project page itself is very sparse.) But currently i am still overwhelmed by packaging. My plan is to get the three packages presentable, approach my potential sponsors for adoption, and then try to understand the rest of the infrastructure. The current admin is very busy in real life. Else i would have used him as sponsor and the packages were already in sid. The task to update the packages to newest upstream was up to now among the easiest ones. Once you have completed the above, add yourself to Uploaders. Not being there yet, i stay with NMU for now and will put my three packages on display. It's time to look for sponsors and to get their opinion about my packaging. Gianfranco Costamagna wrote: that way at the next soname bump you won't need to change the install files too. ($somebody might object that having the 4 makes you sure you don't miss a soname bump) There will be no SONAME change as long as i am the upstream developer. ABI compatibility is one of the most important goals of my development. (Last inadverted breaking of ABI was with 0.3.2 in february 2007, but i got SONAME correct only with version 0.4.2 in february 2008.) not sure why you ship a static library, A former maintainer of libburn has put these files into the libburn-dev.install file. I am not yet apt to judge whether this should be changed. One reason might have been that dbg had versions which did an awful job with dynamic libraries. Did not try yet with my two month old Jessie. I have my own static compilation setup for upstream development purposes. I see Jakub Wilk and Paul Wise discussing the general issue. Of course i would obey an instruction to remove the *.a libraries from *-dev.install, if the discussion comes to such a conclusion. sure, mentors allows to dput, dput and dput again the same package. Other communities put high value on not overwriting the same version of a tarball or package. Glad to see that mentors allows it for development work. if you are talking about the package at #679249 you might directly ask this to the maintainer As said above, George Danchev has no time to sponsor or coach me. He rather orphaned the packages now, to allow me to apply for sponsorship by others: #796145, #796146, #796147. I thought they were orphaned since two years, when George told me he could not longer maintain them. But that last step was made only a few days ago, when he was pointed by a bystander to my questions on debian-user. We do not split in anger or something like that. It's just that real life prevents him from covering my upstream releases. I got an offer of help by Steve McIntyre, who uses xorriso for debian-cd. But before bothering him with technical questions, i preferred to bother people who obviously don't mind noobs and their difficulties. Thanks a lot to this list and to all who answered. Dominique Dumont expressed interest, too. He pointed me to the task of taking care of the repo. (I'm still very clueless with this topic.) I will also inform the neighboring team which maintains dvd+rw-tools. ... still waiting for my new dput -f of libburn to show up on the web site ... it's nearly two hours ago now. Shall i re-dput ? After what waiting time ? Have a nice day :) Thomas
Re: how to use pbuilder without .dsc files?
On Sun, Aug 23, 2015 at 05:07:15PM -0700, Shawn Sörbom wrote: Hi, I am using pbuilder for the first time and I was wondering: How does one build a package in pbuilder if they haven't generated .dsc files? I am trying to build a package on my stable system that has dependencies which are only satisfiable in sid. I have not built this particular version yet, so there are no .dsc or .changes files. what should I do? You can pass -d to dpkg-buildpackage -S to skip installing Build-Depends. -- WBR, wRAR signature.asc Description: Digital signature
Bug#795771: RFS: dblatex/0.3.7-1
Hi Andreas, thanks again for your review. I have uploaded dblatex-0.3.7-2 to first nitpick: not needed to upload a -2 version. using the same -1 is fine and works until the real upload (on Debian ftp-master) is performed Sorry to disagree with your first suggestion (terrible start, I know): there is no terrible start for me :) Using a machine-readable copyright file is optional according to section12.5.1 of the Debian Policy Manual. In contrast to this idea I prefer to keep as close to the upstream copyright file as possible, thus simply diffing the upstream with the Debian file is enough to keep the latter synchronized with the former. fine for me :) Anyway, I'm happy to comply and have changed according to your suggestion. feel free to revert them back if your emacs is more satisfied (I do not care about the evaluation part, since we talk about some cpu cycles, but keep them as you like then, it is fine for me!) I have moved the retrieval of the examples tarball to the watch file and eliminated the get-orig-source target and all related stuff. Indeed this simplifies the rules file remarkably. ack You're right, done. [...] Done. wonderful Here I disagree again: dblatex-examples.tar.bz2 has been uploaded one time (in 2009) to SourceForge and hasn't changed since then, the archive is not versioned at all. Thus IMHO it's overkill to use a separate package for this small, static add-on. mmm what does it happen if they gets updated and you miss it because there is no uscan detecting them? I see that the watch file already takes care of them, unfortunately they are not versioned, so we might not catch an update there... this is usually bad, maybe ping upstream about adding an 1.0 somewhere to avoid people missing examples updates (but here we might really don't care about examples 10 years old never updated) BTW you might also use pypi to fetch your sources from http://pypi.debian.net/dblatex (there is also a watch file for the source tarball, you might want to use it and add the examples part) Good idea, done. thanks As you see, I've been happy to implement many of your findings, however I disagree with your vote on the machine-readable copyright file and on the package split. I hope that you will nevertheless consider to sponsor this upload, although I would also understand if you forbear From=20sponsoring as you don't agree with my packaging decisions. just to clarify, my view is not the right one, and your view is not the bad one. My view is a single view point in a community of 2k+ people, and disagreeing with me is completely fine as long as we do not violate any policy rule ;) we might differ just because I had already done some work for Debian already, so I might foresee problems where a non DD usually don't look (specially related to Debian packaging of course). But as long as you can explain your point of view, I can agree for sure if the explanation is good :) (and this doesn't change usually my sponsoring effort) Some other nitpicks: I see you runtime-depends on python-apt, not sure why, but please consider adding it to the install_requires section of setup.py and let python:Depends do its job :) cheers, G.
Re: Questions before my first upload attempt
* Gianfranco Costamagna costamagnagianfra...@yahoo.it, 2015-08-24, 07:00: debian/tmp/usr/include/libburn/libburn.h debian/tmp/usr/lib/*/libburn*.a debian/tmp/usr/lib/*/libburn.so debian/tmp/usr/lib/*/pkgconfig/libburn-1.pc not sure why you ship a static library, we usually do not build/ship them Um, no. We have literally thousands of packages shipping static libraries (in addition to shared libraries). Policy §8.3 says: “The static library (‘libraryname.a’) is usually provided in addition to the shared version.” (if a static library is really needed you might consider adding another -static binary package, instead of putting in the same binary, but this is up to you) That would be very unusual. Policy §8.3 says static libraries should put into the -dev package. -- Jakub Wilk
Re: Questions before my first upload attempt
On Mon, 24 Aug 2015 12:50:04 +0200, Thomas Schmitt wrote: I configured dput for http, as shown in http://mentors.debian.net/intro-maintainers Strangely it said ftp and not http in its messages: - $ dput -f libburn_1.4.0-1.1_source.changes Trying to upload package to ftp-master (ftp.upload.debian.org) You're uploading to ftp.upload.debian.org and not to mentors.d.n. Quoting from the page you cited above: `dput mentors your_sourcepackage_1.0.changes' (note the 'mentors' which refers to the name in the ~/.dput.cf) (ftp.upload.debian.org will remove your upload attempts automatically.) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Tom Waits: Trampled Rose signature.asc Description: Digital Signature
Re: Questions before my first upload attempt
Hi Thomas, If you dput $something, you need to wait until $something is processed, any later upload will fail because you can't overwrite the files in ftp unprocessed queue. So wait for the upload, get the email confirmation, and then dput again. According to the log you posted, seems that dput worked :) and also the other tool you used ;) Shall i try to create a Debian archive .commands file for dcut(1) ? not sure if dcut works on mentors, but I guess not (I do not remember honestly). When I had partial uploads on ftp queue what I did was: retry the upload this forced dput to upload all the files on mentors.d.o (even if some of them was broken), then after the .changes file was uploaded the $program was checked and removed from the queue. Then I reuploaded all again. cheers, G.
Re: Questions before my first upload attempt
Hi, gregor herrmann wrote: You're uploading to ftp.upload.debian.org and not to mentors.d.n. Duh (once again). This explains a lot. Meanwhile i bothered it with a libisofs upload attempt, too. Need to make me an upload script. I began to write quite a desparate answer to Gianfranco and to think about a version bump. But now it accepts my upload without -f $ dput mentors libburn_1.4.0-1.1_source.changes ... Uploading to mentors (via ftp to mentors.debian.net): ... ... patiently waiting for mail now ... oh joy ! Upload shows effect on package/libburn: All green, except The uploader is not in the package's Maintainer or Uploaders fields. I'm back on tracks, as it seems. Will upload the other two packages, contact my sponsor candidates, and ask them whether i shall file an RFS, additionally. Have a nice day :) Thomas
Re: how to use pbuilder without .dsc files?
❦ 24 août 2015 11:25 -0700, Shawn Sörbom sh...@sorbom.com : Thank you everybody, I appreciate it. I noticed that in my case, the pdebuild solution didn't work until I installed the pkg-kde-tools on my host system (it is a dependency in my case). I guess that tool is used during source build? Anyway, all of the replies were very useful (I ended up using all of the solutions at different times). You can avoid that with -nc. -- I'll burn my books. -- Christopher Marlowe signature.asc Description: PGP signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 22/08/15 15:06, Oxan van Leeuwen wrote: Hi, On 21-08-15 00:19, Tomasz Buchert wrote: I think that we either: * need hard dependency on postfix * need to have a debconf dialog that goes more or less like that: - if postconf exists, the domain is taken from there - if not, the current hostname is taken - then a debconf dialog is shown prefilled with these defaults - the obtained domain name is used in init scripts Waht do you think? Tell me if you need help with the second. The second option seems sensible, I've pushed an implementation. Let me know what you think. Nicely done, but there is one issue. If you modify conffiles in postinst it marks them as changed, and this is not something you want to do. In my branch tomasz-changes I followed ADVANCED PROGRAMMING WITH DEBCONF section in man debconf-devel. The outcome is that the config file is not tracked by conffiles machinery and hence the problem does not exist. Please review. I think that a sensible thing to do would be to provide POSTSRSD_OPTS as 'Environment=...' and then pull a config file with 'EnvironmentFile=-...' (which may contain various configs in comments too). It seems to be sort-of standard. And, right, if you also use debconf, then you probably need to pull a file created created in postinst. I'd prefer to keep separate variables for the most common options. A single options variable will be quite cryptic (as postsrsd doesn't support long options), and that will make it harder to change a setting without having to pull the manpage. Duplicating a few defaults is a small price to pay for ease of configuration in my opinion. We could add a options variable to add additional command-line options, though I doubt it will be used much. Ok. Cheers, Oxan Cheers, Tomasz signature.asc Description: Digital signature
Bug#796828: RFS: xfce4-equake-plugin/1.3.8
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package xfce4-equake-plugin * Package name: xfce4-equake-plugin Version : 1.3.8 Upstream Author : Jeroen van Aart andr...@e-quake.org * URL : http://www.e-quake.org * License : GPL Section : xfce It builds those binary packages: xfce4-equake-plugin - Xfce panel plugin which monitors earthquakes To access further information about this package, please visit the following URL: http://mentors.debian.net/package/xfce4-equake-plugin Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/x/xfce4-equake-plugin/xfce4-equake-plugin_1.3.8.dsc More information about hello can be obtained from http://www.e-quake.org or https://sourceforge.net/projects/equake/ Changes since the last upload: * Closes: 728691 * Moved to bing maps for the detailed map display, the USGS map display remains unchanged Thank you, Jeroen van Aart
Bug#796830: RFS: dominate/2.1.5-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package dominate * Package name: dominate Version : 2.1.5-1 Upstream Author : Tom Flanagan t...@zkpq.ca * URL : https://github.com/Knio/dominate * License : LGPL-3+ Section : python It builds these binary packages: python-dominate - Python 2 library for creating and manipulating HTML documents python3-dominate - Python 3 library for creating and manipulating HTML documents To access further information about this package, please visit the following URL: http://mentors.debian.net/package/dominate Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/dominate/dominate_2.1.5-1.dsc I hope to maintain this package under the Python Modules Packaging Team if they will have me. In which case I will update this bug with the URL to the team repository on Alioth. Changes since the last upload: * Initial release (Closes: #796518) Regards, Ross Gammon -- System Information: Debian Release: jessie/sid APT prefers vivid-updates APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), (100, 'vivid-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-26-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#793876: RFS: chrony/1.31.1-1
Le ven. 21 août 2015 à 9:21, Paul Gevers elb...@debian.org a écrit : Hi Vincent, Hey Paul, [I am merging the e-mails you send yesterday to make the thread easier again.] On 20-08-15 18:12, Vincent Blut wrote: Le jeu. 20 août 2015 à 12:10, Paul Gevers elb...@debian.org a écrit : Your priority switch from extra to optional may require a ping to somebody. I am not sure and I would need to search, so please do that yourself. Yes. I’ll have to send a bug report to the ftp.debian.org pseudo-package asking for the modification of the section/priority in the override-file. Will do later today… or tomorrow. Ack. Bug report sent¹. Which file do you have in common with ntp? Please re-read ¹. I guess I’ve been misled by § 7.6.2! The previous section shows the usage of the 'replaces:' field for packages providing *files* already provided by another package. However, the section 7.6.2 seems to be for *packages* that /do conflict/; I interpreted that /do conflict/ by packages providing the same functionality. I even was quite sure my interpretation was correct after seeing the usage example about MTAs. I didn't check if ntp is also doing the conflicts/replaces/provides dance on time-deamon. If so I than you don't need to mention ntp specifically at all¹¹. It does not. There is still an opened bug report² about adding ntp to the time-daemon virtual package, but the discussion has stalled since few years now. Anyway, depending on your answer, I’ll revert this commit. Lets not do that until we agree. :) Ok. Wouldn't the hwclockfile stuff in /etc not warrant an debian/NEWS update? Or at the very least some help in the changelog? I don’t think so. Finally, that change have no impact for the user. Previously we had to check (in the postinst script) if the RTC keeps local time or UTC by parsing /etc/adjtime and/or /etc/default/rcS. Depending on the result, we set (or no) the rtconutc directive in /etc/chrony.conf. But now chrony is grown enough to check that by itself. Each time it is started, it will parse the correspondent value in the /etc/adjtime file. So, as you can see, the whole point of using the hwclockfile directive is to have something cleaner than playing the text processing game for the same result. Doesn't this actually require a migration path? What if the /etc/chrony and /etc/adjtime are NOT answering the same? Well, I’m not sure I’m understanding you here. The chronyd daemon will use what /etc/adjtime returns, thanks to the 'hwclockfile /etc/adjtime' directive. Oh, you not understanding me makes sense. It was me who didn't understand what you were doing. I was assuming there now was a new mechanism, but now you explained it is just a better implementation of the same thing. But then again, maybe make that a little clearer in your changelog for others like me? Ok, maybe adding something like: “Basically, this directive makes the detection of the standard (Local or UTC time) set in /etc/adjtime — and used by the hardware clock — clearer compared to the text processing method we used to use in the post install script to complete the same task.” What do you think? Can you please explain me how commit 1ce86d3 works (the Breaks of util-linux). As the hwclockfile directive can only deal with /etc/adjtime, we need to ensure that we migrated from /etc/default/rcS to /etc/adjtime. To be honest, I’m not sure that break is even needed, because this migration happened prior to Wheezy. I haven't looked it up, is util-linux in essential? Otherwise, shouldn't you depend on it with the higher than dependency? Indeed, util-linux is essential hence the fact it is not listed in the 'Depends:' field. I assume you tested all migrations for admins that already ran chrony as a different users as described in the README.Debian. Are the manual steps even needed? Shouldn't this go into a NEWS file instead of the README file? I tested a lot of use cases, but Jerome Benoit informed me he had an issue possibly related to this change, but as he uses a custom init script etc., I will have to check his atypical configuration. Ack. After inspecting Jerome’s custom init script, it appreared it was buggy. However I’ll have to find a way not to mess with users who set the default chronyd user in the init script instead of using the user directive in /etc/chrony/chrony.conf. To be honest I don’t see an easy way of doing it, so a first good step will probably be to add a warning in a NEWS file. Line 36 of the README.Debian file ends weird now, you removed a filename but not the and in front. Indeed, will fix. You mean line 27 right? I am talking about The scripts /etc/ppp/ip-up.d/chrony, /etc/ppp/ip-down.d/chrony, and read key 1 from /etc/chrony/chrony.keys and use it as the password to send chronyc commands. In my version that is on line 36. My bad, I was checking the file with nl which doesn't
Bug#793876: RFS: chrony/1.31.1-1
Le mar. 25 août 2015 à 0:33, Jerome BENOIT calcu...@rezozer.net a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi: On 24/08/15 23:52, Vincent Blut wrote: After inspecting Jerome’s custom init script, it appreared it was buggy. To my defence: 1] the buggy part was commented as obsoleted, 2] it contains more material, in particular support for /etc/network/if-*.d You're right, my sentence sounds like the whole init script was buggy, but that isn't the case. The context was about the supposedly breakage of the -u option expressed in 55d503b7.7050...@rezozer.net Sorry, if that offended you! However I’ll have to find a way not to mess with users who set the default chronyd user in the init script instead of using the user directive in /etc/chrony/chrony.conf. To be honest I don’t see an easy way of doing it, so a first good step will probably be to add a warning in a NEWS file. Note that regular users are not supposed to modify their /etc/init.d/chrony but they are supposed to configure properly their /etc/chrony/chrony.conf . Sure, but it'd be great to mitigate upgrade issues for those that did so. I modify my /etc/init.d/chrony mainly to get /etc/network/if-*.d support. BTW, is PPP stuff still needed ? Yes, there are still Dial-up only internet accesses here and there, but its usage dropped significantly in favor of broadband Internet access. In short, you may rather focus on #312092 and #633422 hth, Jerome Cheers, Vincent
Bug#793876: RFS: chrony/1.31.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi: On 24/08/15 23:52, Vincent Blut wrote: After inspecting Jerome’s custom init script, it appreared it was buggy. To my defence: 1] the buggy part was commented as obsoleted, 2] it contains more material, in particular support for /etc/network/if-*.d However I’ll have to find a way not to mess with users who set the default chronyd user in the init script instead of using the user directive in /etc/chrony/chrony.conf. To be honest I don’t see an easy way of doing it, so a first good step will probably be to add a warning in a NEWS file. Note that regular users are not supposed to modify their /etc/init.d/chrony but they are supposed to configure properly their /etc/chrony/chrony.conf . I modify my /etc/init.d/chrony mainly to get /etc/network/if-*.d support. BTW, is PPP stuff still needed ? In short, you may rather focus on #312092 and #633422 hth, Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV25urAAoJEIC/w4IMSybjGwMH/1mbGWS/iBvOfJBUG7od8wW9 ff22VEsvY8GoRw0qNXpVbI+FNRn2uroOS/Q1m8MWzNflnVjUnZ84DUsnsupfLFuV wUdDyU5/vVaK4KrouigPdGVHc7LTs4thmqlSP+FL/eSyvQIu4+XNB6BUDGtXKOOZ Ec5/Vep8MMzv/Cx9rr6oUPfx8pVk0RfmHnlWtH5q07PZNAOu3UyLeEPYVVIqY2VI ntYvEmlrw7aB05gDNFHKJmDYcI8mj6ZboJ18fzx5sdG6E4mLoRM/xr0LvlC/zxbJ XR/Q0tw2IzxjKrRMWiq+QvKkK/kPDoXhY+ZhVpAOyNq8MODXkpyY3Acqb4NHx2Q= =mRUF -END PGP SIGNATURE-
Bug#793876: RFS: chrony/1.31.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/08/15 02:00, Vincent Blut wrote: Le mar. 25 août 2015 à 0:33, Jerome BENOIT calcu...@rezozer.net a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi: On 24/08/15 23:52, Vincent Blut wrote: After inspecting Jerome’s custom init script, it appreared it was buggy. To my defence: 1] the buggy part was commented as obsoleted, 2] it contains more material, in particular support for /etc/network/if-*.d You're right, my sentence sounds like the whole init script was buggy, but that isn't the case. The context was about the supposedly breakage of the -u option expressed in 55d503b7.7050...@rezozer.net Sorry, if that offended you! I just wanted to clarify :-) I am bad, but that bad. However I’ll have to find a way not to mess with users who set the default chronyd user in the init script instead of using the user directive in /etc/chrony/chrony.conf. To be honest I don’t see an easy way of doing it, so a first good step will probably be to add a warning in a NEWS file. Note that regular users are not supposed to modify their /etc/init.d/chrony but they are supposed to configure properly their /etc/chrony/chrony.conf . Sure, but it'd be great to mitigate upgrade issues for those that did so. 1] modified init.d scripts are managed by Debian at, so you do not have to worry about this; 2] most importantly, adventurous folks who modified their init.d scripts are supposed to know what they do. I modify my /etc/init.d/chrony mainly to get /etc/network/if-*.d support. BTW, is PPP stuff still needed ? Yes, there are still Dial-up only internet accesses here and there, but its usage dropped significantly in favor of broadband Internet access. In short, you may rather focus on #312092 and #633422 hth, Jerome Cheers, Vincent Best wishes, Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV27+EAAoJEIC/w4IMSybjRnYIAITEFF3Su3naL4SGDt0TpieR vxSqaN/lfgluHso5/HqmHMemMQM17WgVWSgVTMjO0kexl6/ZBJI1WoLiPL236vWY 1wOHu11ks1XD9S7WLDkoFUkg9gDUFMcT9T7GMUh9TAGTaEgfNauWSbIWNfl+fj2t c91W16WLldoFnKCIHfAjhRGLuvhfEKRDY08uo5Q35r6yUjTeHNeLZiggmuv5U8FT 1rc5lDEcGWmPX8gK0Z4X6m+CVdA+Xzowaq2qX2pBMLYn/H84+WOUvJmsaF93HD2g PyOj2WaZg9q7SZ5MsedY1sUItgunA9+gbtdKLoXbNkOZaKA5+GP/N/3b9L83AYI= =mxTm -END PGP SIGNATURE-
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi Thomas, On 24-08-15 14:10, Tomasz Buchert wrote: Nicely done, but there is one issue. If you modify conffiles in postinst it marks them as changed, and this is not something you want to do. In my branch tomasz-changes I followed ADVANCED PROGRAMMING WITH DEBCONF section in man debconf-devel. The outcome is that the config file is not tracked by conffiles machinery and hence the problem does not exist. Please review. Yeah, that's definitely true. Your branch looks good to me. It's probably a bit cleaner to wrap the config-writing machinery in the postinst in an if [ $1 = configure ], but I don't think it hurts to execute it for the other postinst invocations as well. Other than that, I don't think there are any remaining issues preventing upload? Cheers, Oxan
Re: Introduce wrapper package of linuxbrew into Debian
Hi Gianfranco Costamagna, On Wed, 2015-08-19 at 13:07 +, Gianfranco Costamagna wrote: BTW the git urls are wrong: examples of good git urls: Vcs-Git: git://anonscm.debian.org/collab-maint/package-xx.git Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/package-xx.git Fixed this in control :-) again, forwarding patches from GPL-* to BSD-* is not allowed. So another folk won't be able to forward a patch you made in Debian to upstream. Think about that possibility, maybe it isn't important/real for you, but I want to make you aware of that So keep the same license as upstream indeed avoids many trouble... I've changed debian license to BSD-2-Clause, which is the same as upstream. The revised package was uploaded to mentors: http://mentors.debian.net/package/linuxbrew-wrapper http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-1.dsc Changes since last upload: * dch -r unstable * bump debian copyright to bsd-2-clause * update manpage Thanks. -- .''`. Lumin : :' : `. `' `-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A signature.asc Description: This is a digitally signed message part
