Re: Bug#463862: ITP: ipafont -- Japanese high quality TrueType font

[Hamish Moffatt]

On Mon, Feb 04, 2008 at 06:54:20AM +0900, Hideki Yamane wrote:
> On Sun, 03 Feb 2008 15:43:27 -0600
> William Pitcock <[EMAIL PROTECTED]> wrote:
> > This should be ttf-ipafont.
> 
>  Yes, binary package name is ttf-ipa, but source package name
>  is ipafont.

Please don't do that for a source package with a single binary package
output. It's unnecessarily confusing.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

dezabonare

[Lucia Geogia]

Buna ziua,

Doresc sa numai primesc horoscopul.


Lucia Geogia

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

NMU campaign for control|changelog encoding issues

[Christian Perrier]

Quoting Marc 'HE' Brockschmidt ([EMAIL PROTECTED]):

(in d-d-a)


> * UTF-8 debian/changelog and debian/control
> 
> Only 40 packages still use obsolete charsets in their changelog or
> control files. Please check if your package is listed on the lintian
> tag pages:
> http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html
> http://lintian.debian.org/reports/Tdebian-control-file-uses-obsolete-national-encoding.html
> 
> Bugs against the affected packages will be filed soon.


I started yesterday to NMU such packages, beginning with those that
have wrongly encoded debian/control files (and most often *also* a
wrongly encoded debian/changelog and *even* debian/copyright).

The 9 packages with bad debian/control files have been fixed:
doc-linux-html-pt
doc-linux-text-pt
elmo
fcmp
glade-perl
libroxen-linkif
libroxen-mail
libroxen-presentit
pyca

All of them already had bugs filed for this, some for more than 2 years.

Packages with incorrect debian/changelog are likely to follow with a
little more interaction with maintainers as bugs have not been filed
for all of them yet.

PS: most of these packages are more or less abandoned if one has a
look at the various trivial warnings that lintian spits out (outdated
standards, outdated debhelper compatibility level, wrong use of
build-depends-indep, etc.)



signature.asc
Description: Digital signature

Re: changing the default syslog daemon for lenny?

[Michael Biebl]

Michael Biebl wrote:
> Quoting Petter Reinholdtsen <[EMAIL PROTECTED]>:
> 
>> [Michael Biebl]
>>> That's mostly because of lots of documentation in
>>> /usr/share/doc/rsyslog. If you think that's an issue, I could split
>>> out the doc into a separate package.
>> This is probably a good idea, for those that need a very small disk
>> footprint.  Please split it into a -doc package.
>>
> 
> Ok, will do. Thanks for the feedback!

Done. I've split out the html documentation and now rsyslog weighs
258kb. It's currently waiting in NEW.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Possible mass bug filing: missing shared library dependencies

[Daniel Burrows]

On Thu, Jan 17, 2008 at 10:35:35PM +0200, Niko Tyni <[EMAIL PROTECTED]> was 
heard to say:
> Daniel Burrows <[EMAIL PROTECTED]>
>heroes-common

  Whoops.  The package started out binary-indep, then changed to binary-dep.
I remembered to start invoking dh_shlibdeps on it ... but naturally I
forgot to add ${shlibs:Depends} to the Depends line, so that shlibdeps
invocation had no effect.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic mirror selection

[Raphael Geissert]

Hi,

Leo "costela" Antunes wrote:
> 
> It's been suggested on the referred thread[0].
> I've never worked with it myself, but my limited understanding is that
> it would need work from all mirror admins and even if that was feasible,
> there are bound to be mirrors that are (technically, bureaucratically,
> etc) unable to perform the needed changes to integrate their
> infrastructure with anycast.

Seems like Simon Blake covered the main points very well so there isn't very
much left I can say.

Besides that I'm interested in how your script works at DNS level and if it
wouldn't be more suitable to just setup a server with BIND + GeoDNS[1].


> 
> 
> Cheers
> 
> [0] http://thread.gmane.org/gmane.linux.debian.user.mirrors/311/focus=312
> 

Cheers,
Raphael

[1]http://www.caraytech.com/geodns/




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic mirror selection

[Leo "costela" Antunes]

