In need of help before RFS

[Boyuan Yang]

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]

[Sean Whitton]

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]

[James Cowgill]

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])

[Debian Bug Tracking System]

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]

[Gert Wollny]

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]

[Gianfranco Costamagna]

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]

[Gianfranco Costamagna]

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)

[Debian Bug Tracking System]

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

[Gianfranco Costamagna]

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 )

[Debian Bug Tracking System]

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)

[Debian Bug Tracking System]

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 

Re: Fwd: Re: Preliminary questions for sponsoring a compiler

[Albert van der Horst]

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:

Re: Bug#832299: python-ruffus: FTBFS: sphinx.ext.mathjax: other math package is already loaded

[Andreas Tille]

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

[Dmitry Bogatov]

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

[Dmitry Bogatov]

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]

[Jack Henschel]

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