Re: Bug#754260: RFS: terminology/0.6.0-1 [ITP]
The new version appears to work for me. Thanks very much for testing it again. By the way, do you happen to know if terminology is supposed to replace eterm, or are both going to live together? They are certainly not the same thing, i'll simply put in the lead enlightenment devs response to someone else from the irc channel yesterday: Jul 14 03:36:25 bunjiboys Hi, after a reinstall of my Debian box, I am no longer able to get Eterm working. When i try to start it, it opens the window just fine, but it never opens the shell. I tried settings different commands to run using the -e switch to change what to execute, but it seems like it never gets to that point. After running with both strace and --debug it looks like it is stuck in a loop trying to read a socket (/tmp/.X11-unix/X0). Strace output: https://bunjiboys raster bunjiboys: no idea raster i havent used eterm for over a decade raster also note - thats the socket use to ttalk to x raster so its talking to x all day raster thats how you draw or get input raster i use terminology raster it's actively developed raster and uses modern efl raster eterm does not bunjiboys I was hoping not to have to change terms, been using Eterm for well over a decade now, just so used to it :) raster then get used to it not working raster or fix it yoursefl raster http://git.enlightenment.org/apps/eterm.git/ raster thats the activity on it raster one commit in march raster another janruary last year raster anoither in 2012 raster etc. raster not very active bunjiboys yeah, guess I do need to start shopping around for alternatives cippp for sure you will like terminology raster terminology is a far cry from eterm raster it is pretty different raster on the fancy-side it does a whole host more bunjiboys well, i didnt really use most of the features of Eterm, I disabled all the UI stuff and so on, its probably more an Ive always used it, so Ill keep using it thing bunjiboys Although, having been working on OSX recently, I wouldnt mind something that comes a little closer to iTerm2 raster well then... you'll be needing to do your own debugging raster as such enlightenment has moved on raster we build on efl raster (our libs) raster eterm does not raster it is effectively not part of enlightenment as a project anymore raster it's legacy we don't work on, support etc. raster it doesn't use our library infra raster and doesn't even visually fit in bunjiboys my point was that I'm not against finding something else, just never looked raster sure raster just saying that if you don't move - you're not going to get any help here raster terminology is the e terminal raster it uses efl raster it's modern raster http://www.enlightenment.org/p.php?p=about/terminologyl=en
Bug#740032: sweethome3d-textures: new upstream release 1.0.1
Control: reopen -1 Uploaded new upstream version 1.0.1: http://mentors.debian.net/package/sweethome3d-textures dget -x http://mentors.debian.net/debian/pool/main/s/sweethome3d-textures/sweethome3d-textures_1.0.1-1.dsc Thanks. -- 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/20140715084244.GA32007@jessie01
Bug#751438: marked as done (RFS: pantomime/1.2.2~r289+dfsg-1 [RC])
Your message dated Tue, 15 Jul 2014 12:50:11 +0200 with message-id 53c50763.2010...@wollumbin.marsaxlokk.dhcp.io and subject line Fwd: pantomime1.2_1.2.2~r289+dfsg-1_amd64.changes ACCEPTED into unstable has caused the Debian Bug report #751438, regarding RFS: pantomime/1.2.2~r289+dfsg-1 [RC] 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.) -- 751438: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751438 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package pantomime. It builds these binary packages: libpantomime1.2 - GNUstep framework for mail handling (runtime library) libpantomime1.2-dev - GNUstep framework for mail handling (development files) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pantomime Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pantomime/pantomime_1.2.2~r289+dfsg-1.dsc Changes since the last upload: * New upstream release: - Fixes a crash in CWService when self gets deallocated while reading/writing data (Closes: #750217). * debian/watch: Replace stub with a working one. * debian/repack: New script to repack the upstream tarball. * debian/source/format: Switch to 3.0 (quilt). * debian/README.source: Delete. * debian/control: Rename the package back to `pantomime'. (Build-Depends): Remove quilt. (Homepage): Remove, new upstream maintainer but no homepage yet. (Vcs-Git, Vcs-Browser): Use canonical URIs. (Standards-Version): Bump to 3.9.5; no changes needed. * debian/rules: Don't include patchsys-quilt.mk. (LDFLAGS): Define with `+=' to get the value from dpkg-buildflags. (DEB_MAKE_INVOKE): Add OBJCFLAGS. * debian/patches/compilation-errors.patch: Remove; fixed upstream. * debian/patches/compilation-warnings.patch: Remove hunks applied upstream, fix more issues (Closes: #749762). * debian/patches/check-return-result.patch: New; check the return result of some functions and provide better logging (Closes: #461453). * debian/patches/series: Update. * debian/copyright: Switch to format 1.0, update copyright years/holders. ---End Message--- ---BeginMessage--- Original Message Subject: pantomime1.2_1.2.2~r289+dfsg-1_amd64.changes ACCEPTED into unstable Date: Tue, 15 Jul 2014 10:48:40 + From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: Debian GNUstep maintainers pkg-gnustep-maintain...@lists.alioth.debian.org, Yavor Doganov ya...@gnu.org, elb...@debian.org Accepted: Format: 1.8 Date: Fri, 11 Jul 2014 21:24:50 +0300 Source: pantomime1.2 Binary: libpantomime1.2 libpantomime1.2-dev Architecture: source amd64 Version: 1.2.2~r289+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Debian GNUstep maintainers pkg-gnustep-maintain...@lists.alioth.debian.org Changed-By: Yavor Doganov ya...@gnu.org Description: libpantomime1.2 - GNUstep framework for mail handling (runtime library) libpantomime1.2-dev - GNUstep framework for mail handling (development files) Closes: 461453 749762 750217 Changes: pantomime1.2 (1.2.2~r289+dfsg-1) unstable; urgency=medium . * New upstream release: - Fixes a crash in CWService when self gets deallocated while reading/writing data (Closes: #750217). * debian/watch: Replace stub with a working one. * debian/repack: New script to repack the upstream tarball. * debian/source/format: Switch to 3.0 (quilt). * debian/README.source: Delete. * debian/control (Section): Change to libs. (Build-Depends): Remove quilt. (Homepage): Remove, new upstream maintainer but no homepage yet. (Vcs-Git, Vcs-Browser): Use canonical URIs. (Standards-Version): Bump to 3.9.5; no changes needed. * debian/rules: Don't include patchsys-quilt.mk. (LDFLAGS): Define with `+=' to get the value from dpkg-buildflags. (DEB_MAKE_INVOKE): Add OBJCFLAGS. * debian/patches/compilation-errors.patch: Remove; fixed upstream. * debian/patches/compilation-warnings.patch: Remove hunks applied upstream, fix more issues (Closes: #749762). * debian/patches/check-return-result.patch: New; check the return result of some functions and provide better logging (Closes: #461453). * debian/patches/series: Update. * debian/copyright: Switch to format 1.0, update copyright years/holders. Checksums-Sha1: 163d75616bf835372a9cd353550fc8cf5c5a62ae 1761
Bug#754870: RFS: systempreferences.app/1.2.0-1 -- GNUstep preferences application
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package systempreferences.app. It builds these binary packages: libpreferencepanes-dev - GNUstep preferences library - development files libpreferencepanes1 - GNUstep preferences library - runtime library systempreferences.app - GNUstep preferences application systempreferences.app-dbg - GNUstep preferences application - debugging symbols To access further information about this package, please visit the following URL: http://mentors.debian.net/package/systempreferences.app Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/systempreferences.app/systempreferences.app_1.2.0-1.dsc Changes since the last upload: * New upstream release: - Compatible with current GNUstep libraries (Closes: #749793). * debian/source/format: Switch to 3.0 (quilt). * debian/compat: Set to 9. * debian/control (Build-Depends): Remove quilt. Require libgnustep-gui-dev (= 0.24) and debhelper (= 9). (libpreferencepanes-dev, libpreferencepanes1) (systempreferences.app-dbg): New packages. Split the library as GWorkspace needs it. Adjust package relationships accordingly. (Vcs-Arch): Replace with Vcs-Git and Vcs-Browser. (Standards-Version): Claim compliance with 3.9.5 as of this release. * debian/rules: Update for modern dh. Enable hardening. * debian/README.source: Delete. * debian/manpages: * debian/systempreferences.app.install: * debian/libpreferencepanes-dev.install: * debian/libpreferencepanes1.install: * debian/libpreferencepanes1.lintian-overrides: New files. * debian/SystemPreferences.desktop: Add Keywords field. * debian/copyright: Switch to format 1.0. -- 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/87iomyq3a1@yavor.doganov.org
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
Control: owner -1 ! Control: tags -1 moreinfo Hi Yavor, Before I upload this package to the new queue, could you please comment on the lintian errors about missing source? I am looking for a statement like: I added lintian overrides for these files as the source is available several directories higher. What is more, I made sure that these files are actually build during the package building to prove they are DFSG-free by doing and I added them to the clean target by adding a debian/clean file with the appropriate content. I provided a patch to upstream to make sure these files are removed on clean by the regular build system. I also made sure that these files were used in the appropriate way during build. (I haven't checked the content, but these files should be used to test the build, no?) Paul signature.asc Description: OpenPGP digital signature
Re: Gatejs needs a mentor
Le mardi 15 juillet 2014 à 09:04 +0400, Michael Vergoz a écrit : Hi I'm working on gatejs which is a reverse forward proxy made using javascript (nodejs). It is under the GPLv3 We would like to port it for Debian. Is there someone to help me to do that ? https://github.com/binarysec/gate https://github.com/binarysec/gateGhost Thanks in advance Michael -- Michael Vergoz BinarySEC You might want to visit pkg-javascript team https://wiki.debian.org/Javascript Jérémy. -- 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/1405426996.20229.1.camel@imac.chaumes
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
Hi Yavor, And an additional remark: the COPYING file and the headers in several (all?) source files don't match. The COPYING file says LGPL-2.1+ while the headers say LGPL-2+. Please update your d/copyright file to match the situation. Paul signature.asc Description: OpenPGP digital signature
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
On 15-07-14 14:54, Yavor Doganov wrote: Paul Gevers wrote: Before I upload this package to the new queue, could you please comment on the lintian errors about missing source? The reason for these is gnustep-make's incapable dist rule, combined with not so careful upstream. I am looking for a statement like: I added lintian overrides... Hmm, but I have not overridden them, I don't feel I should. I have informed upstream and I hope it won't happen in subsequent releases. Well, to document this fact is exactly why an override would be nice. But I understand you position, I guess you just want to prevent it happens again next time, right? But think of people other than you working on the package (e.g. me or anybody in the future that needs to NMU the package). I haven't checked, but ftp-masters use also several lintian checks as auto-reject. So maybe this is even needed to pass the NEW queue. I'm not cleaning them explicitly either as gnustep-make's distclean rule does that. There's little I can do given that the object files are in the .orig tarball; adding a lintian override won't change that. Well, the source has to be DFSG-free. How we guarantee that usually is by building everything from source during the build. If you don't want to build it, you have to remove them from source and repack (I had to do that for some releases of one of my upstreams as well). It is an annoyance, sure, but necessary if we uphold the social contract. So, either remove the files from the source, or build during build. Yes and no. They depend on a test framework that is not packaged for Debian, so they're unused for the debian package build. Ack. As for the license, debian/copyright is correct. It is true there are discrepancies, I'll ask upstream to rectify this. Please add a comment field to the copyright file. Otherwise the ftp-master is going to ask the same questions again (or going to reject the package). Also noting somewhere that this package is a requisite for agenda.app is good, e.g. in the ITP. Paul signature.asc Description: OpenPGP digital signature
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
Paul Gevers wrote: Before I upload this package to the new queue, could you please comment on the lintian errors about missing source? The reason for these is gnustep-make's incapable dist rule, combined with not so careful upstream. I am looking for a statement like: I added lintian overrides... Hmm, but I have not overridden them, I don't feel I should. I have informed upstream and I hope it won't happen in subsequent releases. I'm not cleaning them explicitly either as gnustep-make's distclean rule does that. There's little I can do given that the object files are in the .orig tarball; adding a lintian override won't change that. (I haven't checked the content, but these files should be used to test the build, no?) Yes and no. They depend on a test framework that is not packaged for Debian, so they're unused for the debian package build. As for the license, debian/copyright is correct. It is true there are discrepancies, I'll ask upstream to rectify this. -- 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/87oawqhjeb.GNUs_not_UNIX!%ya...@gnu.org
Bug#754870: RFS: systempreferences.app/1.2.0-1 -- GNUstep preferences application
Control: owner -1 ! Control: tags -1 pending I like the Description of the packages to be consistent. Either System Preferences *is* or System Preferences *are*. I think the second option is the logic one considering the name, but otherwise you need something like The System Preferences application When in doubt about such descriptions, I recommend e-mailing debian-l10n-english@l.d.o for advice. Paul signature.asc Description: OpenPGP digital signature
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
Paul Gevers wrote: On 15-07-14 14:54, Yavor Doganov wrote: Hmm, but I have not overridden them, I don't feel I should. I have informed upstream and I hope it won't happen in subsequent releases. Well, to document this fact is exactly why an override would be nice. OK, I added the override. But I understand you position, I guess you just want to prevent it happens again next time, right? Exactly. I haven't checked, but ftp-masters use also several lintian checks as auto-reject. So maybe this is even needed to pass the NEW queue. I thought about that; this lintian error is not in the automatic rejects list. I'm not cleaning them explicitly either as gnustep-make's distclean rule does that. Well, the source has to be DFSG-free. How we guarantee that usually is by building everything from source during the build. If you don't want to build it, you have to remove them from source and repack I don't understand. It is quite common for a package not to build some part of the source; this is not a problem at all as long as everything is DFSG-compliant. Which is the case here. As for the license, debian/copyright is correct. It is true there are discrepancies, I'll ask upstream to rectify this. Please add a comment field to the copyright file. Otherwise the ftp-master is going to ask the same questions again (or going to reject the package). Right; added (in dbuskit.git). Also noting somewhere that this package is a requisite for agenda.app is good, e.g. in the ITP. And also by cdplayer.app (not packaged yet). But isn't this self-explanatory? I think libraries w/o reverse dependencies are strongly discouraged. -- 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/87mwcahg3w.GNUs_not_UNIX!%ya...@gnu.org
Bug#754870: RFS: systempreferences.app/1.2.0-1 -- GNUstep preferences application
Paul Gevers wrote: I like the Description of the packages to be consistent. Either System Preferences *is* or System Preferences *are*. Thanks, fixed in the git repository. -- 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/87lhruhfrr.GNUs_not_UNIX!%ya...@gnu.org
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
On 15-07-14 16:05, Yavor Doganov wrote: Well, the source has to be DFSG-free. How we guarantee that usually is by building everything from source during the build. If you don't want to build it, you have to remove them from source and repack I don't understand. It is quite common for a package not to build some part of the source; this is not a problem at all as long as everything is DFSG-compliant. Which is the case here. This is true if you mean that not all source is used during a build. However, a lot of the Debian developers (yes, there is debate on this how far you should stretch this argument) consider a tar-ball to meet the DFSG if the files are either the preferred form for modification OR build-able from such a form with tools available in Debian (e.g. MS Windows executables in the source are frowned upon by most). In order to guarantee that they are indeed buildable, a lot of DD's will just say, let's build them than. Whatever you do, to prevent accidental usage of a pre-build object file it is very common to at least clean them. Paul signature.asc Description: OpenPGP digital signature
Re: node-webkit
El 14/07/14 18:14, Leo Iannacone escribió: Hi Fernando, AFAIK nobody in JavaScript Team is working on. Consider to join us[0] if you want to package it. Cheers! Leo. [0] - https://wiki.debian.org/Javascript Thanks you. -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar -- 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/53c53c47.20...@docksud.com.ar
Bug#754881: RFS: saga/2.1.2+dfsg-1 (update)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package saga * Package name: saga Version : 2.1.2+dfsg-1 Upstream Author : Olaf Conrad, Volker Wichmann and other contributors * URL : http://www.saga-gis.org * License : GPL Section : science It builds those binary packages: libsaga- SAGA GIS shared libraries libsaga-dev - SAGA GIS development files python-saga - SAGA GIS Python bindings saga - System for Automated Geoscientific Analyses To access further information about this package, please visit the following URL: http://mentors.debian.net/package/saga Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/saga/saga_2.1.2+dfsg-1.dsc SAGA is already packaged in debian, this is just an update to the last upstream version Regards, Johan Van de Wauw -- 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/CAJOp35=Z=7=mSu+GFF9RQ=7X=hgr9vwhegg3xz6zknj_kbn...@mail.gmail.com
Bug#753348: RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library
Control: owner -1 ! Control: tags -1 pending I uploaded the package, but may I request that next time you add a symbols file so that depending packages get a properly versioned dependency? See lintian info tag: I: libperformance0.5: no-symbols-control-file usr/lib/libPerformance.so.0.5.0 N: N:Although the package includes a shared library, the package does not N:have a symbols control file. N: N:dpkg can use symbols files in order to generate more accurate library N:dependencies for applications, based on the symbols from the library N:that are actually used by the application. N: N:Refer to the dpkg-gensymbols(1) manual page and N:https://wiki.debian.org/UsingSymbolsFiles for details. N: N:Severity: wishlist, Certainty: certain N: N:Check: shared-libs, Type: binary, udeb Paul signature.asc Description: OpenPGP digital signature
Autoreconfing guide
I've written a wiki page on how and when to use dh-autoreconf and autotools-dev. (having done a pile of updating like this recently) People might like to comment on it/improve it. (there are more examples needed for using both together, and on updating macros from older conventions, and on tricky cases like configure in top-level, configure.ac in subdir with config.* files) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20140715170553.gf22...@stoneboat.aleph1.co.uk
Re: Autoreconfing guide
I've written a wiki page on how and when to use dh-autoreconf and autotools-dev. Could you provide an url? Thank you! Guido van Steen -- 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/camtvz+vwvz3v4dhurm92cq_pzfcikvu-f4zy8zn+hyl_dgr...@mail.gmail.com
Bug#753348: RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library
Paul Gevers wrote: I uploaded the package, but may I request that next time you add a symbols file so that depending packages get a properly versioned dependency? Symbols files are ultimately unapplicable for Objective-C libraries (see #749202). Using them can be very harmful -- lax dependencies or spurious build failures when a private class or category is removed. I don't override these as they're informational tags and it's a lintian bug that should be addressed. -- 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/87k37eh8nw.GNUs_not_UNIX!%ya...@gnu.org
Re: Autoreconfing guide
+++ Guido van Steen [2014-07-15 19:09 +0200]: I've written a wiki page on how and when to use dh-autoreconf and autotools-dev. Could you provide an url? Doh! https://wiki.debian.org/Autoreconf Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20140715171404.gg22...@stoneboat.aleph1.co.uk
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
Paul Gevers wrote: On 15-07-14 16:05, Yavor Doganov wrote: I don't understand. It is quite common for a package not to build some part of the source; this is not a problem at all as long as everything is DFSG-compliant. Which is the case here. This is true if you mean that not all source is used during a build. However, a lot of the Debian developers (yes, there is debate on this how far you should stretch this argument) consider a tar-ball to meet the DFSG if the files are either the preferred form for modification OR build-able from such a form with tools available in Debian (e.g. MS Windows executables in the source are frowned upon by most). I see what you mean but that's not the case here. The source code is available; that's the preferred form for modification. Whatever you do, to prevent accidental usage of a pre-build object file it is very common to at least clean them. It is done by `make distclean'. -- 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/87iomyh8dz.GNUs_not_UNIX!%ya...@gnu.org
Bug#754202: Gamera/3.4.1-1
* Dmitry Smirnov only...@debian.org, 2014-07-14, 16:21: Finally my biggest concern is new dependency on wxwidgets2.8. There is on-going transition to wxwidgets3.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748169 As the bug says, there is no wxPython 3.0 in Debian yet... IMHO it will be ideal to migrate to wxwidgets3.0 before upload. ...so there isn't anything to migrate to, as far as Debian in concerned. -- Jakub Wilk -- 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/20140715172135.ga5...@jwilk.net
Bug#753348: marked as done (RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library)
Your message dated Tue, 15 Jul 2014 19:42:40 +0200 with message-id 53c56810.9030...@wollumbin.marsaxlokk.dhcp.io and subject line gnustep-performance_0.5.0-1_amd64.changes is NEW has caused the Debian Bug report #753348, regarding RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library 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.) -- 753348: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753348 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 gnustep-performance. * Package name: gnustep-performance Version : 0.5.0-1 Upstream Author : Richard Frith-Macdonald r...@gnu.org * URL : http://gnustep.org * License : LGPL-3+ Section : libs Programing Lang : Objective-C It builds these binary packages: libperformance-dev - GNUstep performance library (development files) libperformance0.5 - GNUstep performance library (runtime library) libperformance0.5-dbg - GNUstep performance library (debugging symbols) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gnustep-performance Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/gnustep-performance/gnustep-performance_0.5.0-1.dsc The ITP bug is #753092. ---End Message--- ---BeginMessage--- And waiting in NEW now. Paul Original Message Subject: gnustep-performance_0.5.0-1_amd64.changes is NEW Date: Tue, 15 Jul 2014 15:49:49 + From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: Debian GNUstep maintainers pkg-gnustep-maintain...@lists.alioth.debian.org, Yavor Doganov ya...@gnu.org, elb...@debian.org binary:libperformance-dev is NEW. binary:libperformance0.5 is NEW. binary:libperformance0.5-dbg is NEW. source:gnustep-performance is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html signature.asc Description: OpenPGP digital signature ---End Message---
Bug#754870: marked as done (RFS: systempreferences.app/1.2.0-1 -- GNUstep preferences application)
Your message dated Tue, 15 Jul 2014 19:40:56 +0200 with message-id 53c567a8.4000...@wollumbin.marsaxlokk.dhcp.io and subject line Fwd: systempreferences.app_1.2.0-1_amd64.changes is NEW has caused the Debian Bug report #754870, regarding RFS: systempreferences.app/1.2.0-1 -- GNUstep preferences application 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.) -- 754870: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754870 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 systempreferences.app. It builds these binary packages: libpreferencepanes-dev - GNUstep preferences library - development files libpreferencepanes1 - GNUstep preferences library - runtime library systempreferences.app - GNUstep preferences application systempreferences.app-dbg - GNUstep preferences application - debugging symbols To access further information about this package, please visit the following URL: http://mentors.debian.net/package/systempreferences.app Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/systempreferences.app/systempreferences.app_1.2.0-1.dsc Changes since the last upload: * New upstream release: - Compatible with current GNUstep libraries (Closes: #749793). * debian/source/format: Switch to 3.0 (quilt). * debian/compat: Set to 9. * debian/control (Build-Depends): Remove quilt. Require libgnustep-gui-dev (= 0.24) and debhelper (= 9). (libpreferencepanes-dev, libpreferencepanes1) (systempreferences.app-dbg): New packages. Split the library as GWorkspace needs it. Adjust package relationships accordingly. (Vcs-Arch): Replace with Vcs-Git and Vcs-Browser. (Standards-Version): Claim compliance with 3.9.5 as of this release. * debian/rules: Update for modern dh. Enable hardening. * debian/README.source: Delete. * debian/manpages: * debian/systempreferences.app.install: * debian/libpreferencepanes-dev.install: * debian/libpreferencepanes1.install: * debian/libpreferencepanes1.lintian-overrides: New files. * debian/SystemPreferences.desktop: Add Keywords field. * debian/copyright: Switch to format 1.0. ---End Message--- ---BeginMessage--- Now waiting in the NEW queue. Original Message Subject: systempreferences.app_1.2.0-1_amd64.changes is NEW Date: Tue, 15 Jul 2014 15:52:06 + From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: Debian GNUstep maintainers pkg-gnustep-maintain...@lists.alioth.debian.org, Yavor Doganov ya...@gnu.org, elb...@debian.org binary:libpreferencepanes-dev is NEW. binary:libpreferencepanes1 is NEW. binary:systempreferences.app-dbg is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html signature.asc Description: OpenPGP digital signature ---End Message---
Bug#753348: RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library
On 15-07-14 18:46, Yavor Doganov wrote: Paul Gevers wrote: I uploaded the package, but may I request that next time you add a symbols file so that depending packages get a properly versioned dependency? Symbols files are ultimately unapplicable for Objective-C libraries (see #749202). Using them can be very harmful -- lax dependencies or spurious build failures when a private class or category is removed. I don't override these as they're informational tags and it's a lintian bug that should be addressed. Thanks for clarifying. As lintian bugs often don't get resolved quickly (I don't blame anybody here), I still recommend adding the lintian override with the comment you wrote above. Once the bug is fixed, lintian will warn you that there are unused lintian overrides. As long as you rely on sponsors for you uploads, it helps documenting these things right in the location where people expect to find the information and it saves you a round trip of e-mail next time (even in case I do the sponsoring, I might just have forgotten what you told me above). Just for your info, I run lintian on nearly every build that I do, and just keeping track of the errors/warnings/info tags that I already have judged is annoying. Therefor I override them if I am sure enough that they are wrong. The ones I don't override are the ones that I still have to come to a final conclusion. But of course, it is your package. Let's just agree that it helps me in helping you getting your packages updated in Debian if you document that you thought about the lintian warnings (by overriding them with a good comment attached). Paul signature.asc Description: OpenPGP digital signature
Bug#753348: RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library
Paul Gevers wrote: Let's just agree that it helps me in helping you getting your packages updated in Debian if you document that you thought about the lintian warnings (by overriding them with a good comment attached). I see; there's no problem at all for me to do that. It would require changes again when lintian is fixed but that's no big deal. As a funny consequence, you don't get these with frameworks, because apparently for lintian a GNUstep framework is not a library. Which is why it greets you with postinst/postrm-has-useless-call-to-ldconfig :-) -- 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/87ha2ih45j.GNUs_not_UNIX!%ya...@gnu.org
Bug#753406: RFS: gnustep-sqlclient/1.7.3-1 [ITP] -- SQL client library for GNUstep
Hi Yavor, On 01-07-14 17:13, Yavor Doganov wrote: I am looking for a sponsor for my package gnustep-sqlclient. libsqlclient1.7 - SQL client library for GNUstep (runtime library) This package contains files in an unversioned sub-directory of /usr/lib/ This is a violation of Debian policy §8.2 [1]: If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Paul [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-support-files signature.asc Description: OpenPGP digital signature
Re: uscan: sf watch redirector update trouble for tth
On 15/07/14 03:30, Paul Wise wrote: On Tue, Jul 15, 2014 at 8:45 AM, Daniel Lintott wrote: Only advice I can give you can find in https://lists.debian.org/debian-mentors/2014/07/msg00153.html Negotiations with sourceforge are continuing but it looks like we may have to adopt the RSS based redirector code. Indeed it looks like that may be be the best way to proceed at least until SF.net can provide a solution. When I wrote the RSS parser script I have tried to make it seamlessly fit with the old redirector.. so it could be fitted in place of, but currently the is one difference. The links in the current redirector are written displayed (in source) as: a href='vpcs-0.5b0-src.tbz'vpcs-0.5b0-src.tbz/abr/ Which results in the following link: https://qa.debian.org/watch/sf.php/vpcs/vpcs-0.5b0-src.tbz For some reason (maybe server configuration difference) I wasn't able to achieve exactly the same in my RSS based redirector... So in the page source I have: a href='/debian/sf.php/vpcs/vpcs-0.5b2-src.tbz'vpcs-0.5b2-src.tbz/abr/ Note the addition of the directory and script name, which may break some of the regex's (it did for me). I had to add this in the source as I couldn't get the link displayed with the slash argument when I tested it on my servers. It may be that I've missed something obvious... so feel free to correct me! Regards Daniel signature.asc Description: OpenPGP digital signature
Bug#753406: RFS: gnustep-sqlclient/1.7.3-1 [ITP] -- SQL client library for GNUstep
Paul Gevers wrote: libsqlclient1.7 - SQL client library for GNUstep (runtime library) This package contains files in an unversioned sub-directory of /usr/lib/ This is a violation of Debian policy §8.2 Right, I totally missed that... I'm not sure how to fix this. The bundles are dynamically opened by the library, it is useless without them. Putting them in a separate unversioned package won't work as it is because it would still make two versions of the library impossible to coexist. Unless they don't link with the library, in which case there's still the valid scenario when the API changes and the old library is unable to load or work with the new bundles. I'd appreciate any suggestions. -- 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/87fvi2h1q1.GNUs_not_UNIX!%ya...@gnu.org
Re: Autoreconfing guide
* Wookey woo...@wookware.org, 2014-07-15, 18:14: I've written a wiki page on how and when to use dh-autoreconf and autotools-dev. Awesome, thanks! https://wiki.debian.org/Autoreconf What is “'foreign' context” and how do you set it? -- Jakub Wilk -- 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/20140715194332.ga1...@jwilk.net
Bug#753406: RFS: gnustep-sqlclient/1.7.3-1 [ITP] -- SQL client library for GNUstep
On 15-07-14 21:16, Yavor Doganov wrote: Paul Gevers wrote: libsqlclient1.7 - SQL client library for GNUstep (runtime library) This package contains files in an unversioned sub-directory of /usr/lib/ This is a violation of Debian policy §8.2 Right, I totally missed that... I'm not sure how to fix this. The bundles are dynamically opened by the library, it is useless without them. Putting them in a separate unversioned package won't work as it is because it would still make two versions of the library impossible to coexist. Unless they don't link with the library, in which case there's still the valid scenario when the API changes and the old library is unable to load or work with the new bundles. I'd appreciate any suggestions. I assume you read the sentences in the policy after my quote. Why wouldn't that work for this package, i.e. put the files in a sub-directory of /usr/lib/libsqlclient1.7/? Is the location of these Bundles so hard-coded that they can't be relocated? Paul signature.asc Description: OpenPGP digital signature
Re: Help with libquazip / Qt4-Qt5
Ok. How can I manage this? Is it possible inside one unique source package? Debhelper does only have a qmake_qt4 buildsystem. I don't think dh(1) supports two build sets, so you will have to do it manually. I succeeded in creating a dual build Qt4/Qt5 and now I get packages for both Qt versions. Last question (just a confirmation) about the package naming. As the default Qt version is Qt4, should I name the Qt4 packages libquazip1-qt4 or just libquazip1? I currenlty choose libquazip1. Here are the files created by pbuilder: libquazip_0.6.2-1_amd64.changes libquazip_0.6.2-1.debian.tar.gz libquazip_0.6.2-1.debian.tar.xz libquazip_0.6.2-1.dsc libquazip_0.6.2.orig.tar.gz libquazip1_0.6.2-1_amd64.deb libquazip1-dbg_0.6.2-1_amd64.deb libquazip1-dev_0.6.2-1_amd64.deb libquazip1-headers_0.6.2-1_all.deb libquazip1-qt5_0.6.2-1_amd64.deb libquazip1-qt5-dbg_0.6.2-1_amd64.deb libquazip1-qt5-dev_0.6.2-1_amd64.deb libquazip-doc_0.6.2-1_all.deb Thanks for your confirmation Eric, Debian Med signature.asc Description: OpenPGP digital signature
Re: Autoreconfing guide
+++ Jakub Wilk [2014-07-15 21:43 +0200]: * Wookey woo...@wookware.org, 2014-07-15, 18:14: I've written a wiki page on how and when to use dh-autoreconf and autotools-dev. Awesome, thanks! https://wiki.debian.org/Autoreconf What is “'foreign' context” and how do you set it? Yeah I didn't have time to look that up and remind myself: fx: duckduck's a bit It's actually 'foreign strictness' https://www.gnu.org/software/automake/manual/html_node/Strictness.html https://www.gnu.org/software/automake/manual/html_node/Options-generalities.html Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20140715195956.gh22...@stoneboat.aleph1.co.uk
Bug#753406: RFS: gnustep-sqlclient/1.7.3-1 [ITP] -- SQL client library for GNUstep
Yavor Doganov wrote: Paul Gevers wrote: This package contains files in an unversioned sub-directory of /usr/lib/ This is a violation of Debian policy §8.2 Right, I totally missed that... I'm testing a patch that installs them in /usr/lib/GNUstep/Bundles/SQLClient.soversion. -- 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/87egxmh0kb.GNUs_not_UNIX!%ya...@gnu.org
Re: Autoreconfing guide
Hi Wooky, } https://wiki.debian.org/Autoreconf Your wikipage looks very good! Thanks! I maintain a package that does not need any compiling. Still upstream development is done using autoconf and autotools. Building the Debian package yields a single binary package for all architectures. AFAIK in this case I need neither dh-autoreconf nor autotools-dev. Correct me if I am wrong though... IMO this could be useful information for the wiki as well. I also find https://wiki.debian.org/AutoTools/autoconf quite interesting. Best wishes, Guido -- 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/camtvz+vsgx1rbycbxod8ypbeuffd6fsyekox7wdec3a4rsy...@mail.gmail.com
Re: Autoreconfing guide
Guido van Steen vanst...@users.sourceforge.net writes: I maintain a package that does not need any compiling. Still upstream development is done using autoconf and autotools. Building the Debian package yields a single binary package for all architectures. AFAIK in this case I need neither dh-autoreconf nor autotools-dev. Correct me if I am wrong though... IMO this could be useful information for the wiki as well. I would still use dh-autoreconf. It's not as critical, since it's unlikely to be necessary for supporting new architectures, but I think the Autoconf and Automake files are better treated as source, and the generated files regenerated on every build. This ensures that the files can still be generated from the source, which in turn ensures that anyone wanting to make changes to the source package will be able to do so easily. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87bnsqmka5@windlord.stanford.edu
Re: Autoreconfing guide
} but I think the Autoconf and Automake files are better treated as source, } and the generated files regenerated on every build. I thought that regenerating generated files was achieved by adding build-depends on autoconf and automake, and that autoreconf was only needed to generate config.guess and config.sub. Apparently I was wrong. Thank you for pointing this out! Next time I will use autoreconf as well. -- 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/camtvz+sfqan-xbybgyvogypkw8mymfckhc7h42tk6wkbt-4...@mail.gmail.com
Bug#753406: RFS: gnustep-sqlclient/1.7.3-1 [ITP] -- SQL client library for GNUstep
Paul Gevers wrote: I'd appreciate any suggestions. I assume you read the sentences in the policy after my quote. Why wouldn't that work for this package, i.e. put the files in a sub-directory of /usr/lib/libsqlclient1.7/? Is the location of these Bundles so hard-coded that they can't be relocated? It is hardcoded in a sense that NSPathUtilities functions won't be able to find them. I could put them in such a directory and change SQLClient.m so that it loads them from there but this doesn't scale at all with the three installation domains and the different filesystem layouts GNUstep supports so the patch will be rejected upstream. Please check again if/when you have time, I think it is compliant now. -- 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/87d2d6gwem.GNUs_not_UNIX!%ya...@gnu.org
Re: Autoreconfing guide
Russ Allbery wrote: I would still use dh-autoreconf. It's not as critical, since it's unlikely to be necessary for supporting new architectures, but I think the Autoconf and Automake files are better treated as source, and the generated files regenerated on every build. However, this is not how the GNU build system is intended to be used. This ensures that the files can still be generated from the source, which in turn ensures that anyone wanting to make changes to the source package will be able to do so easily. This is an obvious plus, but consider the cons: - It can provide non-deterministic builds for packages which misuse the build system (improper quotation, usage of broken third-party macros, etc). - It can provide non-deterministic builds for legitimate use, when a macro changes its semantics (this used to happen quite a lot in the past). - It can introduce bugs for no good reason if a buggy Autoconf/Automake version is used (either an upstream release that introduced a regression or caused by a Debian patch). - Packages may (will?) FTBFS if they're silently upgraded to a new Autoconf/Automake release that requires sourceful changes to configure.ac/Makefile.am's/etc and such changes are not made by the upstream/Debian maintainer (consider binNMUs, or the regular archive rebuilds). - All of the above can happen on a large scale if a big library transition is involved and some stack of packages is being rebuilt. -- 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/87bnsqguto.GNUs_not_UNIX!%ya...@gnu.org
Re: Autoreconfing guide
Yavor Doganov ya...@gnu.org writes: Russ Allbery wrote: I would still use dh-autoreconf. It's not as critical, since it's unlikely to be necessary for supporting new architectures, but I think the Autoconf and Automake files are better treated as source, and the generated files regenerated on every build. However, this is not how the GNU build system is intended to be used. Meh. I think this is a non-issue. Most free software is used in ways that it wasn't originally designed for, and I think this is a clearly superior way to use it on platforms where we have the right tools. The pre-built configure scripts and Makefiles still provide valuable portability to systems where it's hard to get all the right tools installed. This ensures that the files can still be generated from the source, which in turn ensures that anyone wanting to make changes to the source package will be able to do so easily. This is an obvious plus, but consider the cons: - It can provide non-deterministic builds for packages which misuse the build system (improper quotation, usage of broken third-party macros, etc). No, it's not non-deterministic. It's quite deterministic; it just may be broken with newer versions of the tools, just like badly written C code may be broken by newer versions of the compiler. This is exactly *why* you should always regenerate from source: so that you can catch those bugs and *fix* them. That's part of the point of free software. - It can provide non-deterministic builds for legitimate use, when a macro changes its semantics (this used to happen quite a lot in the past). Which is equivalent to saying that unmaintained Autoconf or Automake files will *break* the builds for legitimate uses, like needing to modify some part of the build system and finding that it can't be recreated with the Autoconf and Automake currently available. This is why these bugs should be flushed out and fixed. - It can introduce bugs for no good reason if a buggy Autoconf/Automake version is used (either an upstream release that introduced a regression or caused by a Debian patch). Well, obviously I completely disagree with no good reason. Yes, actually using our build chain will uncover bugs in our build chain, so that we can then fix them. This is very good, even if it's painful when we find the bugs. - Packages may (will?) FTBFS if they're silently upgraded to a new Autoconf/Automake release that requires sourceful changes to configure.ac/Makefile.am's/etc and such changes are not made by the upstream/Debian maintainer (consider binNMUs, or the regular archive rebuilds). Again, this is no different than buiding with a new C compiler. Those are bugs that should be fixed, and better that we know about them than not. - All of the above can happen on a large scale if a big library transition is involved and some stack of packages is being rebuilt. I find your concerns excessively alarmist. I have been rebuilding all the Autoconf and Automake files from scratch for all packages I maintain for quite some time now, including some very complex packages and packages with a mess of Autoconf macros, and have had few problems apart from a few latent upstream bugs that were flushed out and are now fixed. The only significant problem that I had that fell into one of your categories was the need to add: m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) to configure.ac in several of my packages due to an Automake behavior change. I've had considerably more work to do with C++ compiler transitions. If a particular package uses Autoconf and Automake in such a fragile and broken way that it keeps causing problems, maybe it's useful as a matter of expediency to fall back on not rebuilding the files until those bugs can be fixed. I know some packages mangled those tools very badly in the past. But for the vast majority of packages this works fine, or with at most minor patches that upstream is happy to take. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87r41ml144@windlord.stanford.edu
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer j.scha...@email.de, 2014-07-13, 22:23: If you look at the upstream repository you'll see a Debian directory Oops, I missed it. (Wouldn't it make sense to remove it from .orig.tar?) uscan does this automatically when repacking upstream tarballs. I don't believe this is the case. And the .orig.tar you uploaded to mentors certainly contains debian/: $ tar -tf pdf2htmlex_0.11+ds.orig.tar.gz --wildcards '*/debian' pdf2htmlEX-0.11+ds/debian/ pdf2htmlEX-0.11+ds/debian/changelog pdf2htmlEX-0.11+ds/debian/source/ pdf2htmlEX-0.11+ds/debian/source/format pdf2htmlEX-0.11+ds/debian/rules pdf2htmlEX-0.11+ds/debian/pdf2htmlex.NEWS pdf2htmlEX-0.11+ds/debian/dirs pdf2htmlEX-0.11+ds/debian/copyright pdf2htmlEX-0.11+ds/debian/pdf2htmlex.README pdf2htmlEX-0.11+ds/debian/compat pdf2htmlEX-0.11+ds/debian/pdf2htmlex.TODO pdf2htmlEX-0.11+ds/debian/control Removing useless linking against libpython2.7.so.1.0 was easily fixed by not build depending on python-dev. Hmm, that doesn't sound right. It means that a user building in a non-minimal environment can get a package with or without libpython2.7-dev in Depends, depending on which packages they had installed. I think I prefer to live with the dpkg-shlibdeps warnings, than to have this sort of non-determinism. Right. So how about a Build-Conflict with the appropriate binary package? I tend to think of Build-Conflicts as a weapon of last resort. I don't want to uselessly increase the amount of dependencies of the resulting binary package (even though libpython is probably present on most systems). It wouldn't increase the amount of packages required to run pdf2htmlex, at least not for the time being, because libfontforge depends on libpython. The reason linking to unneeded libraries is bad is because it makes Packages a tiny bit bigger, makes dependency resolved a tiny bit slower, and becomes burdensome when one of the libraries change SONAME. Though on the other hand it seems I managed to patch the build system such that it will not use libpython anymore (see patch no-libpython). That's much better. Now, can you do the same with gunicode? :-) What is your opinion about the tarball repacking and the Files-Excluded in debian/copyright? I don't like it, but I'm not going to stop anybody from using it. Note that currently uscan would generate .orig.tar with wrong version; see bug #753772. -- Jakub Wilk -- 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/20140715222609.ga4...@jwilk.net
Re: Autoreconfing guide
+++ Yavor Doganov [2014-07-16 00:45 +0300]: Russ Allbery wrote: I would still use dh-autoreconf. It's not as critical, since it's unlikely to be necessary for supporting new architectures, but I think the Autoconf and Automake files are better treated as source, and the generated files regenerated on every build. However, this is not how the GNU build system is intended to be used. The autotools view that the stuff shipped with the source is sacrosanct has caused (and is causing) orders of magnitude more trouble than reautoconfing at build time does. We now have lots of experience which shows that reautoconfing hardly ever breaks things any more (and if it does that's something we should know about and fix). We also have lots of experience to show that using the old files shipped with the source does not work on new architectures and generates enormous amounts of largely pointless mechanical work for porters and maintainers. This ensures that the files can still be generated from the source, which in turn ensures that anyone wanting to make changes to the source package will be able to do so easily. This is an obvious plus, but consider the cons: Russ has explained why your list of cons is, overall, not convincing. If people want to expand the rationale section of the page on pro's and cons, then that's fine - it's a useful place to collect such info, but do please make sure any claims of problems are evidence-backed. I was mostly hoping for additional info on the practical changes maintainers should know about (very few of whom know anything about the autotools really work). (if your package contains construct 'foo' then it will do X and should be updated to form 'bar'). Or examples of things which break in practice, and what should be done to fix them.. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20140715230748.gi22...@stoneboat.aleph1.co.uk
Re: Autoreconfing guide
On Wed, Jul 16, 2014 at 1:14 AM, Wookey wrote: https://wiki.debian.org/Autoreconf Could you mention this in DevNews? https://wiki.debian.org/DeveloperNews -- bye, pabs https://wiki.debian.org/PaulWise -- 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/caktje6eng4pz2fcwamgmaaykbhr6gaoutck3512kkwtr3vy...@mail.gmail.com
Re: Autoreconfing guide
On Wed, Jul 16, 2014 at 1:14 AM, Wookey wrote: https://wiki.debian.org/Autoreconf Please mention the need to Build-Depend on any packages containing .m4 files that are embedded in the orig.tar.gz. For example, a lot of packages use macros from autoconf-archive and some -dev packages contain macros. I note there are still some upstreams who do not trust autoconf. For example the e2fsprogs maintainer recently rejected my patch to remove autotools cruft from the git repository. As a result of autoconf changes, he copied part (AM_MKINSTALLDIRS) of the nls.m4 file into the acinclude.m4 file. I wonder if lintian should be mentioning dh-autoreconf as best practice at info/pedantic level? I also wonder if autotools upstream should move away from storing artefacts in the orig.tar.gz. A better model might be to run autotools on the build machine and have an option that is run on new/normal/modern platforms to spit out a blob of shell/VBScript/something for ancient/weird/legacy/different platforms. Presumably anyone trying to build for old platforms also has access to a modern platform. Anyone seen plans for something like that? -- bye, pabs https://wiki.debian.org/PaulWise -- 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/CAKTje6GAhUjeKX2wBOHrr_G6MTCoa+iakrTw8RL2vtPx=qd...@mail.gmail.com
Bug#740105: marked as done (RFS: xsane/0.999-1 [ITA])
Your message dated Wed, 16 Jul 2014 04:24:56 + with message-id e1x7gm0-0005db...@quantz.debian.org and subject line closing RFS: xsane/0.999-1 [ITA] has caused the Debian Bug report #740105, regarding RFS: xsane/0.999-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.) -- 740105: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740105 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 the package xsane. It is one of the most popular SANE frontends, and has been unmaintained for some time. It's mentors page is https://mentors.debian.net/package/xsane and the .dsc is at http://mentors.debian.net/debian/pool/main/x/xsane/xsane_0.999-1.dsc Thank you ---End Message--- ---BeginMessage--- Package xsane has been removed from mentors.---End Message---