Hi,

Raphael Geissert wrote:
> 
> I'm not an expert on the subject, but wouldn't anycast be more suitable?
> 

It's been suggested on the referred thread[0].
I've never worked with it myself, but my limited understanding is that
it would need work from all mirror admins and even if that was feasible,
there are bound to be mirrors that are (technically, bureaucratically,
etc) unable to perform the needed changes to integrate their
infrastructure with anycast.


Cheers

[0] http://thread.gmane.org/gmane.linux.debian.user.mirrors/311/focus=312

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Bug#463862: ITP: ipafont -- Japanese high quality TrueType font

[Hideki Yamane]

On Sun, 03 Feb 2008 15:43:27 -0600
William Pitcock <[EMAIL PROTECTED]> wrote:
> This should be ttf-ipafont.

 Yes, binary package name is ttf-ipa, but source package name
 is ipafont.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[William Pitcock]

Hi,

On Sun, 2008-02-03 at 14:19 -0800, Steve Langasek wrote:
> On Sun, Feb 03, 2008 at 08:06:22PM +0100, Andreas Tille wrote:
> > On Sun, 3 Feb 2008, Kevin Rosenberg wrote:
> 
> >> I think that's contention, the difference in opinion between the
> >> package maintainer and some users about what software Debian should
> >> provide.
> 
> > Well, if we advise users to compile their stuff on their own
> > something is broken.  If we can not provide the latest upstream
> > version of a certain end user application because we are missing
> > some underlying libraries (for whatever reason) we IMHO failed
> > in supporting our users.
> 
> I absolutely do not agree that this is a hard rule.  If the libraries are
> unsupportable, it is a disservice to our users to pretend that we are
> supporting them by including them in a release.
> 
> Currently, the packages that are asking for wx2.8 are almost all available
> and releasable in earlier versions, built against wx2.6.  Uploading wx2.8 to
> unstable implies that it's suitable for apps to build against, which by all
> accounts it is not.

Maybe an upload to experimental would be appropriate then?

William


signature.asc
Description: This is a digitally signed message part

Bug#463873: ITP: pondus -- personal weight manager for GTK+2

[Eike Nicklas]

Package: wnpp
Severity: wishlist
Owner: Eike Nicklas <[EMAIL PROTECTED]>


* Package name: pondus
  Version : 0.1.0
  Upstream Author : Eike Nicklas <[EMAIL PROTECTED]>
* URL : http://www.ephys.de/software/pondus/
* License : GPL
  Programming Lang: Python
  Description : personal weight manager for GTK+2

 Pondus keeps track of your body weight. It aims to be simple to use,
 lightweight and fast.
 .
 The data is stored in xml-files for easy access and modification with
 other programs.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Steve Langasek]

On Sun, Feb 03, 2008 at 08:06:22PM +0100, Andreas Tille wrote:
> On Sun, 3 Feb 2008, Kevin Rosenberg wrote:

>> I think that's contention, the difference in opinion between the
>> package maintainer and some users about what software Debian should
>> provide.

> Well, if we advise users to compile their stuff on their own
> something is broken.  If we can not provide the latest upstream
> version of a certain end user application because we are missing
> some underlying libraries (for whatever reason) we IMHO failed
> in supporting our users.

I absolutely do not agree that this is a hard rule.  If the libraries are
unsupportable, it is a disservice to our users to pretend that we are
supporting them by including them in a release.

Currently, the packages that are asking for wx2.8 are almost all available
and releasable in earlier versions, built against wx2.6.  Uploading wx2.8 to
unstable implies that it's suitable for apps to build against, which by all
accounts it is not.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic mirror selection

[Raphael Geissert]

Hello,

Leo "costela" Antunes wrote:

> Hey there,
> 
> As an incredibly late follow-up to this [0] small thread, I created a
> small script to act as backend for pdns and return a mirror for the
> user's country.
> It's a simple DNS based geographic mirror selection idea.
> 
> It works by:
> - using logic based on D-I to select a mirror from a copy of
> Mirrors.masterlist[1], making it behave like a user that selects his own
> country during installation.
> - filtering by country and arch, with a fallback host if the country
> isn't found or no mirrors provide the needed arch.
> - applying a _very_ simple priority scheme to the mirrors that match,
> giving top points to hosts that match "ftp{1,2}.{2}.debian.org" and also
> preferring "leaf" over "push" mirrors.

