Replacing roxterm's multiple binary packages with one
I've decided to discontinue support for legacy libraries in roxterm and concentrate on GTK3 and vte-2.91 and I want to simplify the packaging because of this. The current/old version has these binary packages: roxterm-common (data files, roxterm-gtk2 and roxterm-gtk3 depend on it) roxterm-gtk2, roxterm-gtk3 (binaries) roxterm-gtk2-dbg, roxterm-gtk3-dbg (corresponding debugging symbols) roxterm (virtual package depending on roxterm-gtk3) I want to replace them with a single package, roxterm. I'm not quite sure how to set up the package relationships to do this. I would like the new roxterm to automatically replace roxterm-gtk3, so I think I need to add Replaces: roxterm-gtk3 to the new roxterm, and AFAICT from the policy manual I should use Breaks as well (rather than Conflicts). The main complication is that I don't want to use Replaces: roxterm-gtk2 in case some people want to hang on to that for as long as possible (GTK3 windows with geometry don't work properly with some window managers, for instance), and having the new version wanting to replace it at every dist-upgrade would be a nuisance for them. So should I add Breaks: roxterm-common, roxterm-gtk2 without a corresponding Replaces? Anything else? Should the new roxterm also be marked Breaks older versions of its namesake? Also, I don't want a separate package for the sake of debugging symbols. Is it OK to include them in the main package and override lintian, or is it mandatory to use a separate -dbg package? If so, my preference would be to exclude the debugging symbols for the sake of the simplicity of a single binary package. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5575bacd.8080...@realh.co.uk
Bug#776571: marked as done (RFS: svg.path/2.0~b1-1 -- [ITP] Python modules providing SVG objects)
Your message dated Mon, 08 Jun 2015 22:01:24 +0200 with message-id 5575f494.3020...@danielstender.com and subject line RFS: svg.path/2.0~b1-1 -- [ITP] Python modules providing SVG objects has caused the Debian Bug report #776571, regarding RFS: svg.path/2.0~b1-1 -- [ITP] Python modules providing SVG objects 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.) -- 776571: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776571 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: wishlist Hello, I am looking for a sponsor for my package of svg.path: * Package name: svg.path Version : 2.0b1 Upstream Author : Lennart Regebro rege...@gmail.com * URL : https://github.com/regebro/svg.path * License : CC0-1.0 Programming Lang: Python Description : Python library providing SVG path objects and parser It builds those binary packages: python-svg.path - SVG path objects and parser for Python python3-svg.path - SVG path objects and parser for Python3 Description: SVG path objects and parser for Python In SVG (Scalable Vector Graphics), paths are used to draw simple or compounded shape outlines. svg.path is a collection of objects that implement the path commands in SVG (Line, Arc, QuadraticBezier, CubicBezier), and a parser for SVG path definitions. Buildlog: http://www.danielstender.com/buildlogs/svg.path_2.0~b1-1_amd64-20150129-1319.build For a member of this group, I've already put it under the care of the DPMT: http://anonscm.debian.org/viewvc/python-modules/packages/svg.path/trunk/ And uploaded it to Mentors: http://mentors.debian.net/package/svg.path dget -x http://mentors.debian.net/debian/pool/main/s/svg.path/svg.path_2.0~b1-1.dsc Thank you very much for considering, Daniel Stender -- http://qa.debian.org/developer.php?login=debian%40danielstender.com 4096R/DF5182C8 46CB1CA89EA3B74376761DB915E09AF4DF5182C8 ---End Message--- ---BeginMessage--- I've lost interest in this package being a preliminary for Hovercraft [1]. If somebody wants to take up the preparatory work that's all right with me (but if you would please mention me in deb/copyright). [1] https://bugs.debian.org/775016 RFP: hovercraft -- impress.js presentations by reStructuredText -- http://qa.debian.org/developer.php?login=debian%40danielstender.com 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8---End Message---
Bug#780793: marked as done (RFS: hovercraft/2.0~b1+dfsg-1 [ITP] --- impress.js presentations by reStructuredText)
Your message dated Mon, 08 Jun 2015 21:44:06 +0200 with message-id 5575f086.70...@danielstender.com and subject line RFS: hovercraft/2.0~b1+dfsg-1 [ITP] --- impress.js presentations by reStructuredText has caused the Debian Bug report #780793, regarding RFS: hovercraft/2.0~b1+dfsg-1 [ITP] --- impress.js presentations by reStructuredText 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.) -- 780793: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780793 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: wishlist Hello mentors, I am looking for a sponsor for my package of hovercraft [1]. The software is written in Python and generates beautiful impress.js based presentations which could be displayed in a browser [2], from reST sources. I've git-ized the source at collab maint [3] for now, but would like to put it under the umbrella of the PAPT - the repo could be transfered to git.debian.org/git/python-applications when it becomes available with ease (Vcs- fields kept blank). The dfsg- packaging is to take out a Python logo image which is shipped in the orig for the examples and the tests [4]. I've patched the examples but disabled the tests for now. They need python3-manuel, which is not yet available [5], anyway. I'm going to ask upstream if the image could be replaced for the next release, then. The status of the binary deps not-yet-in-unstable is, python3-watchdog is currently in NEW, python3-svg.path is also RFS [6]. The package has been uploaded to Mentors: http://mentors.debian.net/package/hovercraft http://mentors.debian.net/debian/pool/main/h/hovercraft/hovercraft_2.0~b1+dfsg-1.dsc Buildlog: http://www.danielstender.com/buildlogs/hovercraft_2.0~b1+dfsg-1_amd64-20150319-1332.build Thank you for considering a sponsorship, Daniel Stender [1] https://github.com/regebro/hovercraft [2] http://bartaz.github.io/impress.js/ [3] http://anonscm.debian.org/cgit/collab-maint/hovercraft.git [4] https://lists.debian.org/debian-legal/2015/03/msg3.html [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776885 [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776571 -- http://qa.debian.org/developer.php?login=debian%40danielstender.com 4096R/DF5182C8 46CB1CA89EA3B74376761DB915E09AF4DF5182C8 ---End Message--- ---BeginMessage--- I've lost the interest in this package. If somebody else wants to pick up the preparatory work you're welcome (but please mention me in deb/copyright) Thanks, Daniel Stender -- http://qa.debian.org/developer.php?login=debian%40danielstender.com 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8---End Message---
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi Vincent, I've removed bzr from the build dependencies. After fiddling with the get-orig-source a bit, I realized that I can't get the same checksum either when running it multiple times. According to a 'diff' of 'tar -tvf' output, the only difference between these generated tarballs was the source files' timestamps. This is probably because bzr is used to fetch the sources every time get-orig-source is ran, and it saves the current time (of checkout) as the timestamp of the files, instead of the code's modification date. For this, there appears to be a wishlist bug filed: https://bugs.launchpad.net/bzr/+bug/245170 Best, James On 07/06/15 11:17 PM, Vincent Cheng wrote: Hi James, (Sorry for the late reply!) On Tue, May 19, 2015 at 11:28 AM, James Lu glol...@hotmail.com wrote: Hello Vincent, Okay, I've uploaded a newer version of the package that should fix the problems you mentioned. Earlier, I was trying to manually sync up both Karolina's and upstream's debian/ folders (they had different content, like build-dep versions, etc.), and I must have missed the watch file. I also added a get-orig-source to debian/rules, which pulls the revision from Launchpad bzr, removes the INSTALL symlink, and then repacks. debian/clean is removed and the changelog is also more verbose now. You don't need to declare a build-dep on bzr because it's only used by d/rules get-orig-source, not during the build itself (to be precise, Policy §7.7 specifies the specific d/rules targets in which the dependencies listed in various d/control fields must be satisfied to invoke them; get-orig-source is not one of these targets), so please remove bzr from your build-deps. The orig tarball you've uploaded to mentors seems to differ from a tarball that I've generated locally using your get-orig-source target (i.e. hashsums don't match). Regards, Vincent -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/blu436-smtp100cf3d37eb39e7144ac85df5...@phx.gbl
Bug#775284: marked as done (RFS: linuxptp/1.5-3 [ITP])
Your message dated Mon, 08 Jun 2015 09:56:07 +0200 with message-id 55754a97.8090...@debian.org and subject line RFS for linuxptp has caused the Debian Bug report #775284, regarding RFS: linuxptp/1.5-3 [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.) -- 775284: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775284 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package linuxptp Package name: linuxptp Version : 1.5-1 Upstream Author : Richard Cochran richardcoch...@gmail.com URL : http://linuxptp.sourceforge.net/ License : GPL-2+ Section : utils It builds those binary packages: linuxptp - Precision Time Protocol (PTP, IEEE1588) implementation for Linux To access further information about this package, please visit the following URL: http://mentors.debian.net/package/linuxptp Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/linuxptp/linuxptp_1.5-1.dsc More information about LinuxPTP can be obtained from http://linuxptp.sourceforge.net/ Regards, Tino Mettler ---End Message--- ---BeginMessage--- linuxptp has found a sponsor (me). the package is currently in the NEW queue, awaiting approval from ftp-masters. gfmdsar IOhannes signature.asc Description: OpenPGP digital signature ---End Message---
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi James, (Sorry for the late reply!) On Tue, May 19, 2015 at 11:28 AM, James Lu glol...@hotmail.com wrote: Hello Vincent, Okay, I've uploaded a newer version of the package that should fix the problems you mentioned. Earlier, I was trying to manually sync up both Karolina's and upstream's debian/ folders (they had different content, like build-dep versions, etc.), and I must have missed the watch file. I also added a get-orig-source to debian/rules, which pulls the revision from Launchpad bzr, removes the INSTALL symlink, and then repacks. debian/clean is removed and the changelog is also more verbose now. You don't need to declare a build-dep on bzr because it's only used by d/rules get-orig-source, not during the build itself (to be precise, Policy §7.7 specifies the specific d/rules targets in which the dependencies listed in various d/control fields must be satisfied to invoke them; get-orig-source is not one of these targets), so please remove bzr from your build-deps. The orig tarball you've uploaded to mentors seems to differ from a tarball that I've generated locally using your get-orig-source target (i.e. hashsums don't match). Regards, Vincent -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczd_tcjsl0trtci6zuq-s-yxxpsykxq3aowr_jxcjfnr9s...@mail.gmail.com
Compile Kernel 32 bits on an 64 bits machine: initramfs
Hi all, I am running a Debian 8 machine and I need to compile a 32 bits kernel using this system, I have managed to compile the kernel using the package linux-source-3.16 and it boots fine exporting CFLAGS=-m32 to cross compile. Basically: export CFLAGS=-m32 make make modules_install make install Unfortunately I get a boot error when starting the init process: 3.669383] Failed to execute /init (error -8) [3.671425] request_module: runaway loop modprobe binfmt-464c [3.672133] Starting init: /sbin/init exists but couldn't execute it (error -8) [3.674272] request_module: runaway loop modprobe binfmt-464c [3.675064] Starting init: /bin/sh exists but couldn't execute it (error -8) [3.675072] Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance. [3.675082] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.16.7-ckt9 #8 My thought is that the initramfs created from the 64 bits host does contain 64 bits executables and nothing can work that way. What's your reckon ? If my thought is correct where could I find a pre-generated initramfs to use with such kernel version, or do you have any other solution ? Thanks, Pietro -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1433781952.2560.12.ca...@aol.com