Re: dependent packages blocked from testing
Ltt-controls has not been built on all archs (those out of date messages on the PTS). Seems that there are build deps not available. (Take a look at the buildds status page) Jon Bernard jbern...@debian.org schrieb: Hello, I'm facing a problem with two packages that are blocked from migrating into testing. I'm having trouble seeing a clear path forward and I wonder if anyone could point me in a better direction. The specific packages are ltt-control[1] and ust[2]. If the source packages only built a single binary package, then apt's arbitrary selection of one to break the dependency chain would work, from what I understand. But in this case each source package builds several binary packages and I do not see a clean way out of this (other than asking the release team to manually move them, but I would prefer to find a proper solution). Is there any advise for this situation? Specifically, how do I get out of this mess cleanly, and what could I have done differently to prevent this from ever happening? [1]: http://release.debian.org/migration/testing.pl?package=ltt-control [2]: http://release.debian.org/migration/testing.pl?package=ust Cheers, -- Jon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130718233730.GB19047@helmut.local -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: Empty binary package
On 19-07-13 05:13, T o n g wrote: As said in OP, Which I don't have anymore, so indeed please repeat it if you want my help. - I unpack the upstream tarball and build the binary debian package with 'debuild -us -uc'. the build is good. Why do this debuild -us -uc first if you proceed with the next? - I then build the upstream into *source package* with 'debuild -S -sa', and then build the binary debian package *from this source package*. The binary package built this way is however empty. So how do you do the last step? And why is building from your source package any different than your first step with -us -uc? What do you do EXACTLY when you build from the source package, i.e. please provide all the copy and build commands. It is NOT empty if I try it (the step to create the source package first is not really relevant is it?) paul@wollumbin $ ls -l total 340 drwxr-xr-x 5 paul paul 4096 jul 17 21:12 pam_ssh_agent_auth-0.9.5 -rw-r--r-- 1 paul paul 277802 jul 19 08:17 pam-ssh-agent-auth_0.9.5-1.tar.gz paul@wollumbin $ cd pam_ssh_agent_auth-0.9.5 paul@wollumbin pam_ssh_agent_auth-0.9.5 $ pdebuild lot of output paul@wollumbin $ ls -l total 340 drwxr-xr-x 5 paul paul 4096 jul 17 21:12 pam_ssh_agent_auth-0.9.5 -rw-r--r-- 1 paul paul 53532 jul 19 08:20 pam-ssh-agent-auth_0.9.5-1_amd64.build -rw-r--r-- 1 paul paul652 jul 19 08:17 pam-ssh-agent-auth_0.9.5-1.dsc -rw-r--r-- 1 paul paul 1035 jul 19 08:17 pam-ssh-agent-auth_0.9.5-1_source.changes -rw-r--r-- 1 paul paul 277802 jul 19 08:17 pam-ssh-agent-auth_0.9.5-1.tar.gz and paul@wollumbin $ ls -l /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent-auth_0.9.5* -rw-r--r-- 1 paul paul 1324 jul 19 08:19 /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent-auth_0.9.5-1_amd64.changes -rw-r--r-- 1 paul paul 41696 jul 19 08:19 /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent-auth_0.9.5-1_amd64.deb -rw-r--r-- 1 paul paul652 jul 19 08:18 /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent-auth_0.9.5-1.dsc -rw-r--r-- 1 paul paul 280317 jul 19 08:18 /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent-auth_0.9.5-1.tar.gz (Interestingly, the tar is also different, but that is also to be expected I guess from the known problems with the packaging). And don't forget that you already identified several problems with the upstream source. E.g. it misses a source/format file containing 3.0 (quilt). I've fixed all of those but the binary package built from my source package is empty. Thus I'm reverting to the very beginning, to rule out that it is caused by my modification. The point also reported by Andrey in this thread, is you are NOT asking the right questions and you are not giving enough information. If I try to build your package, it just works, as said before. There are problems, yes, but we have told you how to fix those. So if you want help, please fix the issues, and try to ask specific questions on what you want/need to know and give extensive information. As you say, you probably do something wrong but we can guess it until you tell us what you do. Paul signature.asc Description: OpenPGP digital signature
Re: mentors.d.n upload issues
On Thu, Jul 18, 2013 at 05:59:56PM -0700, Octavio Alvarez wrote: On Wed, 17 Jul 2013 20:08:50 -0700, Bill Blough de...@blough.us wrote: That bit me too days ago. I just incremented the Debian version and uploaded the new version. That worked. It's been worked around for now. I guess I'll see what happens on the next upload. signature.asc Description: Digital signature
Re: dependent packages blocked from testing
On Fri, Jul 19, 2013 at 07:53:51AM +0200, Tobias Frost wrote: Ltt-controls has not been built on all archs (those out of date messages on the PTS). Seems that there are build deps not available. (Take a look at the buildds status page) It waits for ust to be built on ia64, mips, mipsel, s390, s390x and sparc. Out of those, ia64 build just fails while mips, mipsel, s390x and sparc need systemtap-sdt-dev, which does not exist on those arches for at least quite some time. s390 has No entry in s390 database which I have no idea about. Jon Bernard jbern...@debian.org schrieb: Hello, I'm facing a problem with two packages that are blocked from migrating into testing. I'm having trouble seeing a clear path forward and I wonder if anyone could point me in a better direction. The specific packages are ltt-control[1] and ust[2]. If the source packages only built a single binary package, then apt's arbitrary selection of one to break the dependency chain would work, from what I understand. But in this case each source package builds several binary packages and I do not see a clean way out of this (other than asking the release team to manually move them, but I would prefer to find a proper solution). Is there any advise for this situation? Specifically, how do I get out of this mess cleanly, and what could I have done differently to prevent this from ever happening? [1]: http://release.debian.org/migration/testing.pl?package=ltt-control [2]: http://release.debian.org/migration/testing.pl?package=ust Cheers, -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130719070222.ga8...@belkar.wrar.name
Bug#712298: RFS: amanda/1:3.3.4-1 [ITA] - reopened
I finally feel like the package is in a better shape to be uploaded now, so I am reopening my RFS. Here are the updated details: * Package name: amanda Version : 1:3.3.4-1 Upstream Author : Amanda Development Team amanda-hack...@amanda.org * URL : http://www.amanda.org * License : GPL and University of Maryland License Section : utils It builds those binary packages: amanda-client - Advanced Maryland Automatic Network Disk Archiver (Client) amanda-common - Advanced Maryland Automatic Network Disk Archiver (Libs) amanda-server - Advanced Maryland Automatic Network Disk Archiver (Server) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/amanda Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/amanda/amanda_3.3.4-1.dsc More information about amanda can be obtained from http://www.amanda.org. Changes since the last upload: * New upstream version * New maintainer, closes: #700484 * Fix directory hierarchy for amserverconfig template files, * Move templates from amanda-server to amanda-common to match location of amserverconfig and amaddclient, * Update amserverconfig output to reflect correct path of xinetd example, * closes: #551564 * Add patch descriptions * Fix typo errors in various source files * Fix line breaks in man page * Fix FHS deviations in the man page * Add additional hardening flags * Link upstream changelogs from -common package to -client and -server packages * Add overrides for a few lintian false postitives * Modify maintainer scripts to use set -e * Update default directories to not use /usr/adm * Downgrade Conflicts to Breaks for old (pre-oldstable) versions of amanda-common * always regenerate configure when building package Best regards, Bill signature.asc Description: Digital signature
Bug#717262: ITP missing for package curseofwar with RFS 717262 with ITP in title
El dv 19 de 07 de 2013 a les 09:16 +0400, en/na Anton Balashov va escriure: Thank you for your pay attention on that. I made a new letter: From: Anton Balashov sicn...@darklogic.ru To: sub...@bugs.debian.org Subject: ITP: curseofwar/1.1.4-1 With the same text. Is that right? No, you should open an ITP bug in wnpp package. Please, close this last bug sending a mail to 717304-cl...@bugs.debian.org and open another one in wnpp package following the steps wou'll find here: http://www.debian.org/devel/wnpp/ (section Using WNPP) Once you've opened this bug, you should close it in your debian/changelog file. Thanks for your work! signature.asc Description: This is a digitally signed message part
Bug#716850: marked as done (RFS: allegro4.4/2:4.4.2-4)
Your message dated Fri, 19 Jul 2013 13:40:40 +0200 with message-id 20130719134040.68e58...@debian.lan and subject line Allegro 2:4.4.2-4 uploaded has caused the Debian Bug report #716850, regarding RFS: allegro4.4/2:4.4.2-4 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.) -- 716850: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716850 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-request Severity: normal Dear mentors, I am looking for a sponsor for my package allegro4.4 * Package name: allegro4.4 Version : 2:4.4.2-4 Upstream Author : Shawn Hargreaves + the Allegro developers * URL : http://liballeg.org/ * License : Allegro-gift-ware Section : devel It builds those binary packages: allegro4-doc - documentation for the Allegro library liballeggl4-dev - development files for the allegrogl library liballeggl4.4 - library to mix OpenGL graphics with Allegro routines liballegro-doc - transitional dummy package liballegro4-dev - development files for the Allegro library liballegro4.4 - portable library for cross-platform game and multimedia developme liballegro4.4-plugin-alsa - ALSA audio plugin for the Allegro library libjpgalleg4-dev - development files for the JPG loading addon for Allegro 4 libjpgalleg4.4 - JPG loading addon for Allegro 4 libloadpng4-dev - development files for the PNG loading addon for Allegro 4 libloadpng4.4 - PNG loading addon for Allegro 4 liblogg4-dev - development files for the OGG loading addon for Allegro 4 liblogg4.4 - OGG loading addon for Allegro 4 To access further information about this package, please visit the following URL: http://mentors.debian.net/package/allegro4.4 Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/allegro4.4/allegro4.4_4.4.2-4.dsc More information about allegro4.4 can be obtained from http://liballeg.org Changes since the last upload: allegro4.4 (2:4.4.2-4) unstable; urgency=low * Add replaces / breaks on liballegro4.2-dev (Closes: #714595, #714814) * Fix lintian vcs-field-not-canonical warning * Fix unused-override hardening-no-fortify-functions -- Andreas Rönnquist gus...@gusnan.se ---End Message--- ---BeginMessage--- Allegro 2:4.4.2-4 has been uploaded. Thanks!---End Message---
Re: Empty binary package
On Fri, 19 Jul 2013 08:38:49 +0200, Paul Gevers wrote: On 19-07-13 05:13, T o n g wrote: As said in OP, Which I don't have anymore, so indeed please repeat it if you want my help. It was still included in the message that I previously replied. - I unpack the upstream tarball and build the binary debian package with 'debuild -us -uc'. the build is good. Why do this debuild -us -uc first if you proceed with the next? To prove that the upstream can build into binary package just fine. - I then build the upstream into *source package* with 'debuild -S -sa', and then build the binary debian package *from this source package*. The binary package built this way is however empty. So how do you do the last step? And why is building from your source package any different than your first step with -us -uc? What do you do EXACTLY when you build from the source package, i.e. please provide all the copy and build commands. It is NOT empty if I try it The last steps are just as normal. I'll get back to you in specific details later, but again just as normal. Meanwhile, when I said that the binary package is empty, as I explained in my OP, I meant that the built binary package will not contains the files that I want. I.e., it contains nothing except the copyright changelog files. So hope it's clearer this time: upstream directly to binary package, OK. Files included. upstream = debian source then = debian binary package, Not OK. Files are missing. . . . and paul@wollumbin $ ls -l /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent-auth_0.9.5* -rw-r--r-- 1 paul paul 1324 jul 19 08:19 /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent- auth_0.9.5-1_amd64.changes -rw-r--r-- 1 paul paul 41696 jul 19 08:19 /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent- auth_0.9.5-1_amd64.deb -rw-r--r-- 1 paul paul652 jul 19 08:18 /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent-auth_0.9.5-1.dsc -rw-r--r-- 1 paul paul 280317 jul 19 08:18 /var/cache/pbuilder/wheezy-amd64/result/pam-ssh-agent- auth_0.9.5-1.tar.gz Did you try to build debian binary package from there? As a reference, you can also build from my source package (which has fixed all the problems you told me to fix): http://mentors.debian.net/debian/pool/main/libp/libpam-ssh-agent-auth/ libpam-ssh-agent-auth_0.9.5-2.dsc And see if you can get anything other than the copyright changelog files into the binary package. PS. I saw the the following being installed during my binary package building (from my source), but the installed files didn't show up in my binary package: /usr/bin/install-c -m 644 pam_ssh_agent_auth.8 /systems/b/libpam-ssh- agent-auth/test-mine/libpam-ssh-agent-auth-0.9.5/debian/tmp/usr//share/ man/man8/pam_ssh_agent_auth.8 /usr/bin/install-c -m 755 pam_ssh_agent_auth.so /systems/b/libpam-ssh- agent-auth/test-mine/libpam-ssh-agent-auth-0.9.5/debian/tmp/lib/security/ pam_ssh_agent_auth.so Thanks -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ksbe2t$9jn$1...@ger.gmane.org
Bug#716858: marked as done (RFS: gtk-theme-switch/2.1.0-3 [ITA] - GTK+ theme switching utility)
Your message dated Fri, 19 Jul 2013 16:00:22 +0300 with message-id 20130719130022.gb23...@ieval.ro and subject line Closing bug has caused the Debian Bug report #716858, regarding RFS: gtk-theme-switch/2.1.0-3 [ITA] - GTK+ theme switching utility 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.) -- 716858: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716858 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Control: block 588836 by -1 Dear mentors, I am looking for a sponsor for my package gtk-theme-switch * Package name: gtk-theme-switch Version : 2.1.0-3 Upstream Author : Denis Briand de...@narcan.fr * URL : http://gna.org/projects/gtk-theme-switch/ * License : GPL-2+ Section : x11 It builds those binary packages: gtk-theme-switch - GTK+ theme switching utility To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gtk-theme-switch Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/gtk-theme-switch/gtk-theme-switch_2.1.0-3.dsc Changes since the last upload: * New maintainer (Closes: #588836) * Bump debhelper compat to 9 * Bump Standards-Version to 3.9.4 * Fix spelling error in help * Use dh-style debian/rules * Add hardening * Exit cleanly if there is no HOME environment variable (Closes: #716007) * Remove some useless dependencies * Update copyright to DEP5 format -- Marius Gavrilescu signature.asc Description: Digital signature ---End Message--- ---BeginMessage--- The package has been uploaded to unstable -- Marius Gavrilescu signature.asc Description: Digital signature ---End Message---
Bug#701870: marked as done (RFS: aspsms-t/1.3.1-1 [ITP])
Your message dated Fri, 19 Jul 2013 16:23:47 + with message-id e1v0dt9-0005xh...@quantz.debian.org and subject line closing RFS: aspsms-t/1.3.1-1 [ITP] has caused the Debian Bug report #701870, regarding RFS: aspsms-t/1.3.1-1 [ITP] 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.) -- 701870: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701870 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: wishlist Dear mentors, A long time ago, that I've sent a RFS request to debian-mentors [1]. Accidentally the package was removed by mentors [2] and I didn't notice that. So I've uploaded it again. ITP bug for this package is available at [3]. [1] http://lists.debian.org/debian-mentors/2012/02/msg6.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658835 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645103 I am looking for a sponsor for my package aspsms-t * Package name: aspsms-t Version : 1.3.1-1 Upstream Author : Marco Balmer ma...@balmer.name * URL : https://github.com/micressor/aspsms-t * License : GPL Section : net It builds those binary packages: aspsms-t - sms transport for your xmpp/jabber server libaspsms-perl - Perl module providing an easy sms interface To access further information about this package, please visit the following URL: http://mentors.debian.net/package/aspsms-t Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/aspsms-t/aspsms-t_1.3.1-1.dsc More information about hello can be obtained from http://www.example.com. Regards, Marco Balmer ---End Message--- ---BeginMessage--- Package aspsms-t has been removed from mentors.---End Message---
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi,
intrigeri wrote (04 Jul 2013 06:49:08 GMT) :
I plan to review, and hopefully upload bilibop next week.
Here we go.
First, was the target distribution change in debian/changelog
intentional? (0.4.12 has experimental, 0.4.13 has unstable.)
Second, it looks like important changes and refactoring are flowing in
rather quickly, so I'd like to check that you are confident with the
current state of bilibop, and believe it is stable enough to be part
of a Debian release. Do you confirm this?
Also, please keep in mind that once bilibop is uploaded to Debian, the
responsibility of backward compatibility will be yours, as the
maintainer. This being said, while I certainly wouldn't mind a bit
more abstraction / factorization at some places, the code looks solid
enough :)
Some nitpicking follows, that should be fixed before the initial
upload IMHO:
+myshell=$(awk -F: \$1 ~ /$(whoami)/ {print \$NF} /etc/passwd)
Maybe use `getent' instead?
Also Lintian says:
I: bilibop-common: spelling-error-in-manpage
usr/share/man/man1/drivemap.1.gz informations information
... and a few others, so you probably want to run it in verbose /
pedantic mode and take the results into account.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/854nbqh0g2@boum.org
Bug#717262: ITP missing for package curseofwar with RFS 717262 with ITP in title
I had read the documentation I understand the process. Now I have to find a sponsor for finish it. Thanks. 2013/7/19 Anton Balashov sicn...@darklogic.ru Hello, again. I made it: 717...@bugs.debian.org Could you please hint me what should be next? 2013/7/19 Mònica Ramírez mon...@debian.org El dv 19 de 07 de 2013 a les 09:16 +0400, en/na Anton Balashov va escriure: Thank you for your pay attention on that. I made a new letter: From: Anton Balashov sicn...@darklogic.ru To: sub...@bugs.debian.org Subject: ITP: curseofwar/1.1.4-1 With the same text. Is that right? No, you should open an ITP bug in wnpp package. Please, close this last bug sending a mail to 717304-cl...@bugs.debian.org and open another one in wnpp package following the steps wou'll find here: http://www.debian.org/devel/wnpp/ (section Using WNPP) Once you've opened this bug, you should close it in your debian/changelog file. Thanks for your work!
Re: Empty binary package
Hi Tong, On 19-07-13 15:14, T o n g wrote: On Fri, 19 Jul 2013 08:38:49 +0200, Paul Gevers wrote: Which I don't have anymore, so indeed please repeat it if you want my help. It was still included in the message that I previously replied. Sure. therefore the word indeed. - I then build the upstream into *source package* with 'debuild -S -sa', and then build the binary debian package *from this source package*. The binary package built this way is however empty. So how do you do the last step? And why is building from your source package any different than your first step with -us -uc? What do you do EXACTLY when you build from the source package, i.e. please provide all the copy and build commands. It is NOT empty if I try it The last steps are just as normal. Sorry, but what means as normal for you? What command do you use? $ debian/rules binary $ debuild # in the source tree $ some-other-fancy-command $ pdebuild # as I did I'll get back to you in specific details later, but again just as normal. Meanwhile, when I said that the binary package is empty, as I explained in my OP, I meant that the built binary package will not contains the files that I want. I.e., it contains nothing except the copyright changelog files. That part was fully clear to me. And as I said, in my tries it was always there. Did you try to build debian binary package from there? So please tell me what you mean with this sentence, I just don't know what you mean. As a reference, you can also build from my source package (which has fixed all the problems you told me to fix): http://mentors.debian.net/debian/pool/main/libp/libpam-ssh-agent-auth/ libpam-ssh-agent-auth_0.9.5-2.dsc Now we are getting somewhere. At least we can see what you have been trying and inspect your commands. You have two build targets in your rules file. The second overwrites the first results and installs to a weird location: /usr/bin/install -c -m 644 pam_ssh_agent_auth.8 /tmp/buildd/libpam-ssh-agent-auth-0.9.5/debian/tmp/tmp/buildd/libpam-ssh-agent-auth-0.9.5/debian/tmp/usr/share/man/cat8/pam_ssh_agent_auth.8 And see if you can get anything other than the copyright changelog files into the binary package. Sure, remove the second build target and additionally, there are several control files that need renaming as you renamed the package. pam-ssh-agent-auth.* need to renamed to libpam-ssh-agent-auth.* if that is the name of your package. These files contain instructions for dh_* commands. Fixing those two issues, the package builds again with files in the deb. Of course this doesn't mean your finished, but at least you can proceed from there. Paul signature.asc Description: OpenPGP digital signature
Bug#717360: RFS: niceshaper/1.0.0-2 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package niceshaper * Package name: niceshaper Version : 1.0.0-2 Upstream Author : Mariusz Jedwabny mari...@jedwabny.net * URL : http://niceshaper.jedwabny.net/ * License : GPLv2+ Section : net It builds those binary packages: niceshaper - Dynamic traffic shaper To access further information about this package, please visit the following URL: http://mentors.debian.net/package/niceshaper Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/niceshaper/niceshaper_1.0.0-2.dsc More information about niceshaper can be obtained from http://niceshaper.jedwabny.net. Changes since the last upload: niceshaper (1.0.0-2) unstable; urgency=low * Initial release. (Closes: #717124) -- Mariusz Jedwabny mari...@jedwabny.net Tue, 16 Jul 2013 21:05:16 +0200 Regards, Mariusz Jedwabny -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/sig.0912d30b8f.20130719184802.7260.26766.reportbug@mj
Re: dependent packages blocked from testing
Am Freitag, den 19.07.2013, 13:02 +0600 schrieb Andrey Rahmatullin: On Fri, Jul 19, 2013 at 07:53:51AM +0200, Tobias Frost wrote: Ltt-controls has not been built on all archs (those out of date messages on the PTS). Seems that there are build deps not available. (Take a look at the buildds status page) It waits for ust to be built on ia64, mips, mipsel, s390, s390x and sparc. Ok, lets analyze buildd's status page says: Dependency installability problem for ltt-control on hurd-i386, kfreebsd-amd64 and kfreebsd-i386: ltt-control (= 2.1.1-2) build-depends on missing: - liburcu-dev (= 0.7.4) So on the above archs, it does not build due to problems with liburcu-dev. But as this archs are never built before, so they are not blocking the transistion. Of course, you could take a look at liburcu if you can fix the FTBFs... Out of those, ia64 build just fails while mips, mipsel, s390x and sparc need systemtap-sdt-dev, which does not exist on those arches for at least quite some time. s390 has No entry in s390 database which I have no idea about. Yes, for those archs you'll need fix ust, which has problems with systemtap-sdt-dev. As Systemtap-sdt-dev is only available for i386 amd64 ia64 s390 powerpc armel armhf, you 1) (if possible) configure ust to not use systemtap-sdt on the other archs (I do this for example in drizzle, there drizzle's configure automatically checks if it is available and does not utilize it if not -- of course debian/control then needs arch-dependent build-dependencies) 2) only build for those archs where system-tap is available. Note: You need to file an remove request for the old version on the unsupported archs for ust, as they otherwise will block the transition. (If you go for 2), the rm requests are also needed for ltt-control) coldtobi Jon Bernard jbern...@debian.org schrieb: Hello, I'm facing a problem with two packages that are blocked from migrating into testing. I'm having trouble seeing a clear path forward and I wonder if anyone could point me in a better direction. The specific packages are ltt-control[1] and ust[2]. If the source packages only built a single binary package, then apt's arbitrary selection of one to break the dependency chain would work, from what I understand. But in this case each source package builds several binary packages and I do not see a clean way out of this (other than asking the release team to manually move them, but I would prefer to find a proper solution). Is there any advise for this situation? Specifically, how do I get out of this mess cleanly, and what could I have done differently to prevent this from ever happening? [1]: http://release.debian.org/migration/testing.pl?package=ltt-control [2]: http://release.debian.org/migration/testing.pl?package=ust Cheers, -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374273797.7060.25.ca...@ithilien.loewenhoehle.ip
Bug#699846: marked as done (RFS: xorg-gtest/0.7.1-1 [ITP])
Your message dated Fri, 19 Jul 2013 16:23:45 + with message-id e1v0dt7-0005xb...@quantz.debian.org and subject line closing RFS: xorg-gtest/0.7.1-1 [ITP] has caused the Debian Bug report #699846, regarding RFS: xorg-gtest/0.7.1-1 [ITP] 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.) -- 699846: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699846 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my NEW package xorg-gtest * Package name: xorg-gtest Version : 0.7.0-1 Upstream Author : Peter Hutterer peter.hutte...@who-t.net * URL : http://cgit.freedesktop.org/xorg/test/xorg-gtest/ * License : MIT/X Section : libs It builds those binary packages: libxorg-gtest-data - X.Org dummy testing environment for Google Test - data libxorg-gtest-dev - X.Org dummy testing environment for Google Test - headers libxorg-gtest-doc - X.org dummy testing environment for Google Test - documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/xorg-gtest Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/x/xorg-gtest/xorg-gtest_0.7.0-1.dsc More information about xorg-gtest can be obtained from https://launchpad.net/xorg-gtest. Changes since the last upload: xorg-gtest (0.7.0-1) UNRELEASED; urgency=low * initial Debian release (closes: #699403) Regards, Stephen M. Webb ---End Message--- ---BeginMessage--- Package xorg-gtest has been removed from mentors.---End Message---
Bug#717262: ITP missing for package curseofwar with RFS 717262 with ITP in title
Hello, again. I made it: 717...@bugs.debian.org Could you please hint me what should be next? 2013/7/19 Mònica Ramírez mon...@debian.org El dv 19 de 07 de 2013 a les 09:16 +0400, en/na Anton Balashov va escriure: Thank you for your pay attention on that. I made a new letter: From: Anton Balashov sicn...@darklogic.ru To: sub...@bugs.debian.org Subject: ITP: curseofwar/1.1.4-1 With the same text. Is that right? No, you should open an ITP bug in wnpp package. Please, close this last bug sending a mail to 717304-cl...@bugs.debian.org and open another one in wnpp package following the steps wou'll find here: http://www.debian.org/devel/wnpp/ (section Using WNPP) Once you've opened this bug, you should close it in your debian/changelog file. Thanks for your work!
Re: Empty binary package
On Fri, 19 Jul 2013 21:57:14 +0200, Paul Gevers wrote: - I then build the upstream into *source package* with 'debuild -S -sa', and then build the binary debian package *from this source package*. The binary package built this way is however empty. So how do you do the last step? And why is building from your source package any different than your first step with -us -uc? What do you do EXACTLY when you build from the source package, i.e. please provide all the copy and build commands. It is NOT empty if I try it The last steps are just as normal. Sorry, but what means as normal for you? What command do you use? $ debian/rules binary $ debuild # in the source tree $ some-other-fancy-command $ pdebuild # as I did debuild -us -uc Did you try to build debian binary package from there? So please tell me what you mean with this sentence, I just don't know what you mean. build debian binary package from the source package that you just built. I'll get back to you in specific details later, but again just as normal. This is EXACTLY what I did (in a empty directory): dget http://mentors.debian.net/debian/pool/main/libp/libpam-ssh-agent- auth/libpam-ssh-agent-auth_0.9.5-2.dsc dpkg-source -x *.dsc cd libpam-ssh-agent-auth-0.9.5/ debuild -us -uc As normal as building any binary package to me. The binary package built this way is empty. Meanwhile, when I said that the binary package is empty, as I explained in my OP, I meant that the built binary package will not contains the files that I want. I.e., it contains nothing except the copyright changelog files. That part was fully clear to me. And as I said, in my tries it was always there. So you did the above normal steps as building any binary package but get different result? Or did you do something more than normal? As a reference, you can also build from my source package (which has fixed all the problems you told me to fix): http://mentors.debian.net/debian/pool/main/libp/libpam-ssh-agent-auth/ libpam-ssh-agent-auth_0.9.5-2.dsc Now we are getting somewhere. At least we can see what you have been trying and inspect your commands. You have two build targets in your rules file. The second overwrites the first results and installs to a weird location: /usr/bin/install -c -m 644 pam_ssh_agent_auth.8 /tmp/buildd/libpam-ssh-agent-auth-0.9.5/debian/tmp/tmp/buildd/libpam- ssh-agent-auth-0.9.5/debian/tmp/usr/share/man/cat8/pam_ssh_agent_auth.8 And see if you can get anything other than the copyright changelog files into the binary package. Sure, remove the second build target Are you saying changing the line binary: binary-indep binary-arch into: binary: binary-indep # binary-arch to remove the second binary build target? I got the following error when doing that: /usr/bin/install -c -m 644 pam_ssh_agent_auth.8 /systems/b/libpam-ssh- agent-auth/test-mine/libpam-ssh-agent-auth-0.9.5/debian/tmp/usr//share/ man/man8/pam_ssh_agent_auth.8 /usr/bin/install -c -m 755 pam_ssh_agent_auth.so /systems/b/libpam-ssh- agent-auth/test-mine/libpam-ssh-agent-auth-0.9.5/debian/tmp/lib/security/ pam_ssh_agent_auth.so make[1]: Leaving directory `/systems/b/libpam-ssh-agent-auth/test-mine/ libpam-ssh-agent-auth-0.9.5' dpkg-genchanges ../libpam-ssh-agent-auth_0.9.5-2_i386.changes dpkg-genchanges: error: cannot read files list file: No such file or directory dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed If you talked about the build %: dh $@ line, I put them there because I want to fix the following lintian issues: W: libpam-ssh-agent-auth source: debian-rules-missing-recommended- target build-arch W: libpam-ssh-agent-auth source: debian-rules-missing-recommended- target build-indep How else should I fix it then? and additionally, there are several control files that need renaming as you renamed the package. pam-ssh-agent-auth.* need to renamed to libpam-ssh-agent-auth.* if that is the name of your package. These files contain instructions for dh_* commands. Fixing those two issues, the package builds again with files in the deb. Thanks -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kscv5i$d9v$1...@ger.gmane.org
Re: Empty binary package
On Sat, 20 Jul 2013 03:11:46 +, T o n g wrote: Did you try to build debian binary package from there? So please tell me what you mean with this sentence, I just don't know what you mean. build debian binary package from the source package that you just built. I'll get back to you in specific details later, but again just as normal. This is EXACTLY what I did (in a empty directory): dget http://mentors.debian.net/debian/pool/main/libp/libpam-ssh-agent- auth/libpam-ssh-agent-auth_0.9.5-2.dsc dpkg-source -x *.dsc cd libpam-ssh-agent-auth-0.9.5/ debuild -us -uc As normal as building any binary package to me. The binary package built this way is empty. Meanwhile, when I said that the binary package is empty, as I explained in my OP, I meant that the built binary package will not contains the files that I want. I.e., it contains nothing except the copyright changelog files. That part was fully clear to me. And as I said, in my tries it was always there. So you did the above normal steps as building any binary package but get different result? Or did you do something more than normal? My bad. Revisiting my work log, I suddenly realized the source package that I built from is not the one that I built from the upstream source but my already tweaked one. Thanks for your tip on renaming the control files. Now my binary package is no longer empty any more. Sure, remove the second build target Are you saying changing the line binary: binary-indep binary-arch into: binary: binary-indep # binary-arch to remove the second binary build target? [ . . .] If you talked about the build %: dh $@ line, I put them there because I want to fix the following lintian issues: W: libpam-ssh-agent-auth source: debian-rules-missing-recommended- target build-arch W: libpam-ssh-agent-auth source: debian-rules-missing-recommended- target build-indep How else should I fix it then? So this is the remaining issue for me so far (As you can see I've tried to find the answer myself and using the build %:\n\tdh $@ is the answer that I found). Thanks -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ksd3qv$cml$1...@ger.gmane.org