I'm not an expert on the subject, but wouldn't anycast be more suitable?

> 
> 
> 
> Cheers
> 

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#463862: ITP: ipafont -- Japanese high quality TrueType font

[William Pitcock]

Hi,

On Mon, 2008-02-04 at 05:53 +0900, Hideki Yamane wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
> 
>Package name: ipafont

This should be ttf-ipafont.

William


signature.asc
Description: This is a digitally signed message part

Re: wnpp.debian.net sources released, security review wanted, plans for the future

[Moritz Muehlenhoff]

Sebastian Pipping wrote:
>> Not sure what you had in mind for a "feed". If you mean RDF/RSS of
>> DSAs, there are two here:
>> 
>> http://www.debian.org/security/

The recommended way is to subscribe to 
[EMAIL PROTECTED]

> Is there a way to get notified of new security
> bugs right when they are opened?

You can install debsecan, which generates reports on open security issues
and which includes BTS bugs tagged security as well.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#463862: ITP: ipafont -- Japanese high quality TrueType font

[Hideki Yamane]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: ipafont
Version: 00201
Upstream Author: Information-technology Promotion Agency, Japan.
URL: http://ossipedia.ipa.go.jp/ipafont/
License: Original
 It has restriction for distribution for Derived Works. 
 So it's non-free, now. IPA has a plan to change in the future.
 And now its license in Japanese only. We will work for 
translation.
Description: Japanese high quality TrueType font
 IPAfont is Japanese TrueType font provided by Information-
 technology Promotion Agency, Japan.
 .
 It consists of
  * IPA Gothic
  * IPA P Gochic
  * IPA UI Gothic
  * IPA Mincho
  * IPA P Mincho
~




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Moritz Muehlenhoff]

John Goerzen wrote:
> However, I am concerned that is appears to be limited in scope to packages 
> that:
>
>  * Are written in C or C++
>
>  * Can have hardening achieved through technical changes to the build process
>
> I think it is important to remember that other languages can have security 
> problems too, perhaps just as easy as these (shell). 

Sure, but we're trying to optimise for the common case here.

Everyone is welcome to start systematic security enhancement efforts for other
languages (like, checking all existing Python code for insecure sub process
invocation or something similar).

An important reason is that some features (SSP and FORTIFIED_SOURCE) allow us 
to lower the amount of needed work to fix security issues. There have been
several vulnerabilities which are non-issues on e.g. RHEL5, which has both
enabled. The ASLR changes are icing on the cake.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Moritz Muehlenhoff]

Riku Voipio wrote:
>> In kernels that support text ASLR, programs compiled
>> for PIE will gain full position randomization.
>
> For which architectures is text ASLR available? does it require
> external kernel patches? PIE means considerable system overhead
> and fatter binaries, especially for systems without large
> caches.

I'm only aware of x86 and amd64. I don't think it's necessary on
other archs.

Did you followup with upstream on the SSP problems we've seen
on ARM?

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposalto introduce compiler options passed from dpkg-buildpackage

[Moritz Muehlenhoff]

On 2007-12-25, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> Matthias Klose wrote:
>> This is a proposal to introduce a common set of compiler options which
>> can be set independently from the package, and passed/injected to the
>> package build process.  It was first discussed at the last UDS; a
>> corresponding wiki page can be found at [1].
>
> A change like that is more or less required for the planned introduction
> of security hardening features. Since noone really objected to the change
> outlined, I'd be interested in the way forward from here and what timeline
> is planned to set the changes into effect.

Matthias, what's the status?

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Standardisation of the name of the patching targets included in debian/rules.

[Stefano Zacchiroli]

On Sun, Feb 03, 2008 at 11:10:41AM +0100, Martin Quinson wrote:
> I find personnaly patch/unpatch more easy to understand, but YMMV...

I think (hope) that no one will be able to find a reason why the two
target should *not* be called "patch" / "unpatch". They are IMO the only
2 that people will be able to guess out of the blue.

