Bug#890756: RFS: youtube-dl/2018.01.27/1.1 [NMU] -- downloader of videos from YouTube and other sites
Control: tag 890756 + moreinfo
Control: tag 890119 + moreinfo
On Feb 18 2018, Nicolas Braud-Santoni wrote:
> Package: sponsorship-requests
> Severity: normal
> Control: block 890119 by -1
> Control: tag 890119 + pending
> Control: tag -1 + security
>
> Hi,
Hi, Nicholas.
There's no need to rush with any upload, as I am going to take care of that
myself.
BTW, we had, essentially, a whole week of extended holidays here in Brazil
during this week (Carnival), which was the reason why I had not replied
earlier (poor connectivity etc.).
> I'm looking for a sponsor for this NMU against youtube-dl.
I am not a security expert (I only have a day-to-day, working knowledge of
security), so I don't really know enough to be able to disagree with your
assessment of the situation, but the upstream maintainers have a reasonably
good (and are famed) for being security-minded and/or crypto experts.
> It removes youtube-dl's built-in autoupdate mechanism, whose security
> is unclear and which is defunct on Debian anyhow (see #890119 for details).
I am OK (not super happy, but OK) with the removal of the --upgrade option
of youtube-dl, *BUT* I think that removing it completely and giving the
users that try to invoke the command with that option something like "option
not recognized" is a poor user-experience.
We should, *IF* we remove the option, substitute it with an output saying
that in Debian (and other derived distributions) we have disabled that
option. Not having this will make users confused, since it would deviate
from the behavior of upstream.
Speaking as a user (not as the maintainer) of youtube-dl, that's something
that I would expect from *any* Debian package: document conspicuously the
differences between the package that we have in Debian and what upstream
offers.
Ideally, we should propose something better for upstream, even if we don't
end up using it in Debian itself.
> @Rogério: This exactly adds the patch I sent to the packaging repository in
> https://github.com/rbrito/pkg-youtube-dl/pull/2
> However, since the state of the packaging repository is inconsistent
> with what is in the Debian archive, you will need to push to the
> repository, merge my PR, and then manually grab the updated
> changelog.
Yes, I have not yet taken the time to migrate things to salsa.debian.org. I
will do as soon as I get familiar with the needed changes.
I will post the comments above as a review on your pull request...
> The updated version of the package is available on mentors.d.n :
>
> https://mentors.debian.net/package/youtube-dl
>
> https://mentors.debian.net/debian/pool/main/y/youtube-dl/youtube-dl_2018.01.27-1.1.dsc
>
>
> Note that there are 2 minor issues in the package that I did not change:
> - The package still uses dh 10
> I have no idea whether the maintainer wants to switch to dh 11
That's on purpose/intentional, to ease backporting for people that don't
have a debhelper so recent.
Actually, the main functionality of the resulting program will not change
that much with a newer debhelper, which means that the change will be only a
formal change, AFAICS...
> - groff throws a warning on the youtube-dl(1) manpage (lintian tag
> manpage-has-errors-from-man), but I believe this is out of scope for this
> NMU.
This problem has been communicated upstream and we reached the conclusion
that it is a problem with pandoc...
All that being said, I will upload a new version of youtube-dl during the
next few days...
Regards,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
RFC: jbig2enc -- JBIG2 encoder
Dear mentors,
I've been (re-)getting up to speed with my packaging skills and I have an
scratch to itch. I would, therefore, kindly request your comments on the
following package:
- - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - -
* Package name: jbig2enc
Version : 0.28+git0693dcd-1
Upstream Author : Adam Langley <a...@imperialviolet.org>
* URL : https://github.com/agl/jbig2enc
* License : Apache-2.0
Section : graphics
It builds those binary packages:
jbig2enc- JBIG2 encoder
libjbig2enc-dev - JBIG2 encoder (development files)
libjbig2enc0- JBIG2 encoder (shared library)
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/jbig2enc
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/j/jbig2enc/jbig2enc_0.28+git0693dcd-1.dsc
I also maintain my changes in a repository in git-buildpackage form at:
https://github.com/rbrito/pkg-jbig2enc
More information about jbig2enc can be obtained from
https://github.com/agl/jbig2enc.
- - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - -
Apart from lintian's binary-without-manpage/dh-make-template-in-source which
are about a manpage for jbig2 (I still have to decide how to proceed in the
best way with respect to this), are there any problems with the package?
I do *not* consider this package yet ready for primetime, since I'm not sure
what to do with the pdf.py script yet that it contains (it creates PDF files
from jbig2-encoded files).
The reason why I'm titling this to be a RFC instead of a RFS is because it's
been a while since I last packaged a package that had a library and my
packaging-fu regarding the last 5 or so years relative to libraries are
starting to show up.
Thanks in advance,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: Bug#724195: Unable to upload a fix for 724195 (RC, FTBFS)
Dear Andrew,
On Oct 24 2013, Andrew Shadura wrote:
On 24 October 2013 05:41, Rogério Brito rbr...@ime.usp.br wrote:
I have just tried to upload a fix for this bug, but it seems that, with the
transition from the DMUA flags, I lost the privileges of uploading this one.
You can find an updated packaging in any of the following repositories:
https://github.com/rbrito/pkg-hfsprogs
I've uploaded this one.
Thanks a lot for uploading this.
ssh://git.debian.org/git/collab-maint/youtube-dl.git
And this one you probably don't want ;)
Ooops. :) That's what you get when you are maintaining too many packages,
wearing upstream hats, writing blogs, studying a lot and sleep deprived. :)
Sorry for that and, again, thank you very much,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
signature.asc
Description: Digital signature
Unable to upload a fix for 724195 (RC, FTBFS)
Package: hfsprogs
Version: 332.25-10
Followup-For: Bug #724195
Hi.
I have just tried to upload a fix for this bug, but it seems that, with the
transition from the DMUA flags, I lost the privileges of uploading this one.
You can find an updated packaging in any of the following repositories:
https://github.com/rbrito/pkg-hfsprogs
ssh://git.debian.org/git/collab-maint/youtube-dl.git
If anybody could help me, that would be one RC bug less for Debian.
Thanks.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (650, 'testing'), (500, 'unstable'), (10, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages hfsprogs depends on:
ii libbsd0 0.6.0-1
ii libc62.17-93
ii libssl1.0.0 1.0.1e-3
hfsprogs recommends no packages.
hfsprogs suggests no packages.
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
signature.asc
Description: Digital signature
Re: RFS: tunesviewer/1.4.99.2-1
Hi there.
On Aug 27 2012, Rogério Theodoro de Brito wrote:
I am looking for a sponsor for my package tunesviewer.
(...)
# Long description
TunesViewer is a small, easy-to-use program to access iTunesU media and
podcasts from Linux. TunesViewer lets you:
(...)
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/t/tunesviewer/tunesviewer_1.4.99.2-1.dsc
(...)
Is there anybody that could comment on the package?
I would love to have this in Debian, since there are no tools for accessing
iTunes U with a non-{Windows,MacOS X} operating system and this program
fixes this situation.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120830073846.ga5...@ime.usp.br
Re: RFS: Cool Reader
Hi, Vadim.
Please, just continue keeping me CC'ed. I am not currently subscribed to
-mentors.
On Feb 13 2011, buggins wrote:
Hello Rogério,
I've already updated package (fixed issues suggested by Anton Gladky)
Great.
== Start quote ==
I've fixed lintinan pedantic findings, changed target to unstable, wrote
machine-readable copyright.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/c/cr3
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/c/cr3/cr3_3.0.43-12.dsc
Great. I just downloaded it.
* code compilation complains about warnings, some of them can be
serious (it is up to you)
I've checked warnings and found nothing serious. Will clean them up later.
Some of the problems with reallocating a larger piece of memory may be
critical, especially with embedded computers or phones.
BTW, a new version of cppcheck was just uploaded to unstable and it would be
nice if you could run those.
I have some questions.
Some parts of source package are really not used for debian build (e.g.
wxWidgets frontend, Android frontend, snapshots of zlib, libjpeg, libpng,
libfreetype libraries).
Right.
Is it ok to leave them in source package?
Should I add licensing details to debian/copyright for zlib, libjpeg,
libpng, libfreetype libraries? (not used in debian build)
Yes, it is OK to leave them in the source package, but you have to state the
license in debian/copyright and, in any case that you have sources with
conflicting licenses, state that what you are doing is OK, since you are not
using them.
* Formats: epub (non-DRM), fb2, txt, rtf, html, chm, tcr formats
supported, can read books directly from zip archives
* Most complete FB2 format support: styles, tables, footnotes
* Styles can be customized in wide range using external CSS (subset of
CSS2 and CSS3)
* Hyphenation dictionaries (from AlReader or FBReader)
* Pages or scroll view
* Table of contents
* Text search
* Recent books list
* Bookmarks (including comments or corrections for text range)
* Automatic reformatting of .txt files (autodetect headings etc.)
* Customizable look feel, font face/size/weight, colors for text and
background, images for backgrounds (tiled or stretched)
* Font kerning, anti-aliasing
* Optional floating punctuation on right text bound for justified text
(punctuation and hyphenation signs moved outside right text block bound, for
better visual alignment)
* Formatted book is swapped/cached to file, and can be reopened very
fast. Also, this feature allows to open books larger than available RAM
size.
You should add those features to the long description. They are very useful
to know when deciding which package one should install.
CoolReader can be considered as competitor of FBReader.
Provides features missing in FBReader: tables, footnotes, CSS styles.
You may tell that in the long description also, but such a comment may
become
Screenshots are available on http://www.coolreader.org/
Perhaps you may want to use that page in the Homepage field of the control
file instead of the one from sourceforge?
Also, when your package gets accepted, you may want to choose one screenshot
and upload it to http://screenshots.debian.net.
You should state the version of the GPL that you are using.
It uses GPL-2. Should I repost RFS? Wouldn't it be considered as
spam/flood?
Yes, you *will* have to repost a RFS whenever you update the package. Just
keep in mind that some sponsors *don't* like to see the debian revision
incremented until the package reaches the main Debian repository.
Regarding the license, is it GPL-2 or GPL-2+? If a sponsor runs the
licensecheck program on the crengine directory, he/she will get a lot of No
copyright or UNKNOWN messages.
Just stick some boilerplate in those files and you're done.
As another point that the potential sponsors would, perhaps, want to
know is the language in which the program was written, because many have
restrictions to some languages.
A quick glance at the git repository that you informed shows that it is
written in C++.
Yes, it's written in C++. Main part is XML/CSS rendering engine,
CREngine, used by different frontends.
OK. Please, put the indication of the language in the RFS, so potential
sponsors can decide if they want to upload or not.
There are Qt and wxWidgets frontends for desktop.
(Qt version is under development, wxWidgets is not supported).
As a side comment: It's great to have a Qt frontend, especially since the
Nokia N900 comes with it and that would mean one fewer dependency to
install.
I'll try to fix cppcheck findings and compilation warnings.
Great.
Once it's done, should I repost RFS for the package?
Yes, definitely.
Hope this helps,
--
Rogério Brito : rbrito@{ime.usp.br
Re: RFS: Cool Reader
Dear Vadim,
On 02/02/2011 07:33 AM, bugg...@fromru.com wrote:
I am looking for a sponsor for my package cr3 (Cool Reader 3).
Package name: cr3
Version : 3.0.43-2
License : GPL
You should state the version of the GPL that you are using.
It builds these binary packages:
cr3 - e-book reader
As I very recently bought a Nokia N900 and the current ebook readers are very,
very slow with some books that I purchased from O'Reilly, I am on the market
for an alternative and yours sounds promising.
But you, perhaps, forgot to include the debian.tar.gz file that contains the
packaging itself:
http://sourceforge.net/projects/crengine/files/CoolReader3/cr3-3.0.43/cr3_3.
0.43.orig.tar.gz/download
http://sourceforge.net/projects/crengine/files/CoolReader3/cr3-3.0.43/cr3_3.
0.43-2.dsc/download
http://sourceforge.net/projects/crengine/files/CoolReader3/cr3-3.0.43/cr3_3.
0.43-2_i386.changes/download
(...)
As another point that the potential sponsors would, perhaps, want to know is the
language in which the program was written, because many have restrictions to
some languages.
A quick glance at the git repository that you informed shows that it is written
in C++.
That being said, cppcheck issues a lot of warnings and some errors regarding the
code in the crengine subdirectory of your git tree, which I didn't investigate
further:
[./include/lvpagesplitter.h:79]: (error) Common realloc mistake: _list nulled
but not freed upon failure
[./include/lvpagesplitter.h:89]: (error) Common realloc mistake: _list nulled
but not freed upon failure
[./include/lvpagesplitter.h:101]: (error) Common realloc mistake: _list nulled
but not freed upon failure
[./include/lvtinydom.h:1088]: (error) Memory leak: ldomXPointer::_data
Removing some of the checks for null pointers before deallocation would,
perhaps, make the application smaller (and easier to fit in the memory of cell
phones etc).
Source code GIT repository:
git://crengine.git.sourceforge.net/gitroot/crengine/crengine
I would be glad if someone uploaded this package for me.
Best regards,
Vadim
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d4e8958.6020...@ime.usp.br
Re: RFS: compactheader (updated package)
Hi, Williams.
The package is better, but there are still some issues (I hope that this
gets uploaded as I am itching to use it).
On Sep 03 2010, Williams Orellana wrote:
xul-ext-compactheader - Icedove extension to reduce header size to on or
two lines
* The short description has a typo onE or two lines.
* The watch file treats beta versions as final versions. Please steal
the file that I put on my PPA:
https://launchpad.net/~rbrito/+archive/ppa/+files/icedove-compact-headers_1.2.4-1%7Eppa0.dsc
* You forgot to change the license of your packaging to be the same of
the upstream package.
* Another thing to think about: I like the way to avoid copies of
licenses of common packages (e.g., the MPL-1.1), but I am not sure if
refering to other package's files (aside from /usr/share/common-licences)
is allowed.
This is especially the case as you are refering to a package that may
not be installed when you install your package. I guess that you
should probably refer to the xulrunner package instead of iceweasel.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100903202652.ga25...@ime.usp.br
Re: RFS: compactheader (updated package)
Hi there, Williams.
On Sep 03 2010, Williams Orellana wrote:
I have re-uploaded the package
Good job! I hope you get sponsors on this soon. Just to help you here:
dget
http://mentors.debian.net/debian/pool/main/c/compactheader/compactheader_1.2.4-1.dsc
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100903211143.gb25...@ime.usp.br
Re: question about proprietary libraries
Hi there.
On Sep 01 2010, Stephen Sinclair wrote:
I don't have the ability to reverse engineer it and write my own
drivers, but I'd still like users of this device to be able to make
use of my software.
Right. You can dlopen the library, depending on the case. Your program
will still be Free, in the same sense that the Linux Kernel is Free.
You may want to check the license that you will eventually use: I think
that the GPL wouldn't cut it, but the LGPL might.
Would such a library have difficulty getting accepted by Debian?
The library, yes. Your program? No, depending on how dependent the
program would be on that library. If the use of said devices is just a
minor part of the program's role, then it may be accepted into main,
without any problems.
OTOH, if it needs the library, then the most that you would be able to
do with your program would be to go into contrib.
Does this answer your question?
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100902080340.ga7...@ime.usp.br
Re: RFS: compactheader
Hi there.
On Sep 02 2010, Williams Orellana wrote:
I am looking for a sponsor for my package compactheader.
Thank you very much for taking the time to package this extension. It is
so useful and it is hard to understand why this code is not in
Thunderbird anymore, but relegated to an extension. :-(
* Package name: compactheader
Version : 1.2.3-1
Version 1.2.4 is already available, isn't it?
Upstream Author : Joachim Herb
* URL : http://compactheader.mozdev.org/
* License : MPL-1.1+
Section : web
Perhaps section mail would be more appropriate?
I have not yet taken a look at your package, but I needed some
extensions badly and I went ahead and packaged some (not exactly proper
for public consumption).
If you want, just point your browser to:
https://launchpad.net/~rbrito/+archive/ppa
The mailredirect extension is also very useful (it provides the same
functionality of Mutt's bounce).
Regards.
P.S.: Be warned that you will encounter horrors regarding packaging in
that repository. :-)
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100903045153.ga6...@ime.usp.br
Re: RFS: compactheader
Hi.
On Sep 02 2010, Williams Orellana wrote:
I am looking for a sponsor for my package compactheader.
A quick follow up to comment on your package:
* Please, package version 1.2.4.
* Are you sure that the license is MPL-1.1+ and not the tri-license?
* Your packaging is under the GPL-3+ and this will cause any changes
that you make to not be able to be pushed upstream (say that you
produce a patch).
Please, consider always having the packaging in the same terms as the
upstream software, even if you would prefer another license.
* The short description should start with a lowercase letter.
* Your watch file doesn't seem to work:
,
| rbr...@chagas:/tmp/compactheader-1.2.3$ uscan --report-status
| uscan warning: In debian/watch,
| no matching hrefs for watch line
|
https://addons.mozilla.org/en-US/thunderbird/downloads/file/92157/xpi/compactheader\-([\d\.]*)\-tb\.xpi
debian xpi-repack
| rbr...@chagas:/tmp/compactheader-1.2.3$
`
It took me some time to figure out the better solution to use with
mozilla addons. Just look into
ftp://ftp.mozilla.org/pub/addons/13564/
Be careful to regard the betas as lower than the final releases.
Something like mangling the upstream version with s/beta/~beta/
works.
* A more philosophical question is that of using xpi-repack to pack an
extension: that simply seems to me like packaging the binary product
of a program and not using the source code.
I did this with the packages that I mentioned on my earlier e-mail,
but I still think that this is wrong.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100903050749.gb6...@ime.usp.br
Re: RFS: faenza-icon-theme
Hi.
On Aug 30 2010, Rogério Brito wrote:
On Aug 30 2010, Adnan Hodzic wrote:
- dget
http://mentors.debian.net/debian/pool/main/f/faenza-icon-theme/faenza-icon-theme_0.7.dsc
Oh, there's one obvious thing that I didn't catch in the previous look
at your package: it is a Debian native package (meaning that it is
intended to be used only with Debian), but it should be non-native
instead.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100831191348.gb3...@ime.usp.br
Re: RFS: faenza-icon-theme
Hi there.
On Aug 30 2010, Adnan Hodzic wrote:
* URL : [http://tiheum.deviantart.com/art/Faenza-Icons-173323228]
I just did a quick look and you are right that this theme is indeed
beautiful.
My motivation for maintaining this package is: [I want to build a
whole theme, and these icons are part of it. IMHO these are most
popular and most sexy icons right now, it would be great if they were
in Debian officially].
What about the other parts? Just to have an idea of where this is going to...
- dget
http://mentors.debian.net/debian/pool/main/f/faenza-icon-theme/faenza-icon-theme_0.7.dsc
IANADD, but I took a few minutes to see what you did.
* One of the first things was that the long description of the package
has its lines split.
Any particular reason for that? That's annoying. Are you trying to
circumvent the lintian message that your long description may be too
short?
You can surely put some other text there to give the users a better
idea of what the theme is about (and it being beautiful would be bad
if skipped).
* You state in the debian/copyright file that the license is GPL, but
the text is GPLv3+ and you provide instructions for the user saying
that the text of the GPL on Debian systems is under a versioned name.
It is better to make everything versioned here.
* You claim copyright on the Debian packaging, but what is the license?
If you don't specify it, then it is possible to interpret that your
work mixed with the upstream GPL is not distributable.
A usual thing to do is to make your changes be the same as the rest of
the package (with the added side effect that your changes can be
integrated upstream easily).
* The index.theme file in the Faenza directory says that it inherits
Humanity, ubuntu-mono-light, gnome. What about recommending/suggesting
those packages, depending on the status of their Freedomness?
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100831012649.ga2...@ime.usp.br
Re: conffiles
On Aug 30 2010, Russ Allbery wrote:
Matthew Palmer mpal...@debian.org writes:
You should never need to list files in /etc as conffiles, as they're
detected and a conffiles written out at package build time (because
Policy says all files in /etc are conffiles).
This is only true if you're using debhelper, and from previous messages I
believe the original poster is learning packaging by taking a more manual
approach.
Yes. And only if you are using some certain compatibility levels (=5).
Granted, those are likely to be used nowadays, but there are still some
packages that don't use any package helper at all (e.g., magicfilter).
Well, depending on the simpleness of the package, I usually write the
DEBIAN directory directly and the binary *is* the preferred format of
the source. :-)
Another remarkable case when this happens is when you create a
linux-image package from Linus's newer trees: nowadays, it can be a much
lighter-weight alternative to kernel-package.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100831020427.ga12...@ime.usp.br
Re: Default Configuration Issues
Hi, Paul.
On Aug 13 2010, Paul Tagliamonte wrote:
I'm a co-maintainer on the Fluxbox package.
I happen to be a user of fluxbox.
Oh, just one stylistic note about the way that you write things both in
your text and in your changelogs:
( even though they have had regular development since then ).
You seem to put one space after a left parenthesis and one before the
right parenthesis. The usual rules for typesetting text dictates that
there should be no such spaces. Therefore, the text above should be
written as:
(even though they have had regular development since then).
The stock ( un-configured ) behavior of Fluxbox was to allow
window-dragging with a left-click.
You probably meant window dragging with a left click on the title bar,
right?
Since this was stock before, the old version of the debian keys file
does not have the configuration directive ( OnTitlebar Mouse1
:StartMoving ) to enable left-click window moving.
OK.
I found this out early, and patched the global configuration file.
OK.
Fluxbox, however, copies the file to the ~/.fluxbox folder,
the file means the global configuration file?
and uses that without checking for additional directives in the global
conf file. Whoops.
This is not clear: you say that uses that (the global config file?)
without checking for additional directives in the global conf file.
If it is using the global configuration file, it is honoring the
settings there, isn't it?
Your description didn't sound precise here.
This is causing breakage of old installs that are upgrading. What is
the right way of fixing this?
In general, a change in behavior can be handled gracefully with some
time for transitions, so that they users can adapt to that (before
that becomes the default) and with a conspicuous notice (say, in NEWS).
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100814055539.ga2...@ime.usp.br
Re: [Pkg-mozext-maintainers] RFS: useragentswitcher
Hi there.
On Aug 05 2010, Benjamin Drung wrote:
Am Mittwoch, den 04.08.2010, 14:13 -0600 schrieb Williams Orellana:
I am looking for a sponsor for my package useragentswitcher.
(...)
Your debian/rules could even be more shorten with --buildsystem=xul_ext.
With the build system you need to only override dh_auto_install.
Since you may be involved in one way or another with extension for
mozilla stuff, it would be very nice if we had
https://addons.mozilla.org/en-US/thunderbird/addon/13564/
http://compactheader.mozdev.org/index.html
For saving screen space with thunderbird, if it is not packaged yet (I
didn't find it).
One could (can) download it from the site, but I tend to trust the
packages in the Debian archive more than the ones that are available in
other sites.
(I trust Debian people to review the programs that they package/upload).
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100812021938.ga13...@ime.usp.br
Re: My pending RFSs (xpdf) -- patch update suggestion
Hi there, Osamu.
On Jul 17 2010, Osamu Aoki wrote:
=== xpdf-zoom-height.patch ===
I worked on this patch issue and got this fixed.
I guess that, due to timezone issues, you pulled the trigger faster than
I could look into this issue, but that's great. :-)
I realize you have alioth git repo but it was just debian directory
only and it is not well tagged either by missing releases. Since git
is light, why not have upstream and pristine-tar committed?
That is my preference also (and I also like the use of git-dch, but I
don't know about Michael[1][2]).
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580621#94
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580621#102
Also in order to get full picture of changes you made, I imported
previous stable and published packages as much into git repo on my
user account as:
http://git.debian.org/?p=users/osamu/xpdf.git
git://alioth.debian.org/git/users/osamu/xpdf.git (for you to pull)
Now it is -9.
Great.
xpdf (3.02-9) unstable; urgency=low
* Reactivate zoomFitHeight properly by merging it into fix-580495.patch.
* Set VCS-* and Uploaders fields.
-- Osamu Aoki os...@debian.org Sat, 17 Jul 2010 16:00:23 +0900
Question: Can I upload as this?
As far as I know, it would be Michael's desire to get this ASAP into the
archives.
PS: If you agree, can we replace proper git repo with my user one? then
workin on updates become easier. If there are change history
data between 3.02-2 to 3.0-5 and 3.0-7 even as uploaded packkage,
recreating readable history was a bit easier.
Do you mean copying yours to the collab-maint repo? If yes, then I can't
see any problems with that, and I think that Michael would be appreciate
of that. :-)
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100717110346.gb8...@ime.usp.br
Re: My pending RFSs (xpdf, ushare, protoaculous, gordon, checksec)
Hi there, people.
On Jul 16 2010, Osamu Aoki wrote:
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/x/xpdf
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/x/xpdf/xpdf_3.02-3.dsc
But I only see:
http://mentors.debian.net/debian/pool/main/x/xpdf/xpdf_3.02-8.dsc
Yeah, Michael decided to increment the revisions and I followed suit in
the packaging:
* http://git.debian.org/?p=collab-maint/xpdf.git
It looks very nice. I have a question.
I do not see security patches on the web in your patches:
xpdf-3.02pl1.patch: a patch for a security hole (1050 bytes)
xpdf-3.02pl2.patch: a patch for security holes (20843 bytes)
xpdf-3.02pl3.patch: a patch for security holes (30727 bytes)
xpdf-3.02pl4.patch: a patch for security holes (6982 bytes)
You may want to read this:
* http://github.com/rbrito/xpdf-poppler/blob/master/README.md
* http://rb.doesntexist.org/blog/2010/05/27/please-let-me-zoom-my-documents/
*
http://rb.doesntexist.org/blog/2010/06/10/a-version-of-xpdf-with-the-poppler-backend-available/
This is too big a package for me to review now but very good work.
Not that big... :-) I took care to comment each of the patches in the
commit list of the xpdf-poppler fork that I am maintaining in github.
Also, I am including other people that may also be interested in getting
an updated version of xpdf in Debian.
While I prefer the version of poppler that I am maintaining I think
that, for less disruptive changes, Michael's version may be preferrable.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100716021307.ga7...@ime.usp.br
Re: My pending RFSs (xpdf, ushare, protoaculous, gordon, checksec)
On Jul 16 2010, Paul Wise wrote:
As to what you could be doing differently, try kidnapping a few DDs
from DebConf and forcing them to sponsor your packages ;)
Will you be there? :-)
/me goes to buy those airplane tickets. :-)
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100716023700.ga7...@ime.usp.br
Re: RFS: zathura
Hi there, Sebastian.
On Jul 15 2010, Sebastian Ramacher wrote:
I am still looking for a sponsor for zathura.
Unfortunately, I can't sponsor your upload, but the packaging looks fine
at a first brief look (I have not yet tried to compile it---I am reading
the packaging side of things for the moment).
I would just suggest that you add a line to the control file putting a
Provides: pdf-reader and adding something like the update-mime stuff
to register it with the system, so that it is picked up for pdf files.
You can see an example of this with, say, xpdf and the documentation of
update-mime(8).
Otherwise, that's a good job. Thanks.
Kind regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100714224228.ga9...@ime.usp.br
Re: RFS: zathura
Hi there.
On Jul 15 2010, Sebastian Ramacher wrote:
I've updated the package.
Did I do something wrong here? I got this:
,
| tmp$ dget -xu
http://mentors.debian.net/debian/pool/main/z/zathura/zathura_0.0.7-2.dsc
| (...)
| dget: removing zathura_0.0.7.orig.tar.gz (md5sum does not match)
| dget: retrieving
http://mentors.debian.net/debian/pool/main/z/zathura/zathura_0.0.7.orig.tar.gz
`
Oh, BTW, some sponsors would prefer to have the debian revision constant
if the previous revisions didn't get uploaded to Debian's official
repository. Some don't mind the change.
Other than that, the packaging seems sane.
Kind regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100715002302.ga12...@ime.usp.br
Re: RFS: xpdf (updated package)
Hi there.
On Jun 20 2010, Michael Gilbert wrote:
I would be very appreciative if anyone has the time to review and
sponsor this package. See new version at:
http://mentors.debian.net/debian/pool/main/x/xpdf
I just got time for a mini-review.
* Nice that you added credits to me for a patch;
* Would you consider including the latest versin of the zooming patch
that I sent you?
* debian/compat is 5, but you build-depend on debhelper 7.
* the long description of the xpdf *binary* package mentions that it is
only for compatibility and that it can be safely removed. That's not the
case anymore.
* does xpdf *really* provide a postscript-preview virtual package?
* not that it matters much, but xpdf-{common,reader,utils} could be made
arch all instead of arch any.
* minor thing: there are some ugly spaces before commas in some of the
relationship fields.
* minor thing: since we are not shipping a library, there isn't a very
strict requirement of the transitional binary packages be steplocked
with the main binary. Therefore, the binary:Version substitution
variable could be relaxed to source:Version (there won't be a problem
with binNMU's).
If the packages are converted to arch all instead of any, then this
need becomes even lower.
* Your override_dh_auto_build target of debian/rules doesn't seem to
respect the linking time flags.
Could you add something like $(LDFLAGS) to the final compilation?
* does xpdf.postint still needs to have the code for backwards
compatibility with xpdf 2.01-1?
* it would be so darned nice if zxpdf handled:
+ xz compressed files.
+ pdf files with case-insensitive extensions, as, sometimes, .Pdf
files are seen in the wild.
From the functional side of the package, though, it looks sane.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100621040557.ga9...@ime.usp.br
Re: RFS: xpdf (updated package)
On Jun 12 2010, Norbert Preining wrote:
On Fr, 11 Jun 2010, Rogério Brito wrote:
I am very confused with the svn repo of texlive. I did find an
apparently unpatched version of ps_view (is its name there psv?), but no
adaptations.
Hmm, maybe I missed that we are in line now ...
Thanks. I will revisit that very soon.
It seems to depend on wxlua, right? Is this packaged in our
archives? I didn't find the necessary headers, but I am interested
in trying it out, sure.
No, not packaged. That is the reason I started on it for packaing.
Thank you very much for packaging it.
If you just want to try it once and are using amd64 then get
http://www.logic.at/people/preining/software/psv.tar.gz
it contains a dir that can be stowed/graft-ed/whatever into your
/usr/local hierarchy, or run the scripts simply from the unpacked dir,
easy to understand.
I just downloaded it and it is fine for high res looks on the file.
Thank you very much, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100621045500.ga10...@ime.usp.br
Re: RFS: xpdf (updated package)
Hi there.
On Jun 21 2010, Michael Gilbert wrote:
On Mon, 21 Jun 2010 01:05:57 -0300 Rogério Brito wrote:
* Would you consider including the latest versin of the zooming patch
that I sent you?
Where is that at? Has it been well-tested? The previous zoom patch
broke a bunch of other things, and I've disabled it for now. If this
new version has been sufficiently tested, I will consider it.
Please, notice that I am not talking about the zoom to fit, height or
anything else. I am talking about higher zoom factors, that I posted here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=flexibilize-zoom-levels.patch;att=1;bug=580495
It was one of the first things that I did as soon as I started hacking
on xpdf. It is quite stable and should also work with vanilla xpdf.
* minor thing: since we are not shipping a library, there isn't a very
strict requirement of the transitional binary packages be steplocked
with the main binary. Therefore, the binary:Version substitution
variable could be relaxed to source:Version (there won't be a problem
with binNMU's).
I tried a couple ways of doing this, and they all resulted in lintian
errors; whereas the current approach doesn't, so I'm sticking with it.
A patch is welcome.
I just went ahead and changed things on the package at collab-maint. I
did not include my patch above, though, since I want you to see it (but
I am using it and it works well).
Thanks for your review!
You're welcome.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100621053912.ga11...@ime.usp.br
Re: RFS: checksec
On Jun 19 2010, Michael Gilbert wrote:
My motivation for maintaining this package is: This script is provides
useful information about which security features have been compiled
in, and I think that would be useful for developers to check their
Compiled in ...?
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100620014408.ga4...@ime.usp.br
Re: RFS: notorious-women
Hi, Benoît,
On Jun 18 2010, benoît tuduri wrote:
I launched to build my package the debuild command in a command line.
The only errors which are reported for my last upload are :
W: notorious-women: new-package-should-close-itp-bug
W: notorious-women: wrong-bug-number-in-closes l3:#
W: notorious-women: extra-license-file usr/share/doc/notorious-women/COPYING
Just for the record, when you upload some packages to the mentors site,
it tells you at least some of the most pressing things that you should
fix, if you visit the package page that is automatically created.
Those messages are generated with explanations and it is enlightening if
you can study their meaning and see how your package could be made more
robust/better.
In fact, it is a very good thing to always think: can I package this in
a better, easier way, that is more general, that will save me some work
in the future? Being your first critic is a good step to improve your
skills.
That being said, the automated checking programs can assist you in
learning about aspects where you can improve your package.
I didn't chose the artistic of dh-make options because it's not the
precisely the same that i put in copying file, i guess (i'm not a
legal term expert) :-)
I have not seen the contents of your package, but I suppose that it is
you that prepared the package. If that is correct, do you insist in it
having that exact license?
The non-commercial part of the license that you chosen makes it
non-free in Debian. If you remove that part, then it can, from a legal
standpoint, become part of the Debian distribution (just a reminder: the
non-free section of the archive is not considered part of Debian).
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100618022626.ga2...@ime.usp.br
Re: RFS: xpdf (updated package)
Dear Moritz,
Since I don't know if you follow -mentors, so I'm Cc'ing you. Feel free
to Cc me (even though I follow -mentors, I don't mind being Cc'ed).
On Jun 09 2010, Moritz Muehlenhoff wrote:
On 2010-06-04, Rogério Brito rbr...@ime.usp.br wrote:
Just for the record, it seems that things will break again with
poppler 0.13.x.
That should not be a concern for Squeeze, since it will stick with
0.13?
Did you mean 0.12? Anyway, I am starting to see what will change and
what will not.
At least, it does with my version of xpdf-poppler. Not sure with
yours. But, then, I intend to get your version and cherry pick some
of the patches that I have produced and put them together.
I have one patch, in particular, that would be good to send you.
Just to keep things sane here, I am trying to keep in touch with
Michael, but, after a while, he stopped replying. Michael, if you are
reading, please get in touch.
Here are some e-mails that you may have missed:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580495#5
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580495#10
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580621#5
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580621#23
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580621#31
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580621#39
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580621#55
To be honest, I don't like this my and yours here. Can we join
efforts here? I want to have everything integrated, alive and
healthy. I don't like fragmented efforts.
Indeed, it would be ideal if you could join efforts and introduce xpdf
with the poppler backend.
I agree with you, but it seems that some people would like to stick with
xpdf for the time being (e.g., Norbert Preining, Jakub Wilk), since it
seems that poppler might not have all the flexibility that the basic
xpdf has.
That is, perhaps, only up to the point where the poppler backend gains
more flexibility (shouldn't be too far). There are some documents that
work with poppler better than those with xpdf per se.
In that case we would be in the great position to only have to update
one single copy of the xpdf code base (poppler) whenever a security
issue is found it it. That's quite crucial to keep our ever-growing
archive maintenable.
Sure, that's a good side effect. And we pick up the correctness fixes
for poppler.
Unfortunately I don't have the time to sponsor/review the xpdf upload
myself, but I really hope someone chimes in, that would be a big
achievement for Squeeze.
That would be awesome to have. In the meantime, I will keep the
poppler-based xpdf in github updated.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100611092430.ga12...@ime.usp.br
Re: RFS: xpdf (updated package)
Hi, Norbert.
On Jun 04 2010, Norbert Preining wrote:
On Do, 03 Jun 2010, Rogério Brito wrote:
http://rb.doesntexist.org/blog/2010/05/27/please-let-me-zoom-my-documents/
I read that, and might I suggest ps_view? (also pdf viewer).
Sure, suggestions are always welcome.
Probably the best place to get it is from the TeX Live svn/rsync as we
did the necessary chagnes.
I am very confused with the svn repo of texlive. I did find an
apparently unpatched version of ps_view (is its name there psv?), but no
adaptations.
Well, I have it running here, too, but I am too lazy to make a package
for Debian for it.
It seems to depend on wxlua, right? Is this packaged in our archives? I
didn't find the necessary headers, but I am interested in trying it out,
sure.
Thanks,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100611092943.gc12...@ime.usp.br
Re: RFS: xpdf (updated package)
Hi again, Charles.
On Jun 04 2010, Charles Plessy wrote:
Le Thu, Jun 03, 2010 at 02:47:27PM -0300, Rogério Brito a écrit :
Just as a quick question, if you use xpdf with the poppler backend,
do you have poppler-data installed? It contains the character
mappings established by adobe for fonts...
Thanks, Rogério for the helpful answer.
You're welcome, as always. (And it is nice to receive some of your
e-mails once in a while).
I was very surprised that installation of poppler-data solved my
problem for evince but not for xpdf,
Great that this worked. I suspected that it would be the case.
but after reading Michael's answers, it looks that there is an
explanation. I recommand to solve this before uploading xpdf to main.
I am trying to work with Michael, but it seems that my mails to him are
not getting through. :-) (Michael, let us join forces in this, pal).
A very simplified version of the facts is this: CJK fonts need way more
than the 256 different characters. Therefore, for backwards
compatibility, we have to jump through many hoops to map to make things
work. Part of that job is to map CID fonts to Unicode characters, use
CMaps etc.
To cut a long story short, you can install the xpdf-japanese package,
or, since you already have poppler-data installed, you can simply add
these lines to your .xpdf and see if things work:
,[ .xpdfrc ]
| cidToUnicode Adobe-Japan1/usr/share/poppler/cidToUnicode/Adobe-Japan1
| toUnicodeDir /usr/share/poppler/cMap/Adobe-Japan1/
| toUnicodeDir /usr/share/poppler/cMap/Adobe-Japan2/
| cMapDir Adobe-Japan1/usr/share/poppler/cMap/Adobe-Japan1/
| cMapDir Adobe-Japan2/usr/share/poppler/cMap/Adobe-Japan2/
`
Please let me know if things work with that, as I am integrating support
to rich documents on the xpdf tree that I am starting to maintain. Some
extra lines may be needed, depending on how you have things installed.
By the way, I really think that poppler-data shoud be installed by
default on computers configured for office work. We can not expect
users to figure out that they need this package to see CJK characters.
Sure, I have been bitten by this problem many times in the past and I
did not know that there were some nasty patents in this.
I reported #584503 against poppler to propose to have libpoppler
recommend poppler-data.
Yes, even though poppler-data was non-free, it is now in main and I
don't know why it hasn't been added to recommends already.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100606032926.ga32...@ime.usp.br
Re: RFS: xpdf (updated package)
Hi, Jakub.
On Jun 04 2010, Jakub Wilk wrote:
* Rogério Brito rbr...@ime.usp.br, 2010-06-03, 16:00:
Thank you very much for your warm reception. :-)
Don't get me wrong: I believe that all PDF readers in Debian suck
and I appreciate that you want to change that state.
Ah, now your opinion is clearer.
However, I'd like you to bear in mind that some people are using xpdf
because of features that you are going to inadvertently kill
e.g. decent font handling or modest dependencies.
Just for the record, I am studying the way that the font handling may be
performed and don't substitute the Base14 fonts with anything else than
PostScript fonts.
Regarding the dependencies, I think that things tend to be smaller
rather than larger.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100606044922.gb32...@ime.usp.br
Re: RFS: xpdf (updated package)
On Jun 05 2010, Tanguy Ortolo wrote:
I never saw any file that made Evince crash, but I saw some files that
Xpdf renders perfectly and where Evince does not display at all some
fonts. For instance the LaTeX fontspec package's documentation, that
you can find at http://tanguy.ortolo.eu/tmp/fontspec.pdf.
I use fontspec every single day. For poppler-based viewers, install
poppler-data (see my other message to Charles Plessy).
I have often used Xpdf as a fallback when Evince was unable to correctly
display a file. Making them use the same renderer would just leave me
completely unable to read those files, so if it happens, I would try
very hard to keep an old version of Xpdf as long as I can. :-/
Well, I am in a similar situation: I use evince (actually, evince-gtk)
as a fallback for xpdf, but I am willing to have everything use fewer
dependencies, as long as the functionality is kept.
Heck, I even compile my own packages optimized for size (-Os) rather
than for speed (say, -O2 or -O3) with GCC. :-)
The only reason why I keep evince here is that I want to be able to read
djvu files also and I don't want to pull the entire qt4 libraries just
for a single program.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100606051014.ga2...@ime.usp.br
Re: RFS: xpdf (updated package)
On 06/04/2010 01:36 AM, Michael Gilbert wrote:
Thanks for spotting this! I've just uploaded xpdf with a versioned
depenedency on libpoppler-dev:
http://mentors.debian.net/debian/pool/main/x/xpdf
Just for the record, it seems that things will break again with poppler 0.13.x.
At least, it does with my version of xpdf-poppler. Not sure with yours. But,
then, I intend to get your version and cherry pick some of the patches that I
have produced and put them together.
I have one patch, in particular, that would be good to send you.
To be honest, I don't like this my and yours here. Can we join efforts here?
I want to have everything integrated, alive and healthy. I don't like fragmented
efforts.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c08c2e1.9070...@ime.usp.br
Re: editing former patches
On Jun 04 2010, Mihamina Rakotomandimby wrote:
This will skip all the patches. It helps me.
Now, how to split the diff.gz in order to select the only patches I
want?
Have a look at filterdiff, lsdiff and friends. And, for the love of
$DEITY, split the patches in sets that make things like this easier, if
they are not split yet.
And contribute back what you've done.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100604213630.ga16...@ime.usp.br
Re: RFS: xpdf (updated package)
Hi, there.
On Jun 03 2010, Stanislav Maslovski wrote:
This change is for sure quite significant. BTW, do you know if the
internal code in xpdf is equivalent feature wise to poppler? I know
that poppler was a spin-off of the rendering code of xpdf. Do you know
how much they deviate one from another?
I have been keeping in touch with Michael about such smaller version of
xpdf and, in fact, I started a xpdf-poppler project, that I announced at
http://rb.doesntexist.org/blog/2010/05/27/please-let-me-zoom-my-documents/
and that I am hosting at
http://github.com/rbrito/xpdf-poppler/
Unfortunately, Michael didn't inform me that some Gentoo people had been
already working on this, but that's not a problem and I will adopt the
changes that he has in his codebase.
Now addressing some of your concerns, I have already spent the last 3 or
4 days on the code of xpdf and the its rendering is by parts of a
page, in contrast with that of epdfview and evince, which render a whole
page in memory and, in particular, if you choose a large zoom factor,
they barf on that.
The reason of my question is that there are several pdf viewers in the
repository based on poppler. One of them is evince which often crashes
on large pdf files. In these cases xpdf was an
old-and-slow-but-always-working solution.
I have some questions here:
* What do you mean by old? Old looking, perhaps, but thats due to its
use of lesstif, right? Or did you mean anything else?
* What do you mean by slow? In most cases, I think that it is, at
least, of the same speed as others, even if using poppler.
I have not yet benchmarked the differences between pure xpdf and
xpdf+poppler, but I would say that they are very minor.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100603174338.ga2...@ime.usp.br
Re: RFS: xpdf (updated package)
Dear Charles,
On Jun 03 2010, Charles Plessy wrote:
I share the same worries: evince still does not manage to pick up japanese
fonts for some documents, while currently xpdf does. However, with the 3.02-3
update that you propose, it can not anymore…
Just as a quick question, if you use xpdf with the poppler backend, do
you have poppler-data installed? It contains the character mappings
established by adobe for fonts...
Actually, can you use any poppler-based (evince, epdfview, okular etc)
document viewer to view your Japanese documents with poppler-data
installed? If you can, what results do you get?
I can not share the test document because it is a cost estimate, but
if it helps I can communicate it to you privately.
If you could share any problematic document, that would be very nice.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100603174727.gb2...@ime.usp.br
Re: RFS: xpdf (updated package)
Hi, Jakub.
On Jun 03 2010, Jakub Wilk wrote:
* Rogério Brito rbr...@ime.usp.br, 2010-06-03, 14:43:
I have been keeping in touch with Michael about such smaller
version of xpdf and, in fact, I started a xpdf-poppler project,
Count me as one who won't use such a bastardized version of xpdf.
Thank you very much for your warm reception. :-)
,[ dict bastard ]
| 8 definitions found
| (...)
|
| From The Collaborative International Dictionary of English v.0.48 [gcide]:
|
| Bastard \Bastard\, a.
| 1. Begotten and born out of lawful matrimony; illegitimate.
| See {Bastard}, n., note.
| [1913 Webster]
|
| 2. Lacking in genuineness; spurious; false; adulterate; --
| applied to things which resemble those which are genuine,
| but are really not so.
| [1913 Webster]
|
| That bastard self-love which is so vicious in
| itself, and productive of so many vices. --Barrow.
| [1913 Webster]
| (...)
`
One can argue that both of these meanings *do* apply to xpdf. In fact,
xpdf is, right now, more or less abandoned by its upstream and while
very precious, it would need addressing many of its problems.
People would not have the need of a project in the veins of poppler
otherwise.
Font handling in poppler is brain-dead (see bug #528808) and xpdf
Just as a notice here:
* it works perfectly well here with my setup and xpdf-poppler;
* the document doesn't embed fonts, which is disapproved by (almost)
everyone---I do that myself, since it is allowed, but I do know that
many people may have problems otherwise;
* it may not be apparent, but I am a person that lives by TeX.
Besides that, it seems to work fine with poppler5 here and if you had no
response from the poppler maintainer in Debian, that's perhaps a problem
that should, indeed, be addressed.
serves me currently as a is-this-PDF-broken-or-is-it-only-poppler
tester.
You may be exaggerating here, since xpdf is not very strict in its
adherence to the PDF standard. I don't even know if Adobe's reader
follows the definition of the standard.
I would welcome, though, any patches, suggestions, or even brainstorms
etc to xpdf-poppler.
I know that you are qualifed enough to work with pdf and djvu files
based on your work with packages like pdf2djvu, ocrodjvu and similars
(and I have nothing but thank you once again for your work on that).
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100603190020.gc2...@ime.usp.br
Re: RFS: trimage
Hi, Kilian.
On Jun 01 2010, Kilian Valkhof wrote:
I have updated the short description to A GUI and command-line
interface to optimize image files via various command line tools and
pushed these to mentors.debian.net
Since the long description mentions how it performs things, you can keep
the short description shorter. BTW, the A article could be dropped.
Also, why is this package native? A native package is, by definition,
one that only matters to Debian and no distribution or operating system
else. You should fix this.
The long description should have its lines wrapped. The package browsers
are intelligent enough to know when lines should be wrappred and they
they shouldn't when they display the messages to the users.
Nitpick: some consistency in the spaces in the versioned
(build-)dependencies would be good.
I am not exactly sure if you need a build-dependency on python once
python-central is installed (I am not experienced with python), but I
would say that it isn't.
The changelog doesn't close an ITP bug in the first release. Is that
intentional?
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100601221526.ga29...@ime.usp.br
Re: RFS: gtk2-engines-cleanice: adopted, ITA #553506
Dear Stanislav:
On Mar 27 2010, Stanislav Maslovski wrote:
I have adopted gtk2-engines-cleanice (ITA bug #553506).
The package source format has been changed to 3.0 (quilt).
The orig.tar.gz has not been changed.
That is quite nice. I am not a DD and I just did a quick review here,
with the following results:
* the source is lintian clean, even with pedantic and experimental. Good.
* the md5sum of the provided tarball matches the one from upstream. Good.
* the license in the sources is GPL-2, not GPL-2+ as is stated in
debian/copyright.
* the license in the sources list the old address of the FSF.
* the indication of the full text of the GPL in debian/copyright is
unversioned. Since the unversioned path links to GPL-3, you have to
use the versioned file.
(Oh, I just noted that lintian, on the built package, informs this).
* the long description of the package lists the author: is this
necessary?
* the short description mentions CleanIce themes, in plural, but the
long description mention a clean ice theme right at the beginning.
Then, the long description says that the package provides 3 styles.
That should, perhaps, be modified?
* the debian/docs file installs the README file, but it is very short
and contains instructions to compile from source and how to use the
theme. I guess that you could remove that and include just the
information on how to use it in the README.Debian file.
* perhaps you would want to add the package lxappearance as a
Recommends: or Suggests: ?
* similarly to the README file, the AUTHORS file has its entire contents
in debian/copyright. Is this duplication necessary?
* some of the files in debian/rules have some trailing whitespace, but
this is just nitpicking...
I am asking for a review and an upload if everything looks ok.
I really hope that some sponsor upload this soon.
Hope this helps,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100328094118.ga9...@ime.usp.br
Re: RFS: gtk2-engines-cleanice: adopted, ITA #553506
Dear Stanislav,
On Mar 28 2010, Stanislav Maslovski wrote:
Thanks for your detailed review! My comments follow below:
Thank you very much for adopting this package and doing QA work. I did
not even know that it existed.
I just installed it and I have already switched from thinice to this one
(its binary is smaller and I don't need the other engines, since I am a
minimalist person).
On Sun, Mar 28, 2010 at 06:41:18AM -0300, Rogério Brito wrote:
* the source is lintian clean, even with pedantic and experimental. Good.
* the md5sum of the provided tarball matches the one from upstream. Good.
* the license in the sources is GPL-2, not GPL-2+ as is stated in
debian/copyright.
Good eyes! I did not notice it was incorrect and, respectively, did
not touch that part. I will correct this.
No problems. It is great that you are keeping the licensing straight.
* the license in the sources list the old address of the FSF.
Hm, what do you suggest? Provide a patch?
Thinking a little bit further about it, just leave it alone. It would
not be worth to have it corrected just for the few moments when the
package is being built.
OTOH, if upstream is still active, you should communicate it.
[Point to the correct GPL version]
Agreed.
OK.
[About the descriptions]
I will look at this.
Great.
* perhaps you would want to add the package lxappearance as a
Recommends: or Suggests: ?
Hm, I think it should be the other way around.
Yes, yes. You are right. I guess that a bugreport against lxappearance
would be in order so that it depends on some package that provides an
engine.
[AUTHORS file duplicated]
Yep, my feeling was the same, I just kept it because it was in the
original package. I will remove it.
As the new maintainer, you have the opportunity of taking all the best
current practices.
* some of the files in debian/rules have some trailing whitespace,
but this is just nitpicking...
I will look at this also.
That will save us some bytes. :-)
Many thanks for reviewing!
Thanks for caring about this nice and useful package.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100328153013.ga1...@ime.usp.br
Re: dpkg-buildpackage misunderstanding my instructions ...
Dear Joachim,
On Mar 28 2010, Wuttke, Joachim wrote:
$ cat rules
#!/usr/bin/make -f
# -*- makefile -*-
%:
dh $@
If these arcane lines must be modified, I would be most
grateful for help -
You are correct that these lines may be confusing, since there is a lot
of abstraction and implicit behaviour done by those simple and terse
lines.
Using debhelper's version 7 is a good thing for just getting the
packaging working when you know about some of the implementation details
(and, here, the implementation details matter).
I would suggest that you take a notice on Sune Vuorela's e-mail:
http://lists.debian.org/debian-mentors/2009/05/msg00614.html
You may want to use the debhelper-version-5-style debian/rules file, so
that you can see it better what is happening and which file goes where.
Hope this helps,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100328153843.gb1...@ime.usp.br
Re: [Pkg-fonts-devel] RFS: otf-ipaexfont (NEW)
Dear Hideki,
On Feb 27 2010, Hideki Yamane wrote:
It builds these binary packages:
otf-ipaexfont - Japanese OpenType font, IPAexFont (IPAexGothic/Mincho)
otf-ipaexfont-gothic - Japanese OpenType font, IPAexFont (IPAexGothic/Mincho)
otf-ipaexfont-mincho - Japanese OpenType font, IPAexFont (IPAexGothic/Mincho)
The package appears to be lintian clean.
It only has some minor things found with lintian:
,
| I: otf-ipaexfont source: duplicate-short-description otf-ipaexfont-mincho
otf-ipaexfont-gothic otf-ipaexfont
| P: otf-ipaexfont-gothic: no-upstream-changelog
| P: otf-ipaexfont-mincho: no-upstream-changelog
| P: otf-ipaexfont: no-upstream-changelog
| I: otf-ipaexfont: capitalization-error-in-description meta package metapackage
`
I guess that the first and last ones could be improved, right?
Also, being pedantic here, there's a trailing whitespace in the
changelog, that could be removed. :-)
Another one: the package has the otf- prefix, but the fonts provided
have the .ttf suffix. They are, according to the file command, TrueType
font data, despite having OpenType features like Standard Ligatures,
Expert Forms, Fractions, Slashed Zero etc.
I guess that the font files could be renamed to .otf, then?
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227154830.gc2...@ime.usp.br
Re: how to compare versions
On Feb 05 2010, Hideki Yamane wrote:
BTW, I would rename tomoyo-ccstools to tomoyo-ccstools1.7 and not
provide upgrade path for that. If I just would upgrade this pacakge,
it'll break system that it works with security policies for 1.6.x, so
I should leave it and provide README.Debian for upgrade to 1.7.
That seems to be the most sensible solution, since it can allow the
co-installation of both solutions. Is it meaninful to have both of them
installed side-by-side, with the user being able to choose whether one
or the other should be used?
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: xfe (updated package)
Hi, Joachim.
On Jan 29 2010, Joachim Wiedorn wrote:
The upload would fix this FTBFS bug: 560549
Now xfe can be compiled on GNU/kFreeBSD architectures.
Thanks for taking care of kfreebsd.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: patch error in some arch
Hi, Hideki.
On Jan 13 2010, Hideki Yamane wrote:
I want your help with build error in some arch.
As below I got reject with patching, but I built it completely
in my environment (i386).
(...)
patching file src/browsers.cpp
Hunk #1 FAILED at 4.
Hunk #2 FAILED at 20.
2 out of 2 hunks FAILED -- rejects in file src/browsers.cpp
Patch browsers.cpp can be reverse-applied
(...)
Some arch, ia64 and powerpc cannot build this package.
https://buildd.debian.org/pkg.cgi?pkg=jd
I suppose here that your patch applies in i386, since you would possibly
not have buit your package (of course, you should double-check it, since
the patch may not have been applied in the build that you generated).
Anyway, are you sure that you can apply the patch without errors? Are
you sure that the patch that is included in the source package is clean?
If you are using the 3.0 quilt format, then you would have to watch out
for you applying the patch (implicitly, via dpkg) and an
automatically-generated patch named debian/patches/debian-*.
How do I deal with this error?
I hope that the points listed above are useful in tracking the problem.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: easymp3gain
Hi, Mattias.
On Jan 11 2010, Matthias Klumpp wrote:
easyMp3Gain is a GUI application, it does not have any command line
arguments.
Then, please just state it for people using the manpages. The first
thing that I do when I get a new package is to look at the manpage of
the main executable.
(Which I, BTW, assume is called the same as the package name, with all
lowercase characters, in the best Unix tradition).
Is it really necessary to write a manpage, and if it is, who should
write it? Upstream or me?
You can write one. It is easy (should not take more than 5 minutes in
the case of a program that does not take any command line options).
I hope to fix my songs with this utility, BTW.
Thanks,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: QA Upload: fondu -- Mac to Unix font converter
Hi, Christoph.
On Dec 11 2009, Christoph Egger wrote:
The changes are actually minimal for a new upstream release (I
was not reacting as I was expecting way more).
Fair enough.
Did you consider adopting the package if it does matter much for
you? While being updated through QA is good having a real Maintainer
is of course the idea state for a package
Yes, I did consider that, but I'm overwhelmed with some other QA work
that I'm doing. Just for the record, I'm currently evaluating if it is
feasible to maintain xpdf or not.
Also, I am happy to say that at least two of the packages that I got to
do QA updates were, *very* shortly afterwards, adopted by other people.
The packages that I have in mind are gphotofs and id3lib3.8.3, which
were gathering dust.
I am including the -qa list here so that the are away of my efforts and
interests (which I already briefly told to Barry deFreese privately).
dget
http://mentors.debian.net/debian/pool/main/f/fondu/fondu_0.0.20051010-1.dsc
Uploaded.
Thank you again.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: licenses
On Dec 11 2009, Gabriele Giacone wrote:
[1] shows a license. Is it good for Debian? Should I only declare in
d/copyright that software is derived from the RSA Data Security, Inc.
MD5 Message-Digest Algorithm?
I think that there are other packages in the archive that include this
file. That being said, why not use one of the libraries that already
provide md5 implementations?
[2] doesn't show a license. In this case, should we consider upstream
license?
The samething here. I, for instance, use libssl-dev for a package of
mine (hfsprogs) that needs sha1 implementations.
You may also consider using the gnutls implmentation of those. A small
patch to adapt those might be very fruitful.
Also, when the libraries providing the functions get improvements (like,
for instance, specialized versions optimized for some newer CPU arch),
you get those for for your programs. And maintenance becomes easier.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: QA Upload: fondu -- Mac to Unix font converter
Dear mentors,
On Dec 08 2009, Rogério Brito wrote:
Thank you very much for your support in making Debian better from a QA
point of view. :-)
After updating the packaging of fondu (which is orphaned) with some
fixes and improvements for a QA upload, I just packaged a new upstream
version (also as a QA update to fix a bug in one of the programs).
Fondu is a Mac to Unix font converter that is especially useful to folks
that inclined to typographical matters (I am).
The source package is at mentors:
dget http://mentors.debian.net/debian/pool/main/f/fondu/fondu_0.0.20051010-1.dsc
The changes are as follows:
,[ fondu_0.0.20051010-1_amd64.changes ]
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Format: 1.8
| Date: Thu, 10 Dec 2009 08:48:25 -0200
| Source: fondu
| Binary: fondu
| Architecture: source amd64
| Version: 0.0.20051010-1
| Distribution: unstable
| Urgency: low
| Maintainer: Debian QA Group packa...@qa.debian.org
| Changed-By: Rogério Brito rbr...@ime.usp.br
| Description:
| fondu - convert between Mac and UNIX font formats
| Changes:
| fondu (0.0.20051010-1) unstable; urgency=low
| .
|* QA upload.
|* New upstream release. According to the upstream homepage:
| + Someone pointed out a couple of errors in the res2data program
|(which copies the resource fork of a mac file into a data fork).
| + Ages ago someone sent me another patch which I only just noticed.
|And applied.
| Checksums-Sha1:
| e9f0dd0fba61c7c9c3879e2cc034f43a082533db 1081 fondu_0.0.20051010-1.dsc
| 9ca6770a2cf2f71b188e5b99b5307d6981a32b70 130081
fondu_0.0.20051010.orig.tar.gz
| dd9ce0172f05048effa837caca897842597a6d66 4875
fondu_0.0.20051010-1.debian.tar.gz
| 455efaa68e6bfead9d05a08a6664050b72414246 86860 fondu_0.0.20051010-1_amd64.deb
| Checksums-Sha256:
| 7a4635cefd3c0b2cb29c98ccdd5e51a711dfa9e736fecc0be15e4eeeca0630f1 1081
fondu_0.0.20051010-1.dsc
| 96c3e06d2950af6cbc7a833f12fabccf150e1cb8f54058267b0a99c2dcfaa823 130081
fondu_0.0.20051010.orig.tar.gz
| 3a9854ff897acd6993695820fed96be0894bae7eed88ee060045c14ebaffddcd 4875
fondu_0.0.20051010-1.debian.tar.gz
| f294470cf41fdaa4528fd22ac896d52e9d1d2bf001556cb5094fc6dbc642779a 86860
fondu_0.0.20051010-1_amd64.deb
| Files:
| c88b6fb9d6b346135edce5ea693f5e39 1081 utils extra fondu_0.0.20051010-1.dsc
| 743f27c71a2fe187cd4b8d55c27ec340 130081 utils extra
fondu_0.0.20051010.orig.tar.gz
| 184c185b20e6748c4383b9dc34d11511 4875 utils extra
fondu_0.0.20051010-1.debian.tar.gz
| 3b7e9f5886a69ab0386a6e72199a49d1 86860 utils extra
fondu_0.0.20051010-1_amd64.deb
|
| -BEGIN PGP SIGNATURE-
| Version: GnuPG v1.4.10 (GNU/Linux)
|
| iEYEARECAAYFAksg3q8ACgkQCFqbMnwsrriUPwCfXkw9JRjTq2t0hz6jiQziNY+0
| ZRcAoK6X61yLG8tCQJAMVVeV4JNgfjx8
| =Wap/
| -END PGP SIGNATURE-
`
Thanks again, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: QA Upload: fondu -- Mac to Unix font converter
Hi, Christoph.
On Dec 08 2009, Christoph Egger wrote:
Rogério Brito schrieb:
I would be glad if it were uploaded.
Looks good, uploaded.
Thank you very much for your support in making Debian better from a QA
point of view. :-)
Thanks again, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On conditionally copying config.{guess,sub} (was: Re: RFS: gmfsk (NMU, fixes ftbfs))
On Dec 08 2009, Cyril Brulebois wrote:
As for config.{guess,sub}, no need to conditionalize the
'cp'.
Amen, bro.
autotools-dev is in Build-Depends and if it'd stop shipping
those files, or in different locations,
Or if the copy fails for some reason...
you want to know about this through an FTBFS report rather than
silently using ancient config.* files.
Exactly my rationale for removing this from my recent packages. I *do*
want to see the errors and break things as soon as possible, instead of
building something that could have strange behaviours.
And it also makes the scripts more readable.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
QA Upload: fondu -- Mac to Unix font converter
Hi.
I have just updated the packaging of fondu (which is orphaned) with some
fixes and improvements for a QA upload. I did this after reading things
from the QA page (and http://wnpp.debian.net/?sort=installs;desc in particular).
Fondu is a Mac to Unix font converter that is especially useful to folks
that inclined to typographical matters (I am).
The source package is at mentors:
dget http://mentors.debian.net/debian/pool/main/f/fondu/fondu_0.0.20050825-2.dsc
The changes are as follows:
,[ fondu_0.0.20050825-2_amd64.changes ]
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Format: 1.8
| Date: Mon, 07 Dec 2009 17:53:20 -0200
| Source: fondu
| Binary: fondu
| Architecture: source amd64
| Version: 0.0.20050825-2
| Distribution: unstable
| Urgency: low
| Maintainer: Debian QA Group packa...@qa.debian.org
| Changed-By: Rogério Brito rbr...@ime.usp.br
| Description:
| fondu - convert between Mac and UNIX font formats
| Changes:
| fondu (0.0.20050825-2) unstable; urgency=low
| .
|* QA upload.
|* convert to format 3.0 (quilt).
|* create separate patches for each task.
|* set maintainer to the QA group.
|* add LDFLAGS to minimize dependencies.
|* remove trailing whitespace from this log.
|* make sure that it builds correctly:
| + twice in a row.
| + with binutils-gold.
|* create watchfile with sourceforge redirector.
|* fix disparity between override file and control file.
|* add homepage field to keep track of upstream.
|* update standards version to 3.8.3, with no extra changes needed.
| Checksums-Sha1:
| 39bbd46fb3cb98feaf297bbed73e65b12e1b90dc 1081 fondu_0.0.20050825-2.dsc
| 18d681d2413d351ffc84fc0e0a8a66ed208c5ff0 125928
fondu_0.0.20050825.orig.tar.gz
| 8c20192a5377949b118f73c9361bfa407491d9f6 4776
fondu_0.0.20050825-2.debian.tar.gz
| 6c35de393ec2eec4d01886ccf3d5d8a2c499aa8f 87812 fondu_0.0.20050825-2_amd64.deb
| Checksums-Sha256:
| f616ddd79efa4ef458c6d3c2dca48935c42e8218a42a361b481e19af785456be 1081
fondu_0.0.20050825-2.dsc
| 06f382afd02b30c573cc61c112de3ea4c3c24d3edcb38421f7ace76c7235012c 125928
fondu_0.0.20050825.orig.tar.gz
| 6df328764b3462edc4059176134c6f6d680a38c5b5fe99b5d4800efcdaac2954 4776
fondu_0.0.20050825-2.debian.tar.gz
| 4b853adca9a2db3abef63a4ea1797f37408574570792895706e423a439f4da0e 87812
fondu_0.0.20050825-2_amd64.deb
| Files:
| 2b45581c824811da89a7065ff5f88681 1081 utils extra fondu_0.0.20050825-2.dsc
| 5268796674d15aa40323a495316653f1 125928 utils extra
fondu_0.0.20050825.orig.tar.gz
| fe2aba6054bf875c6e0a2b0cb5b78900 4776 utils extra
fondu_0.0.20050825-2.debian.tar.gz
| 1d92a70fb793b5b97890cefde4861129 87812 utils extra
fondu_0.0.20050825-2_amd64.deb
|
| -BEGIN PGP SIGNATURE-
| Version: GnuPG v1.4.10 (GNU/Linux)
|
| iEYEARECAAYFAksdYMYACgkQCFqbMnwsrriP9ACg5ptBFtbfzx+xFdhPNCcNvXWE
| 5QEAnRYAUwrWP4UCKVb7q6OQuAIwB0uj
| =CiT7
| -END PGP SIGNATURE-
`
There are some lintian warnings, but they are minor. There's also a new
upstream version, but we can get to that latter (revealed by the new
brand new watch file that I created).
I would be glad if it were uploaded.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557892: RFH: hfsprogs -- mkfs and fsck for HFS and HFS+ file systems
Package: wnpp
Severity: normal
I would kindly request assistance with maintaining the hfsprogs package,
which is a pair of programs for mkfs and fsck for HFS/HFS+ filesystems.
The package is developed by Apple, but only a small fraction of the
package is actually used. The current packages in Debian use source code
from Apple's MacOS X 10.4 version (codenamed Tiger).
The original patches adapting things to Linux that I got were monolithic
and I cleaned them up, broken them up (for ease of future work) and
were ported forward against some 5 or 6 (I forgot how many) upstream
releases, but still in the 10.4.x branch of their filesystem.
Now, things are getting cleaner and I have started porting the patches
against the first MacOS X 10.5 version, and most of the patches are
already appliable against that version (with the exception of one
patch).
The package has no bugs in its current version, has no lintian
warnings/errors (when using a new lintian version) and is packaged with
format 3.0 (quilt).
In other words, it is in a mostly sane situation, but as is a tautology,
things can be improved.
There are some things to do and I would kindly appreciate some help with
the forward porting the patches.
The package long description:
,
| The HFS+ file system used by Apple Computer for their Mac OS is
| supported by the Linux kernel. Apple provides mkfs and fsck for
| HFS+ with the Unix core of their operating system, Darwin.
| .
| This package is a port of Apple's tools for HFS+ filesystems.
| .
| For users, HFS+ seems to be a good compromise to carry files between
| MacOS X and Linux Machines, as HFS+ doesn't suffer the problems of
| FAT32 like:
| .
| * huge space waste (in slack space as devices grow faster);
| * ability to create files that are more than 4GB in size (especially
| good for those working with multimedia and that need to carry large
| ISO files);
| * ability to use case preserving (and even sensitivity!);
| * ability to use uid's and gid's on the filesystem.
| .
| Users in general can enjoy such benefits since it is expected to have
| more HFS+ filesystems in use, as Apple has announced Macintoshes for
| ix86-64, besides the filesystem being already supported by PowerPC
| systems since the beginning.
`
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: youtube-dl (updated package, support for 1080p videos)
On Nov 19 2009, Simon Richter wrote:
E: youtube-dl: empty-manual-page usr/share/man/man1/youtube-dl.1.gz
W: youtube-dl: manpage-has-bad-whatis-entry usr/share/man/man1/youtube-dl.1.gz
Gee. I just noticed that. :-( It was supposed to be removed to avoid
bloating the diff.
I think that it is fine now. Uploaded again to mentors. :-(
dget
http://mentors.debian.net/debian/pool/main/y/youtube-dl/youtube-dl_2009.09.13-2.dsc
Thanks for looking at that, Simon.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: youtube-dl (updated package, support for 1080p videos)
Hi, Simon.
On Nov 19 2009, Simon Richter wrote:
On Thu, Nov 19, 2009 at 11:39:46AM -0200, Rogério Brito wrote:
dget
http://mentors.debian.net/debian/pool/main/y/youtube-dl/youtube-dl_2009.09.13-2.dsc
| * include the DMUA: yes field.
Sneaky. :)
Oh, that was something that I talked about with some other developers.
It really seem that the opinions on this are divided... :-/
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Writing manpages (was: Re: Man and UTF-8.)
Hi, Joachim.
On Nov 18 2009, Joachim Wiedorn wrote:
Am Wed, 18 Nov 2009 05:30:33 -0200 schrieb Rogério Brito rbr...@ime.usp.br:
But what do you people use to edit manpages that you maintain
frequently?
I find the simplest way is to use *ManEdit*.
Is this the same as gmanedit (that's the only one that seems to be
available in the archives)? I remember having used it some ages ago and
I wasn't impressed, but that was a long time ago.
At the beginning you can get templates for the structure of the man
page. There are support for header and sections. There are some
shortcuts for formatting. But you also must know syntax elements of
manpages: TP LP and so on.
This is what I'm trying to avoid. When I edit the bare *roff sources, I
usually end up having line breaks where I don't want and not having
where I want and it takes me some round trips to get it as I wanted.
I guess that I only have two options left, as it seems: Perl's pod
format or docbook. The only problem with docbook is that I don't know
how to avoid the torrent of markups and typing some of them is long.
Now, if there were some LaTeX - man, that would be amazing.
Anyway, I will give gmanedit a try right now. Let's see if my
impressions still hold.
Other opinions and suggestions are very welcome.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: xfe (updated package - new upstream release)
Hi, Joachim.
On Nov 16 2009, Joachim Wiedorn wrote:
Ok, I have to include intltool in the build dependencies. Please can
you say me the other minor things, so I can check them, too.
Well, this is just a quick look at the package:
* the debian/README file talks about installation of some
programs; this is useless if you are installing a precompiled package,
because you, the maintainer, will have taken care of the dependencies.
* why not wrap the (build-)dependencies to leave one for each line,
easing the manipulation and readability?
* you mention on debian/copyright that you packaged the program, but the
changelog says that some other people worked on that. Can you clarify?
* you can remove comments from the watch file.
* why do you prefix some commands in debian/rules with a minus sign? Do
you want to ignore their error conditions? What about using something
like:
foo || /bin/true
? Why ignore the errors in the first place?
* some comments on debian/rules could be removed, couldn't they?
* in patch 01_no-mount-warning.patch, only linux is checked. What about
the kFreeBSD's? Any bug with them is now considered release critical.
Please, see if my comments apply or if they can be ignored.
* why do you have two patches to xferc? The patches have no comments on
them (See DEP-3).
* patch 05_names-in-xfedefs.patch replaces xmms with audacious. I think
that that should be audacious2.
* why does it get compiled with -O3? Why not -O2? Why not -Os
(especially useful for machines without a lot of cache).
* can't you compile the C++ code with -Wextra and -Weffc++? This way,
more warnings could be emitted and some potential bug that is lurking
there would just be discovered soon.
Anyway, thank you very much for xfe. I'm itching to have a newer version
available in Debian, especially now that you split the not needed parts
from the main program.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Writing manpages
Hi, Russ.
On Nov 18 2009, Russ Allbery wrote:
Yup. :) And there's a nice Emacs mode for POD that does coloration
and whatnot. (There is for *roff as well, but I hate typing *roff
directly.)
Well, it seems that we have two strong contenders: POD and reST. Things
look brighter for a more documented Debian. :-)
And regarding the Emacs mode for POD, that's simply great! My POD files
were interpreted before as comments in Perl documents, but with this
mode, things are much more comfortable! :-)
Thanks for the hint!
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: xfe (updated package - new upstream release)
Hi, Joachim.
On Nov 18 2009, Joachim Wiedorn wrote:
Am Wed, 18 Nov 2009 12:56:08 -0200 schrieb
Rogério Brito rbr...@ime.usp.br:
oh oh, so a long list!
Well, I thought that you wanted some comments. :-)
I still have not understand the difference between README and
README.Debian. Perhaps that's the problem. So I will delete the part
about installation thinks.
README should contain generic comments about the package itself.
README.Debian should contain comments about the package in Debian, like
some divergence in behaviour against upstream that users should violate
the principle of least surprise.
Other things that are pertinent in README.Debian: design decisions that
are taken in Debian, like reserving a given runlevel or allocating a
namespace of something for use in the distribution (say, all config
files with prefix 00 to 40 are meant to be used for tweaking something
in the kernel etc).
With the background that the old package with version 1.04 was very
old and for the new standard 3.8.3 plus cdbs and other thinks I have
to create the hole debian directory new (with dh_make). Or should I
ever let the first line in debian/copyright as it was in the old
package?
You should still give a hint (a short phrase is enough) that other
people worked on the package and give them credit.
Talking about cdbs, it may obfuscate some details that you need to know
once you have to hunt some bug on your package and, while it
encapsulates many things, it may change its behaviour in subtle ways.
It is, after all, a second layer of indirection regarding the original
configuration, compilation, and installation (the first being debhelper,
used by cdbs).
* you can remove comments from the watch file.
Some lines came from the template.
Just kill them. The templates serve as examples for people to know what
values to put in the appropriate fields.
This '-' should only help, if the compilation/packaging was interrupted
and in the next run at this points it would stop because the final
situation was not reached.
An error generated during the package building at a given stage should
not generate the target of the makefile.
It is, in some cases, better to abort things if you encounter an error,
but you, the package maintainer, should decide what is better.
(I, myself, usually turn on every sensible warning, break at many
potential errors and warnings etc, just to be on the safe side).
On the other hand I see the error message and can decide, whether it
is a real error.
Nice.
How should I understand this? In Xfe the mount warning is useful for
NFS and other shared media, if they are no more exist. That could be
activated from the user by local configuration.
Well, I will have to check it to see what happens.
* why do you have two patches to xferc? The patches have no comments on
them (See DEP-3).
I should use better names for patches.
Right. If you find some time, just put a description there so that
people that will possibly make a non-maintainer upload understand why
the patch is there.
* why does it get compiled with -O3? Why not -O2? Why not -Os
(especially useful for machines without a lot of cache).
I think this should be checked together with upstream - that's right?
No, this one should be fixed. Getting rid of the unconditional -O3, the
-ffast-math, -fomit-frame-pointer and so on should be done as a way to
control how the builds happen.
1 - Somebody may want to use the (Debian-policy described) variable
DEB_BUILD_OPTIONS=noopt to disable optimization (to hunt some potential
bug), but, as you package is right now, it always compiles with
optimizations turned on.
2 - The optimization level -O3 may be broken on some architectures (and
it was, if memory serves).
3 - Some other options are broken in other architectures (like, say, the
math-handling functions in ARM).
These options get set in configure and configure.in. You can change
those and convince upstream to flexibilize things a little bit.
All this is preventing you some quite possible headaches once your
package gets to the users systems.
* can't you compile the C++ code with -Wextra and -Weffc++? This way,
more warnings could be emitted and some potential bug that is lurking
there would just be discovered soon.
I can do it for testing. But I think this is the job for the upstream
developer, isn't it?
Yes, it is. But it already reveals some code improvements.
Oh, as a last point, just give a look at the output of lintian. It's
telling some things that are ultra-easy to fix.
That's it. I hope that your package gets into Debian ASAP. I'm using a
copy of it already.
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
RFS: youtube-dl (updated package, support for 1080p videos)
Hi, people.
I just received a bug report telling me that youtube has made 1080p (aka
Full HD resolution) videos available.
I have just updated youtube-dl to grab those movies if you select to
download the best quality video available.
The package is at:
dget
http://mentors.debian.net/debian/pool/main/y/youtube-dl/youtube-dl_2009.09.13-2.dsc
I would appreciate if anybody could upload this downloader of youtube
videos.
Here is the .changes file content:
,
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Format: 1.8
| Date: Thu, 19 Nov 2009 05:16:24 -0200
| Source: youtube-dl
| Binary: youtube-dl
| Architecture: source all
| Version: 2009.09.13-2
| Distribution: unstable
| Urgency: low
| Maintainer: Rogério Brito rbr...@ime.usp.br
| Changed-By: Rogério Brito rbr...@ime.usp.br
| Description:
| youtube-dl - download videos from youtube.com
| Closes: 553919 557042
| Changes:
| youtube-dl (2009.09.13-2) unstable; urgency=low
| .
|* add support for 1080p videos. Thanks Josh Triplett. Closes: #557042.
|* change to 3.0 (quilt) format.
|* include a better manpage. Closes: #553919.
| Checksums-Sha1:
| b748443e3f8117e6d4ee7471a0054173ffe8cb6e 1072 youtube-dl_2009.09.13-2.dsc
| 63a07cc31f18d028e676fdf0aa4f9a01c49e01f9 12737
youtube-dl_2009.09.13.orig.tar.gz
| 5f999a8276027f169c144b7356150eba5305934f 3207
youtube-dl_2009.09.13-2.debian.tar.gz
| 566874ee32c12c07b5a399e33b687f274f7b53cc 15224
youtube-dl_2009.09.13-2_all.deb
| Checksums-Sha256:
| 2a58eec4614b49655519c31c4a0c69af3db655b98c94388224f1c0fa31a646d2 1072
youtube-dl_2009.09.13-2.dsc
| 22da55121cebbce8916070d645b1f0a59209c9329ee31cdf3eedf34c4f274e21 12737
youtube-dl_2009.09.13.orig.tar.gz
| 951893e48346611187b05e24d38c4026a984140180f178eb6f68eb008185a060 3207
youtube-dl_2009.09.13-2.debian.tar.gz
| a1a6e4257a79932be21c7357e0df5ce0f3e72c249aafb74adb4d1ca4b6ab5a83 15224
youtube-dl_2009.09.13-2_all.deb
| Files:
| 8d84ec3e8ebb712236042dac59fea4e3 1072 web extra youtube-dl_2009.09.13-2.dsc
| 9b8b2ad4c8e60c70ea5d5e9dc530fcdb 12737 web extra
youtube-dl_2009.09.13.orig.tar.gz
| ce9bcae14811869e56c47a985cbf4588 3207 web extra
youtube-dl_2009.09.13-2.debian.tar.gz
| c90a1c74fc37758d4277574703752522 15224 web extra
youtube-dl_2009.09.13-2_all.deb
|
| -BEGIN PGP SIGNATURE-
| Version: GnuPG v1.4.10 (GNU/Linux)
|
| iEYEARECAAYFAksE9BgACgkQCFqbMnwsrrh0bACeLplCPW4u87dFvw0lkrDHUj5Y
| UosAmwWorg/2WKG+jP+MqkyEY6ComAVc
| =+53M
| -END PGP SIGNATURE-
`
I would be glad if anybody uploaded this version, so that we can see the
new trailer for Toy Story in enough resolution (so that we can see any
potential new character to give name to future Debian releases!). :-)
http://www.youtube.com/watch?v=5f-MYl-HzNw
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man and UTF-8.
On Nov 17 2009, Russ Allbery wrote:
It is in the *roff language, similar to how '' is an opening or closing
quotation mark in TeX.
Just as an addendum, in TeX, `` is the opening (double) quotation mark
and '' is the closing quotation mark. Similarly, ` is the opening
single quotation mark and ' is the closing single quotation mark.
*roff is a formatting language, not ASCII text with a few special
commands, and it's important to be aware of that while writing in it.
Same with TeX.
*roff is 33 years old. It doesn't work the way that it would if it were
designed today.
Same with TeX.
With TeX, BTW, we have some extensions (or even reimplementations) that
allow us to type things in UTF-8 directly, instead of using escape
sequences like in older TeX (e.g., Rogério instead of Rog\'erio, in
utf-8 or in latin1, though some care should be taken to avoid clashes
between different encodings used in the same file).
Regards from a daily LaTeX user,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Writing manpages (was: Re: Man and UTF-8.)
On Nov 17 2009, Roger Leigh wrote:
However, TTBOMK UTF-8 manpages should be OK as well, though I have
found some issues with more esoteric characters. I would suggest
reporting bugs or contacting the maintainer or groff upstream if
you run into problems here.
OK, since the project strongly advises for the availability of manpages
(and I love manpages), comes the question: what do you people use to
type manpages?
Using troff is simply nasty and hard, with all the typesetting getting
in the way of seeing the content that one has typing (that's not to even
mention the need to memorize the black magic-esque mnemonics).
I'm seriously considering using a dedicated editor for this purpose, but
all of the ones that I've looked at either show the high noise/signal
rate or are too verbose (like docbook manpage).
The best so far that I found seems to be Perl's pod format. At least,
the markup doesn't pollute my view.
But what do you people use to edit manpages that you maintain
frequently?
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man and UTF-8.
Hi, Charles.
On Nov 17 2009, Charles Plessy wrote:
Is there a way to put an indication in the manpage source code for the
nroff parser, that the UTF-8 encoding is used?
I don't know the answer to that. OTOH, if you only need to use accented
latin characters, you can use something like this:
Rog\('erio Brito
This is described in man 7 groff_char. Perhaps other characters are too.
Regards, Rog\('erio. :-)
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: xfe (updated package - new upstream release)
Hi, Joachim.
On Nov 15 2009, Joo Martin wrote:
Now I have looked over all bug reports and I have seen the most of them
are fixed. I have added Closes to the comments in my changelog file.
Thanks for taking care of xfe. I especially like the fact that it is
split to make it leaner.
The updated version is now on mentors.debian.net.
The package seems to be missing a build-dep on intltool. There are some
other minor things, but I can comment on them latter, with other
releases (if I don't forget).
Hope this helps,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: insserv: warning: current stop runlevel(s) ... overwrites defaults
On Nov 11 2009, Michael Hanke wrote:
# Default-Start: S 2 3 4 5
Remove the S state.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian pickiness and packaging improvements
Hi, Russ.
On Oct 29 2009, Russ Allbery wrote:
That was actually most of the point of pedantic. Minor possible bugs
that aren't stylistic belong in info instead. That's why both of them
are suppressed by default.
OK. Nice. Please keep them there. We can just treat them as pedantic and
not recommend them by default.
(I actually like them there).
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian pickiness and packaging improvements
On Oct 22 2009, Raphael Geissert wrote:
Manoj Srivastava wrote:
I also think that style issues should not be a part of even
Pedantic checks. If a package is using a different, and arguably
better style, then lintian should keep its nose out.
If there's a better style I guess nobody would object to consider recommend
it or at least make sure lintian doesn't complain about it.
Couldn't we have a category of warning/checks that is labelled stylistic?
That way, all odd-ball stylistic changes could be separated from
pedantic and enabled with an even wider range of things (like the
trailing-whitespace-at-eol issue, files that don't end with newline
etc).
I hope that you get the idea.
Regards, Rogério.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian pickiness and packaging improvements
On Oct 22 2009, Manoj Srivastava wrote:
On Thu, Oct 22 2009, Rogério Brito wrote:
Couldn't we have a category of warning/checks that is labelled
stylistic?
Whose style would you choose?
Mine, of course. :-)
I am all for idea if it is _my_ style which is selected, and every
one else's style will be warned against.
I'm not all for the idea of having just one style. I knew that this
objection would appear, but I worded it poorly.
What I had in mind would be a grab-bag of such stylistic things. But
scrap that.
I hope you do too.
Sure.
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Updated package: libvformat (QA upload) (install-info transition)
Hi,
The libvformat package is currently orphaned since I previously asked
the maintainer if he would be ok with a NMU or QA upload. He said yes
and orphaned the package.
So, to fix two easy to fix bugs and help with the info transition, I am
contributing this as a QA upload.
There are many things to fix with this package, but it is in a much
better shape than before (the diff.gz is less bloated, it doesn't drag
unnecessary dependencies, it has a cleaner support for some other things
etc).
I see that the package has an already ITA bug filed---the next
maintainer can get my changes and play with them as he pleases, but
since he doesn't seem to be a DD, his package would have to go to the
sponsor way as well as mine.
Closes bugs: 363569, 528907.
Related bugs: 535686, 535687, 545990.
Source:
http://mentors.debian.net/debian/pool/main/l/libvformat/libvformat_1.13-5.dsc
Changelog:
,
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Format: 1.8
| Date: Mon, 19 Oct 2009 17:17:37 -0200
| Source: libvformat
| Binary: libvformat1-dev libvformat1
| Architecture: source amd64
| Version: 1.13-5
| Distribution: unstable
| Urgency: low
| Maintainer: Debian QA Group packa...@qa.debian.org
| Changed-By: Rogério Brito rbr...@ime.usp.br
| Description:
| libvformat1 - library to read and write vcard files
| libvformat1-dev - library to read and write vcard files (development files)
| Closes: 363569 528907
| Changes:
| libvformat (1.13-5) unstable; urgency=low
| .
|* QA upload.
|* debian/copyright:
| + include copyright assignment.
| + point to a versioned license.
|* debian/control:
| + remove debhelper dependency from the runtime binary package.
|(Closes: #363569, LP: #441893)
| + build-depend on autotools-dev.
| + add ${misc:Depends} to all binary packages.
| + set maintainer to Debian QA Group.
| + make dependency to triggers smoother with install-info.
| + improve short descriptions a little.
| + add Homepage field, so that we don't loose track of upstream.
| + tighten the dependency between -dev and lib package.
| + update Standards-Version to 3.8.3.
|* delete trailing whitespace from this log.
|* debian/rules:
| + remove DH_COMPAT.
| + don't ignore make clean error.
| + remove some commented lines.
| + touch build-stamp, as it is not declared as a PHONY target.
| + link config.{sub,guess} in the configuration step.
| + don't incorrectly copy config.{sub,guess} from autotools-dev.
| + improve support for cross-compilation.
|* debian/compat:
| + add, with 5.
|* debian/watch:
| + include, with redirector to sourceforge.
|* doc/libvformat.texi: added info dirsection (Closes: #528907).
| Checksums-Sha1:
| 045f90442d44e595ae359e074a12743706240cfc 1065 libvformat_1.13-5.dsc
| 8df0a9df4ec351ad7a44bd1a73fa6616dff813f7 254463 libvformat_1.13.orig.tar.gz
| 86c20c44fa0901cca8a7566ccd8e50fa1a5c2988 349647 libvformat_1.13-5.diff.gz
| 04ba19be23bc0cdb7cf39d4073a09314dfe6ae45 57466
libvformat1-dev_1.13-5_amd64.deb
| cc13906f659d2408f3ea80c7e5060149939c10fe 16094 libvformat1_1.13-5_amd64.deb
| Checksums-Sha256:
| 355f30750936a8e86ef7f8014e4fce0da24c7339e9019ffe56d2cbf936491292 1065
libvformat_1.13-5.dsc
| 7251fda5f90e56ea5d132399010c0b40e7dc55085efaf17ba724037e71f7d966 254463
libvformat_1.13.orig.tar.gz
| b46fb4514a03f40f1ec53275b9d1da055ab5d29d7f098c4fe17df19461c2b8fc 349647
libvformat_1.13-5.diff.gz
| e144b2314ec973658efadbe2f23ff5721d38febfd7fb77cf1dff5117b736650a 57466
libvformat1-dev_1.13-5_amd64.deb
| 4755875ee351ae6208db8ccd5185cd12e0d869e374443e2898011b59333829fd 16094
libvformat1_1.13-5_amd64.deb
| Files:
| 0c8be487fcf793644e6ba630df8578bc 1065 devel optional libvformat_1.13-5.dsc
| c0926352ec70ed10a427dd691c5eb78e 254463 devel optional
libvformat_1.13.orig.tar.gz
| eb6b216d41a85f4e2daf09ec9f6f4ff8 349647 devel optional
libvformat_1.13-5.diff.gz
| e5605370e1e5fb38df3a68db5320e832 57466 libdevel optional
libvformat1-dev_1.13-5_amd64.deb
| 7e4da76b059ecf28f1a92293a5dfa1e7 16094 libs optional
libvformat1_1.13-5_amd64.deb
|
| -BEGIN PGP SIGNATURE-
| Version: GnuPG v1.4.10 (GNU/Linux)
|
| iEYEARECAAYFAkrcvMwACgkQCFqbMnwsrrjKRgCgzsmHXLFiFD2Jxudy7Mv5Mz9t
| StUAoLfMLS8ohWQ691Iel4vMxG8pX550
| =uSJA
| -END PGP SIGNATURE-
`
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#491616: RFC and RFS: youtube-dl (updated package)
Hi, Filippo.
On Oct 11 2009, Filippo Giunchedi wrote:
On Sat, Oct 10, 2009 at 12:27:29PM -0300, Rogério Brito wrote:
Updated to the newest and greatest (and adjusted the watchfile to
automate things):
dget
http://mentors.debian.net/debian/pool/main/y/youtube-dl/youtube-dl_2009.09.13-1.dsc
how do you use the watchfile here? uscan --verbose doesn't seem to work at
least
for me.
Sorry. I changed the watchfile but forgot to include the changes in the
final package. The small fix was just to include a \.tar in the name
of the package (upstream changed that).
The fixed package is again at the address above.
anyhow, please have a look at the package I linked, it contains a
get-orig-source script which is supposed to download the latest
version and do a tarball out of it
A get-orig-source target is nice to have, indeed, but I'd prefer to use
plain, pristine upstream tarballs for trackability reasons.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFC and RFS: youtube-dl (updated package)
Dear people,
Seeing as youtube-dl, a downloader of videos from youtube, has been
bitrotting and was removed from testing (which means that it won't be
part of the new release, all things equal), I went ahead and gave the
package a facelift.
I would be happy if you could take a look at the package that I uploaded
to mentors more than one month back:
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=youtube-dl
I think that it is mostly sane, but I would love too have it reviewed
and, perhaps, sponsored.
The last update of youtube-dl was approximately 1 year and a half ago,
according to http://qa.debian.org/developer.php?login=edmo...@debian.org
(of course, I'm CC'ing Robert, the maintainer here, but
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491616 is not
encouraging).
(The version that I packaged has two changes of mine that were
incorporated in upstream's source :-) )
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC and RFS: youtube-dl (updated package)
Hi, people.
On Oct 10 2009, Rogério Brito wrote:
I would be happy if you could take a look at the package that I uploaded
to mentors more than one month back:
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=youtube-dl
Updated to the newest and greatest (and adjusted the watchfile to
automate things):
dget
http://mentors.debian.net/debian/pool/main/y/youtube-dl/youtube-dl_2009.09.13-1.dsc
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: aqemu (3rd try)
Hi, Ignace.
On Sep 24 2009, Ignace Mouzannar wrote:
Hello Eugene,
Before looking at the package, there is already a Qt4 front-end in
Debian repositories - it's 'qtemu' package. What are the advantages
of aqemu over qtemu?
Other than offering a qemu Qt4 front-end alternative for debian users,
aqemu lets you configure most of Qemu's options using a menu driven
configuration.
I'm not a user of any graphical interfaces to qemu, so I think that I'm
in a perfect condition to re-ask what Eugene asked: what does aqemu
offers that qtemu doesn't?
In the paragraph quoted above, you are just restating something that
seems to be a similarity between both, not a difference.
What would warrant having yet another package in an already big
distribution? Is aqemu leaner? Does it have more features than qtemu?
Is it any easier to use? (Of course, easiness is not an objective
factor, but that could be a difference).
Using aqemu, a user can setup an advanced qemu configuration without
having to manually input qemu flags; which could appear to be very
convenient for inexperienced qemu users.
This is something that I would expect from any front-end: if it doesn't
do that, it's failed in its very principle, IMVHO. And you're just
restating here something that you mentioned in the first message.
So, is there anything that an uninformed user that uses qemu only with a
command-line would gain from aqemu that he wouldn't get from qtemu?
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: cppcheck, new upstream version 1.36
On Sep 22 2009, George Danchev wrote:
We are of course waiting for 1.37.
Really, cppcheck has proved to be useful for spotting some errors in
some code that I got from third-parties.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ffprobe
Hi, Alessio.
On Sep 18 2009, Alessio Treglia wrote:
It builds these binary packages:
ffprobe- multimedia streams analyzer
I have not yet had time to check the package, but I use it regularly and
it would be a quite welcome addition to the archive.
I have one comment, though: with this abbreviated short description,
people might miss the package. It would be better to say a little more
about it in the short description.
I did not check the long description also, but I would suggest fleshing
it out a little bit, if it is similar to what Christian Marillat has in
his repository.
No offense to him, as he maintains a huge amount of packages and they
are not meant to be in the archive---IOW, people using his repository
should know what they are doing by using a non-distribution source of
packages.
OTOH, for packages targeted at main, it would be a good thing to have
them described in a little bit more detail.
Anyway, thank you for stepping up and bringing this very nice utility to
Debian.
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: pdftk (adopting, fixes RC bugs)
Hi there, Potential Sponsors (TM). :-)
On Sep 17 2009, Johann Felix Soden wrote:
It builds these binary packages:
pdftk - useful tool for manipulating PDF documents
The package appears to be lintian clean.
The upload would fix these bugs: 258377, 424920, 461169, 470215, 504014,
504128, 514561, 519466, 533795, 534080, 538252
The packaging seems sane enough and Johann seems to know a good deal
about the languages to fix problems on his own.
Also, this is a important program for those who want/need to manipulate
PDF files.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: pdftk (major NMU, fixes RC bugs)
Hi, Johann.
First of all, thank you for updating the packaging of pdftk. I've been
thinking about doing something like that, but just didn't have the time.
IANADD, but I'm interested in the package and I have some things to say.
just saw some things
here.
On Sep 14 2009, Johann Felix Soden wrote:
Dear mentors,
I am looking for a sponsor for my NMU of the package pdftk.
In the last month, I sent two mails to its maintainer (Aurélien GÉRÔME)
concerning his package/this NMU but got no reply.
To solve the (RC) bugs, I have to change lots of things. See below for
the shortened changelog. So this is not a normal small-diff NMU.
Yes, this is a well deserved facelift. You may, BTW, like to consider
the following:
* refresh the quilt patches, so that they apply without fuzz;
* you may want to patch the code to avoid the use of tmpnam (see the
warnings).
,
| gcj pdftk.o attachments.o report.o /usr/lib/gcj/itext-2.1.5.jar.so
-I../java_libs2 -lgcj -fdollars-in-identifiers -Wl,-Bsymbolic -Wl,--as-needed
-fpic -lstdc++ -o pdftk
| report.o: In function `ReplaceXmp(com::lowagie::text::pdf::PdfReader*,
std::basic_stringchar, std::char_traitschar, std::allocatorchar )':
| report.cc:(.text+0x27c7): warning: the use of `tmpnam' is dangerous, better
use `mkstemp'
| make[2]: Leaving directory `/tmp/pdftk-1.41+dfsg/pdftk'
| make[1]: Leaving directory `/tmp/pdftk-1.41+dfsg'
`
* some programs are compiled with warnings disabled. Any reason for
that? I'd say that -Wall -Wextra is a good thing for the C/C++ parts,
as well as -Weffc++ for C++ files.
I actually compiled it here with the warnings and it reveals some
nice things.
* there's some weird stuff going on here: if you compile the code with
-O2, then everything builds fine on amd64, at least. If you compile
with -O3, bombs with an error (not an ICE).
I'm very ignorant about Java and stuff, but it seems to me that the
compiler should be consistent about compiling the code with any kind
of optimization levels. They are not asking the compiler to change its
behaviour here.
IMVHO, you should take this upstream (perhaps it has already been
fixed if you build it with gcc-snapshot?).
* you might want to consider these lintian warnings:
,
| rbr...@chagas:/tmp$ lintian -IE --pedantic pdftk_1.41+dfsg-0.1_amd64.changes
| I: pdftk: hyphen-used-as-minus-sign usr/share/man/man1/pdftk.1.gz:54
| I: pdftk: hyphen-used-as-minus-sign usr/share/man/man1/pdftk.1.gz:153
| P: pdftk: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
| P: pdftk: no-upstream-changelog
| rbr...@chagas:/tmp$
`
* DFSG-repack and use extern libitext-java (Closes: #519466)
Thank you very much for the size reduction in the package.
It seems fine otherwise and would be a very welcome update so that the
package doesn't drag even more useless dependencies/deprecated libraries.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RANT] [OT] Bloating dependencies instead of using recommends (was: Re: RFS: sqlkit)
Hi, Paul.
On Sep 10 2009, Paul Wise wrote:
Why is this rant on debian-mentors? Seems to be more relevant for
debian-devel, planet.d.o or LWN.
You're right. Sent to debian-devel.
I don't know how to get it on planet.d.o, but I'm not really sure about
the acceptance of it on LWN---despite the fact that the bloated
dependencies is a generalized problem, not specific to debian.
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[RANT] [OT] Bloating dependencies instead of using recommends (was: Re: RFS: sqlkit)
On Sep 04 2009, Boyd Stephen Smith Jr. wrote:
On Friday 04 September 2009 13:14:43 Alessandro Dentella wrote:
So I'd really prefer to leave those 2 drivers as dependencies.
Recommends, right? As a user it annoys me to no end when the packager
Depends
on something the system will work without; I end up having to roll my own
packages to get the small footprint I desire.
Thank you so very much for bringing this up. I agree 100% with your comment.
I am really annoyed with the current trend of packages dragging in a lot
of dependencies on which the packages don't really depend. The word
dependency seems to has lost its meaning.
A software that is merely an additive to another should be a suggests
or recommends. The package managers explicitly install recommends,
unless told otherwise.
For instance, some packages of mine may be useful with some tools that I
myself never, ever use (and most probably never will---e.g., for
compression, I am willing to use gzip, bzip2 or lzma instead of lzo). I
list such other packages as recommends or suggests, as determined by
policy.
But the problem is that other people seem to have infinite computational
resources: hard disks are always the biggest, their computer memory has
no end, their cpus can run even the silliest background daemons killing
lots of cycles just to put a purple pixel in the lower right corner of
the screen with super-duper 4D with many effects, doing everything
(sure, why not) in interpreted languages (that, of course, have to be
re-JIT compiled every single time the program is run---why bother
compiling it once).
They need a super computer with the latest graphics processing unit just
to show some silly mouse trail animation.
And this problem does not happen only with Debian, and with the current
Desktop environments (proprietary or not). It also seems to happen with
some meant-to-be-small packages, also.
I can cite many examples, but I leave this as an exercise to anybody who
thinks that his system is leaner than other unnamed operating systems:
just run debtree [1] on some of your packages and be scared of what you
get as output.
[1] http://alioth.debian.org/~fjp/debtree/
Geee. Just think of the already bought, installed, established base of
computers that were sold during the last decade (which are the ones that
*are* in the hands of the users) and the sold-from-now-on.
Apparently, people don't even remember how coding were done in, say, 15
or 20 years ago. If you want to see what a surprising animation, with
sound, synchronized could be done on a i386 computer, just watch Future
Crew's Second Reality. [2]
[2] http://www.youtube.com/watch?v=XtCW-axRJV8
It was meant to be run on computers that were much slower than the ones
that we have today.
An ironic thing here is that the video on youtube has more than 17 times
(17 times!) the size of the original program.
People have come to be used to fast computers which even forbids bad
coding. I would recommend them to read a very good book called
Programming Pearls, by Jon Bentley.
With recommends, newbie and novice users will get the packages, and
one of the first things you learn in wrangling apt-get/aptitude is how
to not install Recommends by default.
Amen to that.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: faifa (new package)
Hi, Damien.
On Sep 07 2009, Damien Raude-Morvan wrote:
Faifa is a network tool to configure, inspect
flash, collect statistics on HomePlug 1.0/AV
devices.
.
It sends all private and public ethernet management
frames to the devices.
It builds these binary packages:
faifa - Homeplug 1.0/AV tool
libfaifa-dev - Homeplug 1.0/AV development libraries
libfaifa0 - Homeplug 1.0/AV library
Please, give more detailed descriptions. Especially the long description
should be a little more informative.
When you say inspect flash, do you mean inspect flash memory devices?
When you say HomePlug 1.0/AV devices, please say something along the
lines of the special-purpose, do-something-nice HomePlug 1.0/AV
device. What does AV mean? Anti-virus? Audio-video? Advanced
Virtualization?
I have not yet checked the packaging.
Thanks for your work, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libv8
IANADD, but I would offer one comment here.
On Sep 06 2009, David Bremner wrote:
At Sun, 6 Sep 2009 16:03:10 +, Antonio Radici wrote:
* Package name: libv8
Version : 1.3.9-1
Upstream Author : Google v8 team
* URL : http://code.google.com/p/v8/
Some comments, from only looking at .dsc file.
- according to the home page, v8 only works on ia32 or ARM architectures,
so Architecture: any is surprising
Despite the fact that the package works only on two architectures in a
useful way, it would be enlightening to let it build on more arches,
since some of them may FTBFS revealing errors both on the toolchain and
on the design of the program.
In fact, compiling a given piece of software against a new architecture
is enlightening.
The only possible problems that may arise are regarding the expectations
of users, but this could be documented with a short note on the
package's long description (While this package is available for all
Debian architectures, it is only known to work under ia32 and ARM) and
a slightly longer note as README.Debian, noting that further development
is on track to support more architectures.
- I doubt that many sponsors will be happy DM-Upload-Allowed: yes
on a NEW package.
While I understand that you mentioned this regarding a NEW package, I'm
a slightly bit confused about the best current practices of the DMUA
field.
Some sponsors seem to like to add the field themselves, while others
explicitly say please, add the field so that you can continue uploading
without having many rounds of e-mails. I had at least had three
sponsors telling me the latter.
Perhaps this is a particular case with my packages, perhaps it is their
preference, but it is, nonetheless, a bit confusing. :-)
I repeat it here that you mentioned the fact that the package was NEW
and things are quite different for them.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libv8
On Sep 06 2009, Sune Vuorela wrote:
On 2009-09-06, Rogério Brito rbr...@ime.usp.br wrote:
While I understand that you mentioned this regarding a NEW package,
I'm a slightly bit confused about the best current practices of
the DMUA field.
I would never upload a package that adds DMUA for someone I haven't
worked with already.
Well, perhaps the reason why the sponsors I'm talking about had asked me
to include DMUA was that they were convinced by my work on some packages
(I think) that they were sponsoring.
In this case, it wouldn't be much different from what you mean, if I
understand you what you said.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Using flash/video on non-mainstream arches and youtube-dl (was: Re: view flash website)
Hi.
I'm including -mentors on this reply, since some may be interested in
the newer packages that I offer. Please, keep the CC'ies.
On Sep 03 2009, the grv wrote:
And, for your consideration, every three days i want to visit You
tube, Vimeo website, myspace, and so on web services that use a
flash tecnology. Many people use this services, every day.
Are you using Flash for the video player part? If so, then you might
want to check some alternatives.
(Here begins the part that may be of interest to -mentors)
For instance, youtube-dl (present in the unstable part of our
repository) is a handy tool to download the files and it is frequently
updated.
I have newer version of youtube-dl at http://rb.doesntexist.org/debian/
that may be more interesting for anybody using it (it is signed with my
cryptographic key), and you can get the sources at:
dget http://rb.doesntexist.org/debian/youtube-dl_2009.08.08-1~try01.dsc
I frequently use it with aria2c, so that I can download the videos
faster (and, actually, it is a good thing to follow, say, some courses
from universities).
(Here ends the part of interest to debian-mentors).
If you just trust me (you shouldn't, since you don't know me), you can
get a ready-made package from:
http://rb.doesntexist.org/debian/youtube-dl_2009.08.08-1~try01_all.deb
After you get the videos, you can play them with vlc, mplayer, xine,
totem, whatever.
The package clive is another alternative to grab videos from all over
the place. You may want to check the mozilla/firefox plugin for mplayer
so that you can play your videos in place.
All this is available for powerpc too (I use it, and I'm interested in
the platform, as I have some very old powerpc boxes that are still going
strong).
If you are not using a flash player for videos, then using swfdec or
gnash may be an alternative (I'm not sure, since I don't use those).
The lack of flash for those alternative views is actually a plus, since
my computer doesn't get slower when I visit one site or another that
happens to have 100 ads all flying in just one page of my browser and
taking over my CPU from me.
I prefer to *not* use the flash plugin, even for platforms where Adobe
offers one (like amd64), as a way to keep my computer free of non-free
software.
Anyway, you right. I need to shutdown my debian, when i MUST to visit
flash websites.
I'm not exactly sure what you mean here. Which of the uses above is not
covered by your needs?
If you have anything that is not covered here, then you might want to
talk with the swfdec and with the gnash developers. Free software is
shaped by your views, if you participate.
If you don't, then your problems will probably not be addressed the way
that you prefer and the programs won't work your way.
Thank you.
GRV
I'm not sure about others, but I prefer not to talk to a person whose
name I can't really see. I have already read all the arguments (a name
is just a label etc), but I like to talk to a human.
This isn't mandatory, but just a way to get more feedback (at least from
my side).
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: evilvte (updated package)
Hi.
IANADD and have not seen the package, but something has bugged me once
when I was looking for some terminal programs:
On Sep 02 2009, Wen-Yen Chuang wrote:
-BEGIN PGP SIGNED MESSAGE-
Description: an VTE based super lightweight terminal emulator
Shouldn't the field start with a VTE... instead?
evilvte is a terminal emulator. It supports almost everything VTE
provides.
Now, the point with the problem: it is not, from a user's perspective,
clear what VTE means.
Perhaps mentioning what it stands for it in the long description or
avoiding using jargon/acronyms would be a better thing? For grep'able
strings, you can also include them in the description, putting it after
what the acronym stands for, inside parenthesis.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: mondo -- backup tool (updated package, fixes RC)
Hi.
On Aug 29 2009, Rogério Brito wrote:
I just updated the package mondo and this fixes an RC bug.
This was kindly sponsored by Li Daobing.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Any efficient way to specify target arches?
Hi, Hideki.
On Sep 01 2009, Hideki Yamane wrote:
On Fri, 28 Aug 2009 22:29:44 -0300
Rogério Brito rbr...@ime.usp.br wrote:
Architectures: all [! kfreebsd-i386, ! kfreebsd-amd64, ! hurd-i386]
^^^any?
Yes, of course.
That's what I want! What is needed to do so? Who can do that?
It seems that the aliases allowed by dpkg-architecture(1) are the
solution to what we need, as mentioned here.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gerix-wifi-cracker-ng
On Sep 02 2009, Alice Ferrazzi wrote:
if i remove python-dev from dependence i have a litian error
N:The package appears to use Python as part of its build process in
N:debian/rules but doesn't depend on Python.
Do you need python or python-dev? Perhaps just python would work,
depending on the package? (I have not checked it, though).
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: mondo -- backup tool (updated package, fixes RC)
Dear people,
I just updated the package mondo and this fixes an RC bug.
The current maintainer of the package has even *asked* me to do a
NMU upload (and even asked for co-maintainance---see bug #519548).
Brief information:
,
| Package name: mondo
| Version : 1:2.2.7-2.1
| URL : http://www.mondorescue.org/
| License : GPL-2
| Source dsc : http://mentors.debian.net/debian/pool/main/m/mondo/
`
The URL for quick cut'n'paste:
dget http://mentors.debian.net/debian/pool/main/m/mondo/mondo_2.2.7-2.1.dsc
The long description:
,
| Mondo is reliable. It backs up your Debian GNU/Linux server or workstation to
| tape, CD-R, CD-RW, NFS or hard disk partition. In the event of catastrophic
| data loss, you will be able to restore all of your data [or as much as you
| want], from bare metal if necessary. Mondo is in use by numerous blue-chip
| enterprises and large organizations, dozens of smaller companies, and tens of
| thousands of users.
| .
| Mondo is comprehensive. Mondo supports LVM, RAID, ext2, ext3, JFS, XFS,
| ReiserFS, VFAT, and can support additional file systems easily. It supports
| adjustments in disk geometry, including migration from non-RAID to RAID.
Mondo
| runs on all major Linux distributions and is getting better all the time. You
| may even use it to backup non-Linux partitions, such as NTFS.
`
My changes in this version:
,
|* Non-maintainer upload:
| + The ''Facelift'' release.
| + asked for by the current maintainer (who offered comaintainance).
|* debian/watch:
| + create watch file. (Closes: #544116)
|* debian/control:
| + remove duplicate Priority: and Section: fields.
| + move the Homepage: field to the source stanza.
| + avoid duplicate long description by including comment on mondo-doc.
| + add autotools-dev to Build-Depends.
| + add quilt to Build-Depends.
| + changing Standards-Version to 3.8.3 (no changes needed).
|* debian/{binary,source}.lintian-overrides:
| + remove, not used.
|* debian/copyright:
| + point to the versioned GPL (licensing audits needed).
|* debian/rules:
| + remove some comments.
| + reindent/rewrap for better legibility.
| + move the place where config.{sub,guess} are copied.
| + adapt to use quilt.
| + remove config.{sub,guess} to avoid bloating the diff.gz source.
| + remove unused strip setting (dh_strip takes care of it).
|* debian/patches:
| + include fix check for cdrecord (Closes: #519548).
| + split patches from diff.gz into separate patches.
|* debian/README.source:
| + include instructions as mandated by policy = 3.8.
`
Regarding lintian:
,
| * the package has only one warning according to unstable's version: it
| regards an empty directory, which I won't override for the moment as I
| need to check if it has any function, if it should be moved (with the
| current maintainer).
|
| * the error displayed on mentors.d.n is wrong according to Policy
| section 5.6.8, which states:
|
| If a list is given, it may include (or consist solely of) the special
| value all. In other words, in .dsc files unlike the debian/control,
| all may occur in combination with specific architectures. The
| Architecture field in the source package control file .dsc is
| generally constructed from the Architecture fields in the
| debian/control in the source package.
`
Bugs fixed:
519548 (Release Critical), 544116
I would really love if this package were sponsored, as I use this
package daily (with the patches that I put in the version above).
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Any efficient way to specify target arches?
Hi, David.
On Aug 29 2009, David Claughton wrote:
What kind of package is it, a kernel module?
No, it's not.
But even if it were, how would an efficient way of specifying the
Linux arches or the BSD arches or anything tied to a kernel that Debian
may support?
Most normal packages should work OK on bsd and hurd. I don't think
it matters if it's not very useful on these archs as long as it runs
OK.
The package is avr-evtd.
It is tied to some ioctls that are only available on Linux (and the
compatibility layer of FreeBSD doesn't cover them). Actually, it is
very hardware-dependent (for certain embedded devices).
That's the situation about FreeBSD. I'm not even sure about the Hurd.
So, that's the reason why I'm asking for a way of uploading the package
and not having it bomb when given to the buildd's, as it is Not-For-Us.
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Any efficient way to specify target arches?
Hi there.
Just a quick question: how does one would specify that a given package
should be compiled in all but a small set of arches?
Of course, I could list all the supported arches (instead of any), but
this has an annoying drawback: arches change names (e.g., arm), new
arches are included (avr32), etc.
I have one package that is primarily intended for Linux arches and,
thus, I would like to specify something like:
Architectures: all [! kfreebsd-i386, ! kfreebsd-amd64, ! hurd-i386]
but I suppose that that's not really allowed (is it?).
I just read the policy, but this wasn't addressed there.
Thanks in advance, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Taking care of existing packages
Hi, Gregor and everybody else.
On Aug 20 2009, gregor herrmann wrote:
[Any reason why this thread happens on both -devel and -mentors?]
I am not subscribed to -devel (only to -mentors; I asked to be CC'ed on
the original message).
The reason why I posted to both is that I see a trend in -mentors that
many new contributors seem to create an artificial need as a reason to
get their contributions in the distribution and choose to package a new
program.
They could, of course, be invited (if publicized more conspicuously, as
I put in my original message) to join/help an existing team as a first
step to learn the packaging issues.
The current approach has some drawbacks (a obviously non-exhaustive list):
* More existing packages means more need for QA, but we have
limited resources available. (Too many packages, none working
correctly or abandon-ware, as some would say).
* The existing teams need help from trivial things to complex
tasks. New contributors should be encouraged first to work with them
as apprentices and to, of course, raise the quality of the
existing software that we already have.
In other words, let's get what we already have in a good shape before
embarking in a new ship.
We usually don't eat something if that is still not prepared. Why
should software (or any other thing, for that matter) be different?
* Working with existing people teams helps:
+ Understand the modus operandi of collaborative software production.
+ Foster the mentoring process that the distribution needs to
keep a steady flux of good maintainers to assure the long-term
health of the project per se.
This is good both for the maintainer (explaining skills involve
what I will call here a mental organization of the tasks to
clearly see the distilled, main points of the process) and for the
apprentice, as practical knowledge is gained.
(...) true wealth is measured not by what you accumulate, but by
what you pass on to others. --- Larry Wall, 1999.
I am quite open to listening the opinions of others, so that we can
reach a better understanding of the problems involved.
And one point for meditation:
Apart from design/preference issues, would we have so many programs
written (which I would even call false starts) if we had
well-stablished programs that did their proposed goal well?
Perhaps we would, perhaps not.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Taking care of exising packages
Dear all,
Motivated by some unfortunate trends seen in debian-mentors, I would
like to raise (again) the question of wheter we are doing the right
thing or not.
Here is my plea:
,
| Attn Debian/Ubuntu/whatever developers and maintainers:
|
| It is with sadness that I see many NEW packages uploaded to the Debian
| repository and little thought about some packages that are already in
| the distribution, but that are bit-rotting.
|
| Please, if an existing package has not been updated for some time, just
| publicize this fact more conspicuously. Let us engage the existing (and
| prospective) maintainers in taking care of aging, but still useful
| packages.
|
| If, OTOH, the packages are not useful, or no one is willing to maintain
| it in Debian, I would propose to remove it as soon as possible from the
| archives, since they present problems (two of the first that come to
| mind are: users installing packages that won't work/might break their
| systems, and the burden of having to worry about security updates).
|
| In a certain sense, more *MAINTAINANCE* of programs should be expected
| from Debian Developers/Maintainers (and not only of packages, but also
| regarding the ports).
|
| Let us take a moment of reflextion regarding the archive as a whole and
| not just fire up/accept new ITP's and RFS's without taking into
| consideration the current state (and the Release Critical bug counts) of
| the existent packages.
|
| This is not meant to say that new packages should be unnacepted: just
| that a second (and third, fourth, etc) thought should be given if you
| can help improve the Distribution, so that we don't end up with a lot of
| half-working packages where all but a few are actually usable.
`
Regards, Rogério Brito.
P.S.: Please, CC'me as I am only subscribed to -mentors, but not -devel.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: about debian/watch
On Aug 15 2009, Niels Thykier wrote:
You may want to look in the uscan's man page, where there is an
example of how to watch files on SourceForge via http://sf.net/
Is there anything wrong with SF's redirector these days?
A package of mine has a watch file that I believe is correct and DEHS
was showing that the version of the package upstream was the same as the
one in Debian until, say, two or three days ago.
Now, it shows this:
http://dehs.alioth.debian.org/report.php?package=avr-evtd
Is there anything that has changed in the last few days?
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (updated package)
Hi, Russ.
On Aug 04 2009, Russ Allbery wrote:
Rogério Brito wrote:
Ooops. Fixed. The updated sources are again at the same address.
Uploaded. Thank you!
Thank you for being so kind to sponsor the package.
Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (updated package)
Hi, Russ and other mentors.
On Aug 03 2009, Russ Allbery wrote:
Rogério Brito rbr...@ime.usp.br writes:
I have one off-topic comment: I've seen some well known maintainers
do some things without the rigor that mentors apply to prospective
maintainers.
Yes. It's a little frustrating.
Frustrating is indeed the right word.
I see some weaknesses in the way that Debian is currently structured and
I think that I will write a longer e-mail about that (things that are
easily changed). Let's hope that I have the energy for that.
dget
http://mentors.debian.net/debian/pool/main/m/magicfilter/magicfilter_1.2-62.dsc
It looks like there's an accidental change to the timestamp for the
previous release in debian/changelog:
Ooops. Fixed. The updated sources are again at the same address.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (updated package)
Hi, Russ.
On Aug 02 2009, Russ Allbery wrote:
Rogério Brito rbr...@ime.usp.br writes:
|* Fix magicfilter dj550c truncates with dj670c (sometimes):
| no problems printing the attached file and marked unreproducible for
| almost 7 years. (Closes: #33666)
|* magicfilter works fine with Linux = 2.6. (Closes: #250715)
Did something change about the magicfilter package in this new release
that fixes these two bugs? If not, they don't belong in debian/changelog.
I get your point here (and I fixed them in the package and already
closed them in the BTS and I agree with the rationale behind them).
I have one off-topic comment: I've seen some well known maintainers do
some things without the rigor that mentors apply to prospective
maintainers.
Wouldn't it be the case to require said maintainers to shape up their
skills so that their packages improve and, as a side effect, the quality
of the overall distribution increases?
Anyway, back to my package in question, the sources are again fixed at
mentors.d.n, which can be found at:
dget
http://mentors.debian.net/debian/pool/main/m/magicfilter/magicfilter_1.2-62.dsc
Thanks for your advice,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: magicfilter (updated package)
Dear mentors,
I have adopted the magicfilter package some time ago and I am now fixing
some quite long-standing bugs (you can see for yourself in the list
below). I am, therefore, looking for a sponsor for the new version
1.2-62 of my package magicfilter.
Please, keep in mind that, as this package will soon be upgraded to a
new upstream version, I have left the build system that the original
maintainer created.
The new versions of the package will use a brand new build system based
on debhelper.
Well, these are the contents of the .changes file:
,[ magicfilter_1.2-62_amd64.changes ]
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Format: 1.8
| Date: Sun, 02 Aug 2009 16:52:36 -0300
| Source: magicfilter
| Binary: magicfilter
| Architecture: source amd64
| Version: 1.2-62
| Distribution: unstable
| Urgency: low
| Maintainer: Rogério Brito rbr...@ime.usp.br
| Changed-By: Rogério Brito rbr...@ime.usp.br
| Description:
| magicfilter - automatic printer filter
| Closes: 33666 101010 250715 294485 295293
| Changes:
| magicfilter (1.2-62) unstable; urgency=low
| .
|* debian/control:
| + promote djtools, recode to recommends. (Closes: #101010, #295293)
| + demote enscript to recommends. (Closes: #294485)
| + add a2ps and mpage as alternatives to enscript.
| + wrap the recommends line.
| + change Standards-Version to 3.8.2 (no changes needed).
|* Fix magicfilter dj550c truncates with dj670c (sometimes):
| no problems printing the attached file and marked unreproducible for
| almost 7 years. (Closes: #33666)
|* magicfilter works fine with Linux = 2.6. (Closes: #250715)
| Checksums-Sha1:
| 039bc9de2047e0e680219fdaf3deb45684d19126 1179 magicfilter_1.2-62.dsc
| 37cdbbbe2a9bdf5b1100dd9e21e2761f81f7896b 53502 magicfilter_1.2.orig.tar.gz
| 27608fcc3200a4295b24fc132bb8ec112b7a8429 39173 magicfilter_1.2-62.diff.gz
| 1e5b3b863a60546a5bf15134ee57e005de2e1209 51406 magicfilter_1.2-62_amd64.deb
| Checksums-Sha256:
| aed186eee01b5420f48ee82ade6434cc815f739428e6fb2cc1fb533930908ab9 1179
magicfilter_1.2-62.dsc
| 00cc5e65e4bb44df7970b5681970d95a5893b18ebd96cf2c8b0dad84b82e8b2b 53502
magicfilter_1.2.orig.tar.gz
| a4c25070c36d78cb4344df273e797f2cca8628289f5aad0e397df7ba29cd5b32 39173
magicfilter_1.2-62.diff.gz
| 685012b4f116ba12a08f31397eb2dd83e547163e66a098e9f8ebbe0e38ebc6f9 51406
magicfilter_1.2-62_amd64.deb
| Files:
| fad0f931243bc550b3e127accae4cbe8 1179 text optional magicfilter_1.2-62.dsc
| 8d1e638b84321e42b6aff60e6bde1f42 53502 text optional
magicfilter_1.2.orig.tar.gz
| 581094b4a585d5aceef199fd8cc2a2bf 39173 text optional
magicfilter_1.2-62.diff.gz
| 73705a0c30d34f0a8e4cb7915e2a688f 51406 text optional
magicfilter_1.2-62_amd64.deb
|
| -BEGIN PGP SIGNATURE-
| Version: GnuPG v1.4.9 (GNU/Linux)
|
| iEYEARECAAYFAkp1/CcACgkQCFqbMnwsrriZ6QCgmg4lQVGZbzxYiHZfWxySCOgU
| 9ZQAnRM0Gc7gYBGU32TLYglHwvkt//R1
| =HtF1
| -END PGP SIGNATURE-
`
The package appears to be mostly lintian clean (with the latest lintian
from unstable).
The upload would fix these bugs: 33666, 101010, 250715, 294485, 295293
(as seen above).
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/m/magicfilter
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/m/magicfilter/magicfilter_1.2-62.dsc
I would be glad if someone uploaded this package for me.
Kind regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: agedu
Hi, Alexander.
On May 27 2009, Alexander Prinsier wrote:
* Package name: agedu
Version : 8442-2
Upstream Author : Simon Tatham ana...@pobox.com
* URL : http://www.chiark.greenend.org.uk/~sgtatham/agedu/
* License : MIT
Section : utils
(...)
agedu - a Unix utility for tracking down wasted disk space
(...)
- dget http://mentors.debian.net/debian/pool/main/a/agedu/agedu_8442-2.dsc
IANADD, and have not reviewed your package, but IMVHO, this one gets my
vote for potential sponsors.
The combo filelight/baboab + fslint/fdupes + agedu + simhash is simply
amazing to remove cruft from one's archives.
I have compiled agedu from the upstream sources just to see what it was
all about and I am very happy that it lets us see the things which other
packages doesn't.
Recommended.
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: osgppu (3rd try)
On May 24 2009, Neil Williams wrote:
It would help if you included the long descriptions - I have no idea
what GLSL is meant to mean and the package name makes even less sense.
(...)
The Programming Language is also missing, as are details of whether
this is an updated package, a new package or whatever.
What happened to my proposal for a new template of packages to be
sponsored? The reactions seemed to be that it was an improvement over
what mentors.d.n offers currently.
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dhttpd (updated package)
Hi, Ryan.
On May 13 2009, Ryan Niebur wrote:
I am looking for a sponsor for the new version 1.02a-18
of my package dhttpd.
It builds these binary packages:
dhttpd - minimal secure webserver without cgi-bin support
I'm quite short on time and can't review your package, but updating
dhttpd is a very nice thing. Thanks.
Regards, Rogério.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
