Re: In need of help before RFS
On Wed, Jul 27, 2016 at 11:09 AM, Boyuan Yang wrote: > 1. Upstream put some *CA certificates* of VeriSign and Thawte inside > repository and intends to install it into final binary package. I > don't know how to write copyright information for these files. What > should I do to deal with this problem? I'm not sure, but I expect these certificates are not copyrightable. > 2. Even though it is a C++/Qt project, upstream is providing a small > prebuilt .jar file for feature enhancement. The source code for the > .jar file is provided as well. Does it mean that I should drop > prebuilt jar file and rebuild it from source code utilizing the > toolchain of Java during building process? Yes please. I would suggest that upstream remove it from their source tarball and VCS and adjust their build system to always build it from scratch. They can include the pre-built jar in their binary package downloads and or as a separate download for people who only want to have to build the C++ parts. > 3. When adding debian-specific patches, do I have to write > pseudo-headers for patch diff file? This would be a good idea but not mandatory, please follow DEP-3 when adding such headers though. http://dep.debian.net/deps/dep3/ -- bye, pabs https://wiki.debian.org/PaulWise
In need of help before RFS
Hello all, I am working on my ITP for nixnote2, an open-source Evernote desktop client (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609849) and met some problems. I hope someone could help solve my problems here: 1. Upstream put some *CA certificates* of VeriSign and Thawte inside repository and intends to install it into final binary package. I don't know how to write copyright information for these files. What should I do to deal with this problem? BTW, I looked into the source package of `ca-certificates' and found that those CA certificates was provided by Mozilla in MPL-2.0 in a completely different type and was somehow transformed into usable certificates when building binary package. 2. Even though it is a C++/Qt project, upstream is providing a small prebuilt .jar file for feature enhancement. The source code for the .jar file is provided as well. Does it mean that I should drop prebuilt jar file and rebuild it from source code utilizing the toolchain of Java during building process? 3. When adding debian-specific patches, do I have to write pseudo-headers for patch diff file? It is clear that patches generated by dpkg-source or gbp provides such patches templates as well as "diff --git" format diff files, but when I am trying to manage patches with quilt, the generated patches are just plain traditional "diff -u" style patch files. 4. There is one source file which is licensed under *public-domain*(see the d/copyright file for detail, the whole project is under GPL-2 though). I found some words about this situation (https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#public-domain) but still have little idea about writing correct copyright paragraph in debian/copyright file. Should I just leave the body of license empty, or should I add some description words here? And should I leave the copyright-holder line empty, or just delete the "Copyright: " line? I am in need of your suggestions. A concrete example would be much appreciated. For those who may be interested, my current work is hosted on https://github.com/hosiet/nixnote2 . Thanks, Boyuan Yang
Bug#827933: RFS: yabar/0.4.0-3 [ITP]
control: owner -1 ! control: tag -1 +moreinfo Hello, I can't sponsor the package, but I hope that the following review is useful to you. 1. You should install the examples to /usr/share/doc/yabar/examples, not /usr/share/yabar/examples. You can use dh_installexamples to do this. 2. Since you are packaging based on git tags not github tarballs (I'm looking at force-create in your gbp.conf), you might have the watch file look for git tags rather than tarballs. Uscan watch file format version 4 can do this. Not a big deal -- just a suggestion. 3. You should remove the export-dir from gbp.conf: this will override settings in personal ~/.gbp.conf, arbitrarily selecting a different build area on other developer's machines! 4. Are you sure about Section: misc? How about x11? 5. You have a lot of libs listed as dependencies. These should be included in ${shlibs:Depends}. Is dh_shlibdeps not generating the correct list? 6. You have a build-dependency on git-core, presumably because of the call to git-describe(1) in upstream's Makefile. However, you also set the VERSION environment variable in debian/rules -- though I think your VERSION in d/rules includes the Debian revision, which might not be what you want. Remember that your source package needs to be buildable outside of a git repository. You should add some comments to the rules file explaining why you are setting VERSION and please explain in reply to this e-mail why you need the git-core build-dep :) 7. Could you explain the Suggests: fonts-font-awesome? 8. You could add some paragraph breaks to the extended description. 9. "plain c" in the description should be "plain C" 10. Why priority 'extra' not 'optional'? Do you expect a file conflict? 11. Why the tight dpkg-dev dependency? 12. As I said before, please merge your debian/changelog entries to a single 0.4.0-1 entry, with only the "Initial release (Closes: #xx)" line. 13. Why a 'low' upload urgency? Counterintuitively, this means that you think the package is more likely than usual to be buggy and so it should take longer to migrate to testing; it doesn't actually mean "less important". Unless you think the upload is buggy, you should use priority=medium. 14. I see you are ignoring .o files in debian/source/options. Since your clean target deletes .o files, why do you need this? If you don't need it, it would be less confusing if you just deleted it. Is it because upstream hasn't merged your fixed clean target patch yet? I think it would be more readable to the debian/clean file instead of debian/source/options. 15. Any reason you haven't forwarded d/patches/fix-typos, d/patches/makefile-ldflags, and d/patches/makefile-version? 16. Are you sure you need all the lines in your rules file? I think that with debhelper compat level 9, it is enough to export DEB_BUILD_MAINT_OPTIONS and the rest will happen automatically. Not sure, though. 17. You could probably add --parallel to the dh invocation. 18. You should install the README (patched to remove the installation instructions) and the screenshots to /usr/share/doc/yabar. It looks like useful documentation that a Debian user probably wants. On Tue, Jul 26, 2016 at 11:08:21AM +0200, Jack Henschel wrote: > I recently switched from developing on the debian/sid branch to the > master branch (hence the latter one has more recent commits). gbp by > default assumes the build branch is 'master' (except specified via > --git-debian-branch). Since I do not yet have a lot of experience > with gbp, I am uncertain which work flow is better. (Any > recommendations?) You can configure the Debian branch in debian/gbp.conf. Most of us work on a master branch for unstable, sometimes adding additional branches for backports etc. It's definitely up to you so long as your debian/gbp.conf sets things up for other developers to work with the package. It's nice just to merge new upstream versions into a master branch: git merge 1.2.3 or whatever it is tagged. > For the most recent version of my work, please use the master branch, > however the version on mentors is still based off the tag 0.4.0-3 on > debian/sid branch. For the record, this review was based off the master branch. > (Sorry for this 'mess'. Michael Stapelberg has just requested > colab-maint access for me and then things should hopefully be cleaned > up.) collab-maint definitely isn't compulsory, just in case you didn't know. I haven't actually tried to build, install and run the package yet; I thought this review was long enough that I should hit 'send' :) -- Sean Whitton signature.asc Description: PGP signature
Bug#831792: RFS: scid/1:4.6.2-0.1 [NMU]
On Tue, 2016-07-26 at 18:18 +, Gianfranco Costamagna wrote: > control: owner -1 ! > control: tags -1 moreinfo > > > I am looking for a sponsor for my package "scid": [...] > 3) > X: scid source: maybe-not-arch-all-binnmuable scid -> scid-data This lintian tag does not indicate your package has a bug in it. The tags description even states that you should not attempt to fix it. James signature.asc Description: This is a digitally signed message part
Bug#832556: marked as done (RFS: wvstreams/4.6.1-10 [QA, RC])
Your message dated Tue, 26 Jul 2016 20:35:49 + (UTC) with message-id <122340169.8922475.1469565349106.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#832556: RFS: wvstreams/4.6.1-10 [QA, RC] has caused the Debian Bug report #832556, regarding RFS: wvstreams/4.6.1-10 [QA, 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.) -- 832556: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832556 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for the package "wvstreams" * Package name: wvstreams Version : 4.6.1-10 Upstream Author : Net Integration Technologies Inc. et al. * URL : https://github.com/apenwarr/wvstreams/ * License : LGPL-2.1 Section : libs It builds those binary packages: libuniconf4.6 - C++ network libraries for rapid application development libwvstreams-dev - Development libraries and header files for libwvstreams4.6 libwvstreams4.6-base - C++ network libraries for rapid application development libwvstreams4.6-doc - Documentation for WvStreams libwvstreams4.6-extras - C++ network libraries for rapid application development uniconf-tools - Tools to interface with UniConf uniconfd - Server that manages UniConf elements To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wvstreams Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wvstreams/wvstre ams_4.6.1-10.dsc Changes since the last upload: * d/p/gcc-6: Update patch to fix more restrictive interpretation of the standard by g++-6, Closes: #831146 Note with the upload of Version 4.6.1-9 Gianfranco pointed out to me that it would be nice to update to dh-autoreconf too. However, on one hand the package uses nested configure scripts, and I don't know how this should be handled, and on the other hand, the build scripts already calls autoheader and autoconf and manually copies the system versions of config.sub and config.guess. In order to not introduce new bugs I prefer to just fix the RC bug and not change the build system to use dh-autoreconf (I actually tried, but it didn't really work out). many thanks, Gert --- End Message --- --- Begin Message --- Hi, > I am looking for a sponsor for the package "wvstreams" Sponsored, BTW if you have logs for the autoreconf issues, I'm more than happy to check and try to fix them :) /me is not an autoreconf man G.--- End Message ---
Bug#832556: RFS: wvstreams/4.6.1-10 [QA, RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for the package "wvstreams" * Package name: wvstreams Version : 4.6.1-10 Upstream Author : Net Integration Technologies Inc. et al. * URL : https://github.com/apenwarr/wvstreams/ * License : LGPL-2.1 Section : libs It builds those binary packages: libuniconf4.6 - C++ network libraries for rapid application development libwvstreams-dev - Development libraries and header files for libwvstreams4.6 libwvstreams4.6-base - C++ network libraries for rapid application development libwvstreams4.6-doc - Documentation for WvStreams libwvstreams4.6-extras - C++ network libraries for rapid application development uniconf-tools - Tools to interface with UniConf uniconfd - Server that manages UniConf elements To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wvstreams Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wvstreams/wvstre ams_4.6.1-10.dsc Changes since the last upload: * d/p/gcc-6: Update patch to fix more restrictive interpretation of the standard by g++-6, Closes: #831146 Note with the upload of Version 4.6.1-9 Gianfranco pointed out to me that it would be nice to update to dh-autoreconf too. However, on one hand the package uses nested configure scripts, and I don't know how this should be handled, and on the other hand, the build scripts already calls autoheader and autoconf and manually copies the system versions of config.sub and config.guess. In order to not introduce new bugs I prefer to just fix the RC bug and not change the build system to use dh-autoreconf (I actually tried, but it didn't really work out). many thanks, Gert
Bug#831792: RFS: scid/1:4.6.2-0.1 [NMU]
last thing: 4) this hack seems useless now sed s/x86_64-linux-gnu/$(DEB_HOST_MULTIARCH)/ configure > configure.sed chmod 755 configure.sed ./configure.sed BINDIR="$(CURDIR)/debian/tmp/scid/usr/games" \ G.
Bug#831792: RFS: scid/1:4.6.2-0.1 [NMU]
control: owner -1 ! control: tags -1 moreinfo >I am looking for a sponsor for my package "scid": lets see. 1) The package will be probably orphaned in 10-15 days, so you might want to set yourself as Maintainer and adopt it 2) +* Copyright (C) 2013-2015 Fulvio Benini maybe you want also to put copyright file in machine readable format https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 3) X: scid source: maybe-not-arch-all-binnmuable scid -> scid-data 4) the breaks+replaces can be dropped, since that version is already available in oldstable Breaks: scid (<=1:4.3.0.cvs20110714-2) Replaces: scid (<=1:4.3.0.cvs20110714-2) Recommends: scid (>=1:4.3.0.cvs20111216-1) please fix the above and I'll give another review/upload. thanks, G.
Bug#832463: marked as done (RFS: passwordsafe/0.99+dfsg-1)
Your message dated Tue, 26 Jul 2016 15:50:46 + (UTC) with message-id <1607811323.8684417.1469548246722.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#832463: RFS: passwordsafe/0.99+dfsg-1 has caused the Debian Bug report #832463, regarding RFS: passwordsafe/0.99+dfsg-1 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.) -- 832463: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832463 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "passwordsafe" * Package name: passwordsafe Version : 0.99+dfsg-1 Upstream Author : Rony Shapiro =20 * URL : https://pwsafe.org * License : Artistic 2.0 Section : utils It builds those binary packages: passwordsafe - Simple & Secure Password Management passwordsafe-common - architecture independent files for Password Safe To access further information about this package, please visit the follow= ing URL: https://mentors.debian.net/package/passwordsafe Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/passwordsafe/pass= wordsafe_0.99+dfsg-1.dsc More information about passwordsafe can be obtained from https://pwsafe.o= rg. Changes since the last upload: * New upstream version. Closes: 832281 * Recommend xvkbd package. Closes: 829406 * Add patch from Reiner Herrmann for reproducible builds. Closes: 829261 * Update standards version to 3.9.8 (no changes needed) * Remove unneeded patches and refresh remaining patches Regards, Bill Blough signature.asc Description: Digital signature --- End Message --- --- Begin Message --- Hi, > I am looking for a sponsor for my package "passwordsafe" its in g.--- End Message ---
Bug#777651: closing RFS: syncterm/1.0+dfsg-1 [ITP] -- BBS terminal program from Synchronet
control: reopen -1 control: unarchive -1 control: owner -1 jgoer...@complete.org On Tue, 26 Jul 2016 04:33:09 + Bart Martens wrote: > Package syncterm has been removed from mentors. lets try to cc everybody :) thanks G. signature.asc Description: OpenPGP digital signature
Bug#832519: marked as done (RFS: cdist/4.2.2-2 )
Your message dated Tue, 26 Jul 2016 15:22:38 + (UTC) with message-id <711696749.8701441.1469546558900.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#832519: RFS: cdist/4.2.2-2 has caused the Debian Bug report #832519, regarding RFS: cdist/4.2.2-2 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.) -- 832519: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832519 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cdist" * Package name: cdist Version : 4.2.2-2 Upstream Author : Nico Schottelius * Url : http://www.nico.schottelius.org/software/cdist/ * Licenses: GPL-3, GPL-3+ Section : admin It builds those binary packages: cdist -- Usable Configuration Management System cdist-doc -- Usable Configuration Management System (html documentation) To access futher information about this package, visit the following URL: http://mentors.debian.net/package/cdist Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cdist/cdist_4.2.2-2.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git More information about cdist can be obtained from http://www.nico.schottelius.org/software/cdist/ Changes since last upload: * New upstream release Regards, Dmitry Bogatov --- End Message --- --- Begin Message --- Hi, >I am looking for a sponsor for my package "cdist" I changed the version from 4.2.2-2 to 4.2.2-1, and uploaded on deferred/3 g.--- End Message ---
Bug#829205: marked as done (RFS: btrfs-progs/4.5.3-0.1)
Your message dated Tue, 26 Jul 2016 15:08:36 +0200 with message-id <04a147c1-a6f0-1dd4-bfde-fad004467...@debian.org> and subject line Re: Bug#829205: RFS: btrfs-progs/4.5.3-0.1 has caused the Debian Bug report #829205, regarding RFS: btrfs-progs/4.5.3-0.1 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.) -- 829205: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829205 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for this update of "btrfs-progs". I have chosen to update to v4.5.3, because this version does not trigger a bug when combined with linux-4.6.x as discussed in the following email: https://www.spinics.net/lists/linux-btrfs/msg56664.html If the two patches discussed in this email are merged into linux-4.7, I plan to package btrfs-progs-4.6.1 or v4.7 when linux-4.7 is uploaded to unstable: https://www.spinics.net/lists/linux-btrfs/msg56659.html Alternatively, this bug might be fixed in btrfs-progs-4.7. For now, lets use 4.5.3! Here is the upstream changelog post-4.5.2: * ioctl: fix unaligned access in buffer from TREE_SEARCH; might cause SIGBUS on architectures that do not support unaligned access and do not perform any fixups * improved validation checks of superblock and chunk-related structures * subvolume sync: fix handling of -s option * balance: adjust timing of safety delay countdown with --full-balance * rescue super-recover: fix reversed condition check * check: fix bytes_used accounting * documentation updates: mount options, scrub, send, receive, select-super, check, mkfs * testing: new fuzzed images, for superblock and chunks Package name: btrfs-progs Version: 4.5.3-0.1 Section: admin It builds these binary packages: btrfs-progs - Checksumming Copy on Write Filesystem utilities btrfs-progs-dbg - Checksumming Copy on Write Filesystem utilities (debug) btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) (udeb) btrfs-tools - transitional dummy package btrfs-tools-dbg - transitional dummy package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfs-progs Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.5.3-0.1.dsc Changes since the last upload: * Non-maintainer upload. * New upstream release. * Update standards version to 3.9.8 (no changes needed). * Install upstream changelog. (Closes: #824894) * Fix serious errors in debian/copyright. This is not a GPL2+ package. Cme was used to generate a machine-readable copyright file, then manual fixes were made. (Closes: #824896) * Add mangling rules to debian/watch to prefer non-rcN versions; * Add cryptographic signature verification of tarball. Thank you, Nicholas --- End Message --- --- Begin Message --- Closing, a new version is ongoing in unstable right now G. On Fri, 8 Jul 2016 21:34:27 -0400 Nicholas D Steeves wrote: > Hi Adam, > > On 8 July 2016 at 08:58, Adam Borowski wrote: > > Might be RC but certainly isn't urgent. I don't see Nicholas pointing any > > of the upstream changes as immediately important (and I _do_ read > > linux-bt...@vger.kernel.org); debian/copyright changes are hardly ever > > time-sentitive too. > > For 4.5.3, the only potentially urgent fix was for sparc, which is no > longer a 1st tier support arch. > http://www.spinics.net/lists/linux-btrfs/msg54831.html > > I believe the following two fixes in 4.5.3 are probably normal > priority, and are definitely a positive and desirable direction. Does > reducing the probability of a corner case causing a problem count as > important?: > > https://github.com/kdave/btrfs-progs/commit/df2236d73bdffd69cf6d9aac7d80c880b4413aaa > https://github.com/kdave/btrfs-progs/commit/9988284574c1692e5181ecd6f8b9e2512b0503ae > > > Especially that the proposed new contents of debian/copyright is, IMHO, > > containing far more inaccuracies than the old one did. > > I consulted the xfsprogs and linux-src debian/copyrights. Other than > the git repo already mentioned in the file, do you know of another > location that could be cited? I've attached asubstantially simplified > copyright. Would you please review it and offer critique? > > I went for the following approach, similarly to xfsprogs and linux-src: > > * a blanket statement, listing maybe some major holders but with a stress on > > "and others". > > T
Re: Fwd: Re: Preliminary questions for sponsoring a compiler
Paul Wise schreef op 2016-07-26 07:15: On Tue, Jul 26, 2016 at 3:01 AM, Albert van der Horst wrote: It has been published, the generic system is GPL as well. It is on the net since ages http://home.hccnet.nl/a.w.m.van.der.horst/ciforth-5.0.tar.gz and http://home.hccnet.nl/a.w.m.van.der.horst/cifgen.html Wrong! Must be: http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html I doubt that any one has downloaded this in a dozen years ;-( . I see. Indeed not in VCS , but we should not be dogmatic about tarballs that provide a source that is feasible to change, i.e. they are Open Source in actual practice. There is a difference between "I can modify this" and "Open Source". After all, it is possible to modify ELF binaries with a hex editor, objdump or IDA Pro. It is possible to modify minified JavaScript using a text editor. That doesn't make individual ELF files or minified JavaScript files "source". The important thing is equality of access to the work between upstream developers, Debian package maintainers, Debian users, users of Debian derivatives and every other person touching the software in some way. I have included here some links to articles about what "source" or the "preferred form for modification" is: http://www.inventati.org/frx/essays/softfrdm/whatissource.html https://b.mtjm.eu/source-code-data-fonts-free-distros.html https://wiki.freedesktop.org/www/Games/Upstream/#source As an experienced developer I'm familiar with this. In the end it is about knowledge. The comments in my Forth solutions to the projecteuler.net problems are worth more than the code itself. If compilers cease to exist for a language x, the source code is what left and represents the knowledge. I hear you, but consider this. Given the choice to compile c or patch an ELF file, I ( still ;-) ) prefer modifying the c-source. There is a forth loosely based on ciforth : jonesforth. Given the choice between using the generic system and using the assembler source, Mr. Jones chose the assembler source. I should have used the word separate, not private. Ah, that is fine, as long as both are packaged for Debian and appropriate build and runtime dependencies declared. Do you really demand that a Debian package can generate windows executables, and booting floppies in double density? And do you demand to test that to a level approaching Debians (let alone mine) quality standards? It sounds like you are automatically generating some assembler from forth code and then hand-tweaking the assembler? I don't tweak the assembler myself (maybe for a test). Others may, it is a service saving them the considerable time to understand a complicated system in case they want something simple. Also (in contrast to gforth) it is assembler all the way down, but some of it is an assembler representation of Forth code. Could you explain the development workflow here? Let's start with the data. The knowledge to do 64 bits is contained in width64.m4 , there is also width32.m4 and width16.m4. The knowledge to do nasm files is contained in nasm.m4. Other assemblers have their m4's.Last but not least linux.m4 versus msdos32.m4 versus osx.m4 versus alonehd.m4 etc. So we have orthogonal sets of alternatives. Now these are selected by configuration files, also interpreted by m4. Configuration files also contain choices (e.g. "prepared for multitasking") and sizes. A prelude sets defaults, changeable by the configuration file. A postlude makes depending configurations and detects conflicts. (Real mode -> 16 bits. Real mode and 32 bits --> error). A configuration item is an m4 function. Then there is one generic file. Parts of it are protected by a m4 function that decides whether or not it will show up in the output. A configuration file, an assembler selection and the generic file are passed through m4, to generate an assembler source, a test file, and the glossary documentation. (So all documentation is pertinent. It says "a cell size is 64 bits" "you have 8 slots in the search order"). The glossary documentation is sorted by my sssort tool that can specify records by regular expressions, then combined with the other information that also passes through m4. texinfo takes it from there. With all that in place development workflow is trivial: I can add one test line in the generic file, change the name of command >IN to PP, or change the section where a command belongs, increase the size allocated to stacks etc. , and go make stuff, up and including fitting documentation. There is a document contained in ciforth-5.0.tar that discusses when you want to modify at the assembler level, and when at the generic level. It is useful to provide both. I assume you are talking about README.ciforth here? You're awfully optimistic here. That is hardly more than a list of the files involved. The document is called cifgen.ps and is generated via the makefile. It can be downloaded separately: http:
Re: Bug#832299: python-ruffus: FTBFS: sphinx.ext.mathjax: other math package is already loaded
On Mon, Jul 25, 2016 at 09:50:50PM +0200, Christian Seiler wrote: > If you really want your package to build _now_ for some > other reason, you could try to switch the dot format to png instead > of jpg (I would recommend png instead of jpg anyway for graphviz, > because jpg is more suitable for photos and not diagrams). Done since perfectly correct. Thanks for the hint Andreas. -- http://fam-tille.de
Bug#832519: RFS: cdist/4.2.2-2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cdist" * Package name: cdist Version : 4.2.2-2 Upstream Author : Nico Schottelius * Url : http://www.nico.schottelius.org/software/cdist/ * Licenses: GPL-3, GPL-3+ Section : admin It builds those binary packages: cdist -- Usable Configuration Management System cdist-doc -- Usable Configuration Management System (html documentation) To access futher information about this package, visit the following URL: http://mentors.debian.net/package/cdist Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cdist/cdist_4.2.2-2.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git More information about cdist can be obtained from http://www.nico.schottelius.org/software/cdist/ Changes since last upload: * New upstream release Regards, Dmitry Bogatov
Bug#832515: RFS: cdist/4.2.2-2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cdist" * Package name: cdist Version : 4.2.2-2 Upstream Author : Nico Schottelius * Url : http://www.nico.schottelius.org/software/cdist/ * Licenses: GPL-3, GPL-3+ Section : admin It builds those binary packages: cdist -- Usable Configuration Management System cdist-doc -- Usable Configuration Management System (html documentation) To access futher information about this package, visit the following URL: http://mentors.debian.net/package/cdist Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cdist/cdist_4.2.2-2.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git More information about cdist can be obtained from http://www.nico.schottelius.org/software/cdist/ Changes since last upload: * New upstream release Regards, Dmitry Bogatov
Bug#827933: RFS: yabar/0.4.0-3 [ITP]
Thanks for your interest! On 07/24/2016 11:13 PM, Sean Whitton wrote: > I want to review this package more throughly, but I'm a bit confused by > your git repository. You have a branch `debian/sid` which is tagged > `0.4.0-3` but your master branch contains some additional commits. > > If I want to review from git rather than download from mentors, where > should I look? The master branch or the debian/sid branch? I recently switched from developing on the debian/sid branch to the master branch (hence the latter one has more recent commits). gbp by default assumes the build branch is 'master' (except specified via --git-debian-branch). Since I do not yet have a lot of experience with gbp, I am uncertain which work flow is better. (Any recommendations?) For the most recent version of my work, please use the master branch, however the version on mentors is still based off the tag 0.4.0-3 on debian/sid branch. (Sorry for this 'mess'. Michael Stapelberg has just requested colab-maint access for me and then things should hopefully be cleaned up.) signature.asc Description: OpenPGP digital signature