So please go for patch/unpatch.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: How to cope with patches sanely (Was: State of the project - input needed)

[Stefano Zacchiroli]

On Sat, Feb 02, 2008 at 05:47:13PM +1100, martin f krafft wrote:
> As Debian moves more and more into developing countries, where
> Internet access is not (yet) ubiquitous, this seems like a step
> backwards. Ideally, the history should be on the source DVDs.

Nope, I disagree. Well, I agree that it would be cool to have the
history on the DVDs, but we have never had it, beside the changelogs
which only describe changes without including the actual changed lines.
So I fail to see how this would be a step backward.

That said, I would also love to see the .git.tar.gz format in practice,
but that would be an advantage only for developers (and only for those
which are currently missing broad band to use debcheckout ...), not for
our average users. An advancement on the same line, with a much broader
result would be obtained by having all Debian packages on whatever
version control system, no matter how we play with the source package
format.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Andreas Tille]

On Sun, 3 Feb 2008, Kevin Rosenberg wrote:


I think that's contention, the difference in opinion between the
package maintainer and some users about what software Debian should
provide.


Well, if we advise users to compile their stuff on their own
something is broken.  If we can not provide the latest upstream
version of a certain end user application because we are missing
some underlying libraries (for whatever reason) we IMHO failed
in supporting our users.  The user does not care about the underlying
infrastructure but expects us to provide the application he needs.
Our job would be to care for the needed library - if needed by
patching it to become more stable.  If this exceeds the timeframe
of a single developer the solution is called group maintenance.

Kind regards

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ur link will be aproved

[Harish Kumar]

Hi Dear

I need Law/Legal Related links, if you have then please contact me
[EMAIL PROTECTED]

Category links alsoacceptable, Pr-1


Regards
Harish

On 2/3/08, Amjad Butt <[EMAIL PROTECTED]> wrote:
> u want link exchane here
> www.newcellphoneonline.info
> www.autobike.info
>
> contect me
> [EMAIL PROTECTED]
>


-- 
---Thanks & Regards---
Harish Arora
Team Lead
Mosaic-services
New Delhi-65
Contact: 9953115325


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Raphael Hertzog]

On Sat, 02 Feb 2008, Kumar Appaiah wrote:
> On Fri, Feb 01, 2008 at 06:06:04PM +0100, Raphael Hertzog wrote:
> > No, I said "rebase" and not merge. 
> > See http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
> > 
> > (Note that this means that nobody should derive from upstream-patched as
> > the branch is regularly rewritten and one can't branch and later merge
> > from it)
> 
> Dear Raphael,
> 
> Here is where I want some explanation. Assume that my simple branches
> are:
> 
> upstream: Pure upstream sources right from the orig.tar.gz
> master: Debian packaging on top of upstream (mostly ONLY debian/
> directory addition in comparison to upstream).
> 
> In this simplistic case, should I have a new upstream version, should
> I update my upstream branch and merge it into master, or rebase
> master? While rebasing ensures that all my changes apply over the new
> upstream release, what is the reason I shouldn't merge?

If you don't touch upstream sources and only add a debian directory, then
the difference between merge and rebase is not important. Both would work
equally well (since you will never have a conflict).

I was explaining how I would handle patches on top of upstream code. And
where you have to update the patches when the upstream code changes.
Rebase is exactly the process of "updating patches" while merge is really
"keep the old patch and add fixups patch to reconcile after conflicts".

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#463806: ITP: pgtop -- display PostgreSQL performance information like top

[Christian Perrier]

Quoting Noah Slater ([EMAIL PROTECTED]):
> On Sun, Feb 03, 2008 at 04:52:03PM +0100, Christian Perrier wrote:
> > I'd suggest to phrase this "PostgreSQL performance monitoring tool" or
> > any other way to avoid a verb sentence...
> 
> Sure thing, sounds sensible. How about:
> 
>   PostgreSQL performance monitoring tool akin to top


Seems fait, yes.



signature.asc
Description: Digital signature

Re: How to cope with patches sanely

[Raphael Hertzog]

