Re: afflib package - bug #645915
Hi Christophe, Le lundi 09 janv. 2012 à 08:10:18 (+0100 CET), Christophe Monniez a écrit : Le samedi 07 janvier 2012 à 17:10 +0100, Julien Valroff a écrit : [...] BTW, is there any good reason you use git-dch? I find it very hard to follow the work because of it (but may be due to the fact I am not used to using it). Well, I have no good reason to use it. We really should update our workflow to see who works on what. Does it really matter? I am OK to work on any package but I do not use all of them which explains why I always prefer a regular user tests the changes I have made before uploading. The packages for which I am an uploader means I use it and I am OK to take care of it on a regular basis (ie. follow upstream development, package new releases, fix bugs ASAP etc.). But if someone of the team steps up and upload such a package before I can do it, I am perfectly fine with it. Maybe what we should do is make sure nobody else works on a given package before doing it ourselves (this would avoid duplicate work, but I do not think it has happened in the recent past). It was once said that it's up to the uploader to maintain the changelog because it's automatically generated by git (I suppose git-dch). So, when I work on a package, I don't update the changelog, to not interfere with the uploader work. Am I wrong ? What is the good way of doing it ? I am not used to using git-dch and *I* think it is not needed in our workflow, but I was not aware of the discussion you already had on this point. Remember I am new in the team, and still must have to learn your habits ;) Sorry if I have broken these rules. Now, my question was also on a practical level: what do you see as advantage working with git-dch? I am personally used to debcommit which allows me to keep the standard workflow (eg. dch --team) while still making git commit logs useful. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: afflib package - bug #645915
* Julien Valroff [Mon Jan 09, 2012 at 08:06:14PM +0100]: I am not used to using git-dch and *I* think it is not needed in our workflow, but I was not aware of the discussion you already had on this point. Remember I am new in the team, and still must have to learn your habits ;) Sorry if I have broken these rules. Now, my question was also on a practical level: what do you see as advantage working with git-dch? I am personally used to debcommit which allows me to keep the standard workflow (eg. dch --team) while still making git commit logs useful. Committing without touching the changelog at the same time makes it easier to backport/merge/revert/... stuff. git-dch creates debian/changelog based on the commit messages, keeping the task to create a new release (which includes maintaining the debian/changelog) still easy and simple. Unless there's a *really* good reason to not use git-dch I'd strongly vote for keeping our workflow as it is (WRT debian/upstream branches, git-import-orig, git-dch,...). regards, -mika- signature.asc Description: Digital signature ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: afflib package - bug #645915
Le samedi 07 janvier 2012 à 17:10 +0100, Julien Valroff a écrit : Hi, Le mardi 27 déc. 2011 à 10:06:38 (+0100 CET), Christophe Monniez a écrit : Hi, I worked on this bug [1] to try to solve it. I did a build in a clean environment and found that it was not linked against libreadline. I've just requested a binNMU for i386 to fix the current situation. Once done, we will be able to at least lower the severity of the bug. I leave it up to you if you consider it should be closed or not. Thanks Julien, I will see once the package will be uploaded. The situation comes from an uploader build made in an unclean environment (the last upload was an NMU, hence independent on our work). I have also worked somehow on the package in git but not fixed all the lintian warnings (nor tested it all). I'm working on the other lintian warnings (man pages). BTW, is there any good reason you use git-dch? I find it very hard to follow the work because of it (but may be due to the fact I am not used to using it). Cheers, Julien Well, I have no good reason to use it. We really should update our workflow to see who works on what. It was once said that it's up to the uploader to maintain the changelog because it's automatically generated by git (I suppose git-dch). So, when I work on a package, I don't update the changelog, to not interfere with the uploader work. Am I wrong ? What is the good way of doing it ? -- Christophe Monniez christophe.monn...@fccu.be ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: afflib package - bug #645915
Le mardi 27 décembre 2011 à 13:57 +0100, Julien Valroff a écrit : Hi Christoph, Le mardi 27 déc. 2011 à 10:06:38 (+0100 CET), Christophe Monniez a écrit : Hi, I worked on this bug [1] to try to solve it. I did a build in a clean environment and found that it was not linked against libreadline. I was disappointed and asked for help on debian-mentors IRC channel. It seems that the package was build in a n unclean environment before upload. I thought that packages were always built in a clean environment. Except for the binary package built by the uploader (well, actuall, it should be built in a clean environment, but nothing can guarantee this). Anyway, this situation can be easily solved by uploading the latest afflib which is in our git repository. So, Mika or Julien, could you have an eye on this package and upload it to close this bug ? There are a few things to check before the package can be uploaded, here is the output of lintian: I: afflib source: missing-debian-source-format W: afflib source: patch-system-but-direct-changes-in-diff ChangeLog and 33 more W: afflib-dbg: debian-changelog-line-too-long line 1 W: afflib-dbg: debian-changelog-line-too-long line 5 W: libafflib-dev: debian-changelog-line-too-long line 1 W: libafflib-dev: debian-changelog-line-too-long line 5 W: libafflib0: debian-changelog-line-too-long line 1 W: libafflib0: debian-changelog-line-too-long line 5 I: libafflib0: no-symbols-control-file usr/lib/libafflib.so.0.0.0 W: afflib-tools: debian-changelog-line-too-long line 1 W: afflib-tools: debian-changelog-line-too-long line 5 W: afflib-tools: binary-without-manpage usr/bin/affcompare W: afflib-tools: binary-without-manpage usr/bin/affconvert W: afflib-tools: binary-without-manpage usr/bin/affcopy W: afflib-tools: binary-without-manpage usr/bin/affcrypto W: afflib-tools: binary-without-manpage usr/bin/affdiskprint W: afflib-tools: binary-without-manpage usr/bin/affinfo W: afflib-tools: binary-without-manpage usr/bin/affix W: afflib-tools: binary-without-manpage usr/bin/affrecover W: afflib-tools: binary-without-manpage usr/bin/affsegment W: afflib-tools: binary-without-manpage usr/bin/affsign W: afflib-tools: binary-without-manpage usr/bin/affstats W: afflib-tools: binary-without-manpage usr/bin/affuse W: afflib-tools: binary-without-manpage usr/bin/affverify W: afflib-tools: binary-without-manpage usr/bin/affxml All of them should be quite easy to fix - the manpages can be easily generated via help2man (and then, forwarded upstream). The changes made to upstream sources must be fixed. Here are the details of what is actually changed: dpkg-source: warning: the diff modifies the following upstream files: ChangeLog Makefile.in aclocal.m4 affconfig.h.in afflib.spec configure configure.ac doc/Makefile.in lib/Makefile.in lib/afflib.h lib/afflib_i.h lib/afflib_pages.cpp lib/afflib_stream.cpp lib/afflib_util.cpp lib/aftimer.h lib/lzma_glue.cpp lib/utils.h lib/vnode_afd.cpp lib/vnode_aff.cpp ltmain.sh lzma443/Makefile.in man/Makefile.in pyaff/Makefile.in tests/Makefile.in tools/Makefile.in tools/affcat.cpp tools/affcompare.cpp tools/affconvert.cpp tools/affcrypto.cpp tools/affinfo.cpp tools/affix.cpp tools/affverify.cpp tools/affxml.cpp win32/affconfig.h I can help if needed, but don't know much about this package. Cheers, Julien Thanks Julien, it clarifies what I have to do. I'll take a look quickly. I don't know where the diff's come from, will investigate. -- Christophe Monniez christophe.monn...@fccu.be ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
afflib package - bug #645915
Hi, I worked on this bug [1] to try to solve it. I did a build in a clean environment and found that it was not linked against libreadline. I was disappointed and asked for help on debian-mentors IRC channel. It seems that the package was build in a n unclean environment before upload. I thought that packages were always built in a clean environment. Anyway, this situation can be easily solved by uploading the latest afflib which is in our git repository. So, Mika or Julien, could you have an eye on this package and upload it to close this bug ? Thanks for your help. 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645915 -- Christophe Monniez christophe.monn...@fccu.be ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