On Sat, 02 Feb 2008, Charles Plessy wrote:
> Is there sombody working on Wig&Pen? Is the format consensual enough
> that it would be accepted in Debian?

I plan to work on it (but have not done anything yet except thinking about
it and following discussions), the format might need some tweaks (explicit
list of patches instead of implicit for example) but the basic principles
are sane and I believe it will be accepted in Debian.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#463806: ITP: pgtop -- display PostgreSQL performance information like top

[Noah Slater]

On Sun, Feb 03, 2008 at 04:52:03PM +0100, Christian Perrier wrote:
> I'd suggest to phrase this "PostgreSQL performance monitoring tool" or
> any other way to avoid a verb sentence...

Sure thing, sounds sensible. How about:

  PostgreSQL performance monitoring tool akin to top

-- 
Noah Slater 

"Creativity can be a social contribution, but only in so far as
society is free to use the results." - R. Stallman


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#463806: ITP: pgtop -- display PostgreSQL performance information like top

[Christian Perrier]

Quoting Noah Slater ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: Noah Slater <[EMAIL PROTECTED]>
> 
> * Package name: pgtop
>   Version : 0.04
>   Upstream Author : Jeremy D. Zawodny <[EMAIL PROTECTED]>
> * URL : http://search.cpan.org/~cosimo/pgtop-0.04/pgtop
> * License : GPL
>   Programming Lang: Perl
>   Description : display PostgreSQL performance information like top


I'd suggest to phrase this "PostgreSQL performance monitoring tool" or
any other way to avoid a verb sentence...



signature.asc
Description: Digital signature

Bug#463806: ITP: pgtop -- display PostgreSQL performance information like top

[Noah Slater]

Package: wnpp
Severity: wishlist
Owner: Noah Slater <[EMAIL PROTECTED]>

* Package name: pgtop
  Version : 0.04
  Upstream Author : Jeremy D. Zawodny <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~cosimo/pgtop-0.04/pgtop
* License : GPL
  Programming Lang: Perl
  Description : display PostgreSQL performance information like top

pgtop is a console-based tool for monitoring queries and overall
performance of a PostgreSQL database.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.20.3-bytemark-uml-2
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Noah Slater 

"Creativity can be a social contribution, but only in so far as
society is free to use the results." - R. Stallman



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#463807: RFH: wxwidgets2.6 -- wxwidgets2.8 may be packaged

[Christoph Berg]

Package: wnpp
Severity: normal

Following this afternoon's discussion on #debian-devel, I'm filing
this RFH bug to note that Ron, the wxwidgets2.6 maintainer, does
encourage people wanting to actively work on getting 2.8 into Debian
to do so.

Bear in mind that there are lots of open issues that should be
tackled, preferably in cooperation with upstream. Starting with an
experimental upload is probably a good idea.

Ron is willing to grant alioth/git access.

(Filing on wnpp/wxwidgets2.6 for additional visibility.)

Thanks,
Christoph


signature.asc
Description: Digital signature

Bug#463796: ITP: mlt -- multimedia framework

[Fathi Boudra]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: mlt
Version: 0.2.4
Upstream Author: Charles Yates <[EMAIL PROTECTED]>
   Dan Dennedy <[EMAIL PROTECTED]>
URL: http://www.mltframework.org
License: LGPL
Description: multimedia framework

 MLT is an open source multimedia framework, designed and developed for
 television broadcasting. It provides a toolkit for broadcasters, video
 editors, media players, transcoders, web streamers and many more types of
 applications. The functionality of the system is provided via an assortment
 of ready to use tools, xml authoring components, and an extendible plug-in
 based API.

for informations, mlt++ and kdenlive ITPs will follow.

cheers,

Fathi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Andreas Tille]

On Sun, 3 Feb 2008, Richard Hartmann wrote:


On Feb 3, 2008 4:13 AM, Kevin Rosenberg <[EMAIL PROTECTED]> wrote:


I see an "other option" and it is straightforward. Do like what was
done in lenny with wxwidget2.4 and my package ctsim which requires
wxwidgets 2.4. They were removed from Debian testing and it's not a
problem. Simply download, compile, and install the library and
application yourself and don't rely on Debian for your every need.


While that is trivial for one, two or five packages to do, this approach
will, at some point, lead to exactly the mess a packaged distribution
with dependency awareness is meant to avoid.

I do not know why you think your approach is better, safer or more user
friendly than simply typing

 apt-get install ctsim

and having both ctsim and a 2.4 version of wxwidgets installed.


I seem to have missed the mail from Kevin but I might wholeheartly
add that this "other option" is something else than Debian.  We
provide a system for our users and if we force our users to build
the software we normally provide themselves we just failed.  So
I would regard the proposal not as a valid option.

Kind regards

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Standardisation of the name of the patching targets included in debian/rules.

[Martin Quinson]

On Sun, Feb 03, 2008 at 06:32:42PM +0900, Charles Plessy wrote:
> Dear maintainers of CDBS, dpatch, and quilt,
> 
> if you are subscribed to [EMAIL PROTECTED], you must have noticed the
> long discussion about patch systems. An idea that was quite popular
> was to standardise the patch target in all patch systems used during
> package building.
> 
> Here is a summary of the targets used by the different makefile
> includes available to the developpers:
> 
> File  Package To patchTo 
> depatch
> /usr/share/dpatch/dpatch.make dpatch  patch   unpatch
> /usr/share/quilt/quilt.make   quilt   patch   unpatch
> /usr/share/cdbs/1/rules/patchsys-quilt.mk quilt   apply-patches   
> reverse-patches
> /usr/share/cdbs/1/rules/simple-patchsys.mkcdbsapply-patches   
> reverse-patches
> /usr/share/cdbs/1/rules/dpatch.mk cdbsapply-dpatches  
> deapply-dpatches
> 
> Since these five files provide patching facilities to a large number of Debian
> source packages, it would be very advantageous if they could use the same
> name for the patching and depatching rules: developpers could use them
> without needing ab initio knowledge of the underlying system.
> 
> Obviously, there is no solution that wouldn't require a change in at least two
> packages, and that is the reason I contact all of you and CC debian-devel.

Hello,

I'm sorry I'm so overhelmed currently that I cannot follow d-d.
Whatever the conclusion of the discussion is, I'll happilly follow it.

/usr/share/cdbs/1/rules/patchsys-quilt.mk follows the same "syntax"
than /usr/share/cdbs/1/rules/simple-patchsys.mk since it aims at being
a (decent) drop-in replacement for the cdbs trivial patch system.

I find personnaly patch/unpatch more easy to understand, but YMMV...

A solution would be to add "patch: apply-patches" pseudo-rules to cdbs
files, and such. 

Please fill a bug when you reach a consensus to keep me aware of it.

Bye, Mt.

-- 
There is no experimental demonstration of your theorem.
  -- Bastard Reviewer From Hell


signature.asc
Description: Digital signature

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Richard Hartmann]

On Feb 3, 2008 4:13 AM, Kevin Rosenberg <[EMAIL PROTECTED]> wrote:

> I see an "other option" and it is straightforward. Do like what was
> done in lenny with wxwidget2.4 and my package ctsim which requires
> wxwidgets 2.4. They were removed from Debian testing and it's not a
> problem. Simply download, compile, and install the library and
> application yourself and don't rely on Debian for your every need.

While that is trivial for one, two or five packages to do, this approach
will, at some point, lead to exactly the mess a packaged distribution
with dependency awareness is meant to avoid.

I do not know why you think your approach is better, safer or more user
friendly than simply typing

  apt-get install ctsim

and having both ctsim and a 2.4 version of wxwidgets installed.


Best regards,
Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely (Was: State of the project -

[Matthew Johnson]

On Sun Feb 03 10:38, Pierre Habouzit wrote:

>   You agree on the fact that a Debian source package isn't (or shouldn't
> for big enough packages) be the preferred form of modification. Then
> it's that it's an exchange format. As an exchange format quilt is
> brilliant, because it holds *EVERYTHING* a SCM need to figure out how to
> rebuild meregeable and rebaseable patches from it. So why bother with
> anything else ?
> 
>   An exchange format *Must* be simple. That's the very reason why Debian
> uses rfc822-style flat files everywhere, and that's one of our best
> strength:
>   (1) this format is ubiquitous in Debian ;
>   (2) it's really easy to parse (in the Debian flavour that doesn't need
>   the stupid quoted-printeable escapings and so on at least) ;
>   (3) it's human readable ;
>   (4) implementing parsers and generators take usually less than a
>   hundred lines in a high level enough language.
> 
>   .git.tar.gz fails in those 4 points.
> 
>   What I ask you is just to be consistent. Either we _will_ modify
> source packages, either we won't. If we will, adding features to it is a
> good idea, if we won't, let's just focus on how to let it be expressive
> enough to encode in it all what we use as new features upstream from it.
> And as a matter of a fact, quilt is enough for that.

Full ACK

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: How to cope with patches sanely (Was: State of the project - input needed)

[Pierre Habouzit]

On Sat, Feb 02, 2008 at 08:38:14AM +, martin f krafft wrote:
> also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.01.27.0939 +1100]:
> > On Fri, Jan 25, 2008 at 06:00:02PM +, Raphael Hertzog wrote:
> > > On Fri, 25 Jan 2008, Michael Banck wrote:
> > > > On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
> > > > > On 25/01/08 at 08:01 +, Steve Langasek wrote:
> > > > > > As a second runner up, quilt is ok by me. :)
> 
> ...
> 
> >   I'm less and less sure that a git-based format is a brilliant
> >   idea. I like git more than a lot, but it's a poor idea to base
> >   source packages on them.
> 
> Why?

  Because it's a way to high level tool for the task. Git (and I suppose
that the following is true for other DVCS, and if not, they _REALLY_
suck, and I mean it, really) has been designed so that you can only
exchange patches. That means that you can work on your git repository,
extract your patches, send them upstream, see upstream merge them into
his git repository and when you fetch back, git figures things out.
*DANG* that's how the kernel and git itself are developed.

  There is no *need* to force people using git to grok the format since
git *is* able to grok it (not the current one, but some form of wig&pen
should probably work).

> >   IOW, all that you should need to grok what is in a source package
> > should basically be tar/ar/cpio/... and vi.
> 
> Are you sure that this has to be the case in 10 years?

  Are you sure git will be there and backward compatible in 10 years ?
Okay, it's likely given the current upstream, that focuses a _lot_ on
backward compatibility. But still. Some repository formats have been
deprecated (the object store is of version3 and IIRC git doesn't grok
version1 anymore, but I may be mistaken). That's the kind of gamble I
wouldn't take.

  Whereas I guess tar will always grok tarballs it generates today in 10
years, and gzip/bzip2/lzma/$compressor won't change either, and text is
text for enough time to assume it'll remain as editeable in 10 years.
 
> At the same time, I don't think it's wise to expect people to know
> the different ways to handle git.tar.gz and bzr.tar.gz and so on.
> I think what we want is the often-mentioned wrapper which hides the
> actual storage backend in use.

  No IMSHO we want the tools we use to be able to import informations
from these packages easily, and in fact, we rather just want them to
generate those packages. I see little point in .git.tar.gz because it
only holds _recent_ history, and you can't base new devels on it (you
cannot commit in a shallow clone in git). AFAUI in bzr it's even worse:
shallow clones have a reference to the original repository, that could
have disappeared in 10 years. So it makes this extra history usefulness
quite useless in the long term [I'm not saying it's a waste of space or
whatever, I just say it's IMHO a not so useful feature, which adds a
clear complexity and non-editability to the package].

On Sat, Feb 02, 2008 at 08:43:12AM +, martin f krafft wrote:
> also sprach Theodore Tso <[EMAIL PROTECTED]> [2008.01.28.1613 +1100]:
> > From: Author O' The Patch <[EMAIL PROTECTED]>
> > Detailed patch description
> > Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
> > 
> > This is at the beginning of every single quilt patch, and because of
> > this, we can easily important the patch into either a mercurial or git
> > repository, while preserving the authorship information of the patch.
> 
> Nice, I didn't see this before. This *is* in fact nice and puts
> the quilt *format* very high on my list.

  Yes, quilt preserves *everything* you put in the header, so if you use
git (or $scm) to generate the patches with authoring information, commit
message and so on, it wont be lost.

  You agree on the fact that a Debian source package isn't (or shouldn't
for big enough packages) be the preferred form of modification. Then
it's that it's an exchange format. As an exchange format quilt is
brilliant, because it holds *EVERYTHING* a SCM need to figure out how to
rebuild meregeable and rebaseable patches from it. So why bother with
anything else ?

  An exchange format *Must* be simple. That's the very reason why Debian
uses rfc822-style flat files everywhere, and that's one of our best
strength:
  (1) this format is ubiquitous in Debian ;
  (2) it's really easy to parse (in the Debian flavour that doesn't need
  the stupid quoted-printeable escapings and so on at least) ;
  (3) it's human readable ;
  (4) implementing parsers and generators take usually less than a
  hundred lines in a high level enough language.

  .git.tar.gz fails in those 4 points.

  What I ask you is just to be consistent. Either we _will_ modify
source packages, either we won't. If we will, adding features to it is a
good idea, if we won't, let's just focus on how to let it be expressive
enough to encode in it all what we use as new features upstream from it.
And as a matter of a fact, quilt is enough for

Standardisation of the name of the patching targets included in debian/rules.

[Charles Plessy]

Dear maintainers of CDBS, dpatch, and quilt,

if you are subscribed to [EMAIL PROTECTED], you must have noticed the
long discussion about patch systems. An idea that was quite popular
was to standardise the patch target in all patch systems used during
package building.

Here is a summary of the targets used by the different makefile
includes available to the developpers:

FilePackage To patchTo 
depatch
/usr/share/dpatch/dpatch.make   dpatch  patch   unpatch
/usr/share/quilt/quilt.make quilt   patch   unpatch
/usr/share/cdbs/1/rules/patchsys-quilt.mk   quilt   apply-patches   
reverse-patches
/usr/share/cdbs/1/rules/simple-patchsys.mk  cdbsapply-patches   
reverse-patches
/usr/share/cdbs/1/rules/dpatch.mk   cdbsapply-dpatches  
deapply-dpatches

Since these five files provide patching facilities to a large number of Debian
source packages, it would be very advantageous if they could use the same
name for the patching and depatching rules: developpers could use them
without needing ab initio knowledge of the underlying system.

Obviously, there is no solution that wouldn't require a change in at least two
packages, and that is the reason I contact all of you and CC debian-devel.

Have a nice day,

-- 
Charles Plessy
Debian-med packaging team
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely (Was: State of the project - input needed)

[Pierre Habouzit]

On Sat, Feb 02, 2008 at 08:21:44AM +, martin f krafft wrote:
> also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.01.27.0505 +1100]:
> >   Seconded. I'd add, that in fact we should standardize on quilt
> >   as an exchange format for patches, because it's simple, and that
> >   there are powerful tools to handle them.
> 
> Except those patches contain no VCS-specific data, like the author.
> In relation to licencing issues, I think it's especially interesting
> to have the ability to cherry-pick and keep the original committer
> info unchanged. I'd say what we really want is a way to cherry-pick
> between different VCS, and a higher-level wrapper on top of all VCS
> implementing a generic, cross-distro workflow.

  FWIW I export my patches in an almost quilt compatible way (ls -1 >
series and that would be true), using git format-patch, hence retaining
VCS informations.

  Using quilt as an exchange format doesn't mean that you should strip
off VCS metadatas (for the clever ones that supports it). Git works the
same with a series of patches with authoring information. That's carved
into its design.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpYMOVI7eNCh.pgp
Description: PGP signature

Re: How to cope with patches sanely (Was: State of the project - input needed)

[Andreas Tille]

On Sat, 2 Feb 2008, martin f krafft wrote:


PS: this figure is 80% correct but will surely be questioned by 70%
of the people. The likelihood that someone replies to this message
is 50%.


I just take the mere chance to do this. ;-)


The likelihood that someone flames is currently 12.6%.


Is this number related to the 50% answers or absolute?


The likelihood that I err is 0.


I like this. ;-)

I also like the feeling when sun might have risen behind the mountains
in high North

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]