Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Rick Thomas]

On Mar 23, 2011, at 2:15 AM, Christian PERRIER wrote:


I'm just not fond of "Australia/Sydney" presented as a choice, I'd
rather have "New South-Wales".



For what it's worth, the timezone database (as evidenced by, among  
other things, the output of the "tzselect" command) is organized  
mostly in terms of country/city rather than country/larger- 
geographical-area.


Which is not to say that the larger geographical areas get completely  
short-shrift in the timezone database.  Look at the directory  
structure under /usr/share/zoneinfo for example.


As I understand it, the choice of a large city in the affected  
geographic area is practical in two ways:


1) Individual cities are fairly unlikely to be split into two or more  
timezones.  Larger geographical units are more likely to be split than  
individual cities -- all depending on unpredictable future political  
squabbles.


2) Most people know what their nearest large city is.  They may not  
know the fine distinctions of past and present political divisions as  
applied to timezones as applied to their present location.



Just one point of view from somebody who occasionally lurks on the  
"tz" mailing list.


Enjoy!

Rick


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/0ef9eef7-c2e0-4767-be44-846fed53d...@pobox.com

Re: Bug#595427: wnpp: ITP: winetricks -- Quick and dirty script to download and install variousredistributable runtime libraries

[Jari Aalto]

2011-03-15 21:24 Austin English :
> On Tue, Mar 15, 2011 at 13:52, Jari Aalto  wrote:
>>    - does not depend on external programs outside of Debian.
>
> ...vast majority of its uses requires downloading things from outside of
> Debian, typically with a potentially non-DFSG license (Microsoft
> redistributable dlls being one of the most common).

But that does not conern Debian. The winetricks itsef is LGPL and DSFG
compliant.

>
>>    - has nothing to do with WINE package itself, so bundling it would
>>      not be good. Winetricks update schedule is different from WINE.
>
> Actually, we're looking at making the release schedule match Wine's
> (every other Friday), to make it easier to package. That said, it's
> not a huge deal at the moment, since Debian hasn't updated Wine in
> ages (still waiting on mingw64 to build wine-gecko, last I checked,
> but I'm not intimately familiar with the situation).

If I understand correct, there are no obstacles left with proceeding with
the packaging of winetricks?

Jari


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3licmna@picasso.cante.net

Re: Need for automatic USB stick backup package

[Marco d'Itri]

On Mar 22, Paul Wise  wrote:

> Automounting is disabled on desktops that do the right thing and when
I call bullshit on this.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: ranting vs bug filing (Re: potential MBF: first alternate depends not available in main

[Goswin von Brederlow]

Holger Levsen  writes:

> Hi,
>
> this is not particulary about unrar or Goswin...
>
> On Samstag, 19. März 2011, Goswin von Brederlow wrote:
>> No, I truely mean that unrar-free is practically useless. The stoneage
>> rar formats it suports have not been in general use for many years.
>
> http://bugs.debian.org/src:unrar shows me two unrelated bugs, none stating 
> it's useless. 
>
> I wonder why people rant here about bugs, instead of filing them in the 
> appropriate places.
>
> Ranting on -devel doesn't change things. (Sometimes its useful to make people 
> aware, yes. But then, the next step is something else than ranting again.)
>
>
> cheers,
>   Holger

And don't forget: One mans useless piece of code is another mans holy
grail.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxkmb4o2.fsf@frosties.localnet

Re: Library depending on -data packages

[Goswin von Brederlow]

Simon McVittie  writes:

> For instance, openarena needs a corresponding version of openarena-data:
> if you substitute a data-set in the same format (zipped Quake III-compatible
> assets) with non-trivial modifications, it won't be network-compatible, and
> might even crash if you don't make corresponding modifications to openarena.
> The existence of openarena-data is an implementation detail of openarena,
> so it has this relationship:
>
>/--->--- Depends -->---\
> openarena   openarena-data
>\---<-- Recommends --<--/

Why should openarena-data recommend openarena? How does the
functionality of openarena-data (provide some chunks of data) in any way
change by having openarena installed or not? It doesn't suddenly become
better in providing the data.

I feel that -data and -common packages are obviously enough auxilary
packages which only use is to provide for their main package that we do
not have to overly fear users installing only the -data package and
wndering why the game doesn't work. The recommends seems totaly
unneccessary.

Further, why is the Recommends versioned? Does that even have any affect
at all? Will "apt-get install openarena-data" with recommends enabled
update an older openarena because the recommends lists a newer version.
(Well, it does because of the Breaks. But lets say we only had
Recommends. What then?)


MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipvab3vk.fsf@frosties.localnet

Re: Bug#595427: wnpp: ITP: winetricks -- Quick and dirty script to download and install variousredistributable runtime libraries

[Philipp Kern]

On 2011-03-23, Jari Aalto  wrote:
> 2011-03-15 21:24 Austin English :
>> On Tue, Mar 15, 2011 at 13:52, Jari Aalto  wrote:
>>>    - does not depend on external programs outside of Debian.
>> ...vast majority of its uses requires downloading things from outside of
>> Debian, typically with a potentially non-DFSG license (Microsoft
>> redistributable dlls being one of the most common).
> But that does not conern Debian. The winetricks itsef is LGPL and DSFG
> compliant.

Ew, you certainly know what contrib is about, right?

Kind regards
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniojeif.h5j.tr...@kelgar.0x539.de

Re: Library depending on -data packages

[Goswin von Brederlow]

Jonathan Nieder  writes:

> (dropped cc's; hopefully that's okay.)
> Hi!
>
> Luca Capello wrote:
>
>> I see these situations as a misuse of Depends: where Recommends: would
>> be perfectly fine, otherwise Recommends: are useless.  But given that it
>> seems no one agrees with me, is such a behavior documented somewhere?
>
> Checking policy, I see:
>
>   The Recommends field should list packages that would be found
>   together with this one in all but unusual installations.
>
> which I grant is not all that helpful.


Look at it from an installing point of view. When installing foo should
also install bar in all but unusual installations then "foo Recomends:
bar" is the right thing.

In the case of a foo-data package recommending the foo package I would
say that that users should not install foo-data but install foo in all
but unusual circumstances. Since foo-data will not be installed directly
but allways through foo the question of wether it should recommend foo
becomes pointless. Yes, foo-data will nearly always be found together
with foo simply because foo depends on foo-data.

Imho we really don't want a recommends for reverse depends. Or do you
think libc6 should recommend coreutils because they will allways be
found together?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ei5yb3ci.fsf@frosties.localnet

Re: Cross compiler ITP (armel)

[Goswin von Brederlow]

Mark Hymers  writes:

> On Mon, 14, Mar, 2011 at 02:04:30PM +, Hector Oron spoke thus..
>> Hi,
>> 
>> 2009/11/2 Mark Hymers :
>> > On Mon, 02, Nov, 2009 at 12:43:42PM +, Philipp Kern spoke thus..
>> >> Of course it is a sane approach but very special care needs to be taken 
>> >> when
>> >> releasing to ensure GPL compliance.  So what we should get is support in 
>> >> the
>> >> toolchain to declare against what source package the upload was built to
>> >> keep that around.
>
> Ok, I'm only going to comment on this part.  This is nearly implemented
> and should be there by the end of the day (I need to run up some test
> packages to work with).
>
> The current design is the Binary packages can contain an additional
> control field: Built-Using.
>
> The specification of this field is that it *must* contain only strict
> version dependencies and these must be to source packages.  I.e.
>
> Built-Using: gcc-4.5 (= 4.5.2-5)

So ia32-libs could contain

Built-using: acl (= 2.2.49-4), ... 112 more entries

and drop the source copies (75% of the source package)?

It isn't exactly "using" the packages to build but it contains copies of
the prebuild debs of those versions. The GPL requirement for the source
to exist is the same though.

> If dak can't parse this field, or the source versions which are declared
> are not present when the binary package is uploaded, it will reject the
> upload.  If it can parse and find these dependencies, it stores them in
> an extra table in projectb which prevents us from throwing away the
> relevant source files until these binaries no longer exist anywhere in
> the archive, the same way as we handle it for the normal source case.

What exactly means "not present"? The ia32-libs packages are curently
build against testing. Would an upload to unstable be allowed with a
Built-Using string listing versions only in testing?

Also does the testing transition consider the Built-Using? If I specify
'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from
entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5
(= 4.5.2-5) from being replaced from testing?

> I'm not entirely sure where this should be documented, it's not really a
> policy thing as it's specific to the archive.  Suggestions welcome.
> We'll obviously include it in the minutes to d-d-a at the end of the
> meeting (the main people this should be used by, as far as I know are
> cross-compiler builders and the d-i and kernel-wedge people).
>
> Mark

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aagmb2tp.fsf@frosties.localnet

Re: Cross compiler ITP (armel)

[Goswin von Brederlow]

Mark Hymers  writes:

> On Tue, 22, Mar, 2011 at 01:57:42PM +, Hector Oron spoke thus..
>> Hi Mark,
>> 
>> 2011/3/22 Mark Hymers :
>> 
>> > The current design is the Binary packages can contain an additional
>> > control field: Built-Using.
>> 
>>  First of all, thanks very much for taking care of it, that probably
>> will get us going.
>> 
>>   I just would like to point out that current design solves half of
>> the problem (being GPL compliant), but it does not solve code
>> duplication in the archive, which it can also be useful for large
>> datasets. IMHO, we do not want source and binary packages containing
>> the same bits, bytes and nibbles, problem which might be solved by the
>> multiarch specification, treating 'source' as yet another architecture
>> (in next couple years?) :-)
>
> I'd have thought the right answer to that was to allow some form of
> Build-Depends-Source mechanism where the source is unpacked at build
> time in a known place or something.  Of course, the problem with this is
> that we traditionally haven't allowed network access to be required
> during a build so the exact semantics would have to be worked out.
> Maybe something like, if a package declares
> Build-Depends-Source: gcc-4.5
> the source code must be available under debian/external-source/gcc-4.5
> and then leave it up to the builder to sort that out.  That's a rough
> (and probably bad) idea off the top of my head - I'm sure the buildd
> team at least will have other thoughts on the matter.
>
> Mark

Using the multiarch syntax this could be folded into Build-Depends:

Build-Depends: gcc-4.5:src

That would then cause the gcc-4.5 source to be unpacked to
/usr/src/gcc-4.5/ (I would guess) as part of the installation of
Build-Depends done by sbuild or pbuilder or whatever tool you use.
There would be no special network access required during the build other
than what is already in use for installing Build-Depends in general
prior to a build.


What this really comes down to is patching dpkg / apt / aptitude so they
can "install" sources and sbuild / wanna-build / quinn-diff to cope with
the syntax.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762rab2ae.fsf@frosties.localnet

Re: Cross compiler ITP (armel)

[Philipp Kern]

On 2011-03-23, Goswin von Brederlow  wrote:
> Also does the testing transition consider the Built-Using? If I specify
> 'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from
> entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5
> (= 4.5.2-5) from being replaced from testing?

It doesn't need to.  All we want is compliance on the archive side so that the
sources are not expired away, as long as that binary is carried in a suite.
No need to involve britney at that point.

Kind regards
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniojhdp.h5j.tr...@kelgar.0x539.de

Re: Help identify packages that multiarch support will break

[Goswin von Brederlow]

Raphael Hertzog  writes:

> [ Bcc to -dpkg for info ]
>
> Hello,
>
> since multiarch support in dpkg is on good track, it's about time to
> identify what will break when people start using multiarch packages...

A while back I already posted about a major problem cases. Specifically
packages violating Debian policy: 8.2 Shared library support files. That
includes conffiles in /etc and binaries in /usr/bin. Both are already a
problem if the library SONAME changes but will bite multiarch too.

A rough check over all packages in unstable back then resulted in 126
library packages with conffiles and a further 926 (excluding those with
conffiles) library packages with binaries. A library package being one
with a shlibs file.


What is the policy on conffiles under multiarch? Can a Multi-Arch: same
package have conffiles? Or would that confuse dpkg too much?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqpi9krl.fsf@frosties.localnet

Re: Help identify packages that multiarch support will break

[Raphael Hertzog]

Hi,

On Wed, 23 Mar 2011, Goswin von Brederlow wrote:
> What is the policy on conffiles under multiarch? Can a Multi-Arch: same
> package have conffiles? Or would that confuse dpkg too much?

They can have conffiles but obviously the confffile must be the same
across all architectures (for a given version).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323105746.ga20...@rivendell.home.ouaza.com

Re: Cross compiler ITP (armel)

[Goswin von Brederlow]

Philipp Kern  writes:

> On 2011-03-23, Goswin von Brederlow  wrote:
>> Also does the testing transition consider the Built-Using? If I specify
>> 'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from
>> entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5
>> (= 4.5.2-5) from being replaced from testing?
>
> It doesn't need to.  All we want is compliance on the archive side so that the
> sources are not expired away, as long as that binary is carried in a suite.
> No need to involve britney at that point.
>
> Kind regards
> Philipp Kern

Not quite. For ia32-libs it would be nice if ia32-libs could be blocked
from testing as long as the source packages it includes aren't in
testing. Currently that is solved by building against testing in the
first palce. But that is something we can live with.


As a side note the debian-cd package needs to also consider Built-Using
when creating source images. Will the Sources.gz file list multiple
entries for a source if multiple versions are relevant?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj069k74.fsf@frosties.localnet

Re: Cross compiler ITP (armel)

[Mehdi Dogguy]

On 23/03/2011 11:59, Goswin von Brederlow wrote:

Philipp Kern  writes:


On 2011-03-23, Goswin von Brederlow  wrote:

Also does the testing transition consider the Built-Using? If I specify
'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from
entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5
(= 4.5.2-5) from being replaced from testing?


It doesn't need to.  All we want is compliance on the archive side so that the
sources are not expired away, as long as that binary is carried in a suite.
No need to involve britney at that point.

Kind regards
Philipp Kern


Not quite. For ia32-libs it would be nice if ia32-libs could be blocked
from testing as long as the source packages it includes aren't in
testing. Currently that is solved by building against testing in the
first palce. But that is something we can live with.



It's correct that there is no need to consider Built-Using when migrating
packages from one distribution to another, because the information there
is too strict. Instead, we could check that Build-Depends are fulfilled
when migrating the package. But, this is a long standing known issue
(#145257).

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d89d34f.8060...@dogguy.org

Re: Cross compiler ITP (armel)

[Steve McIntyre]

On Wed, Mar 23, 2011 at 11:59:11AM +0100, Goswin von Brederlow wrote:
>
>As a side note the debian-cd package needs to also consider Built-Using
>when creating source images.

Yup, we'll need to consider that. I'm looking forwards to having all
the stuff we need properly dealt with, however it's done.

Cheers,
-- 
Steve McIntyre, Cambridge, UK   st...@einval.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323113749.ga4...@einval.com

Re: Help identify packages that multiarch support will break

[Goswin von Brederlow]

Raphael Hertzog  writes:

> Hi,
>
> On Wed, 23 Mar 2011, Goswin von Brederlow wrote:
>> What is the policy on conffiles under multiarch? Can a Multi-Arch: same
>> package have conffiles? Or would that confuse dpkg too much?
>
> They can have conffiles but obviously the confffile must be the same
> across all architectures (for a given version).
>
> Cheers,

And if I change the conffile and upgrade does dpkg then ask twice if I
want to keep my version?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aagm9hmq.fsf@frosties.localnet

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Karl Goetz]

On Wed, 23 Mar 2011 10:18:04 +0800
Paul Wise  wrote:

> this would only work for g-i not the text-based installer. The
> text-based installer could use the GNOME strategy of providing a
> search box to input your city/country and a list of possibly
> corresponding timezones/locales.

Would you remove the 'country' question from d-i? else the timezone
option would then be asking you for redundant information.
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Karl Goetz]

On Wed, 23 Mar 2011 07:15:20 +0100
Christian PERRIER  wrote:

> Quoting Paul Wise (p...@debian.org):
> > I agree with the other Australians in the thread; the east-coast
> > timezones are currently all the same but might not be in the future
> > so we shouldn't rely on them being the same and we should allow
> > selection of Australia/Sydney vs Australia/Melbourne.
> 
> Sure. That was an option I was considering, too.
> 
> I'm just not fond of "Australia/Sydney" presented as a choice, I'd
> rather have "New South-Wales".

Is there a particular reason for this? (Perhaps consistency, guessing
by the rest of your post?)

> Given that the map idea is great...but just an idea which I certainly
> am unable to implement, and that I have to deal with what we have
> *now*, I hereby propose selecting states:
> 
>  New South-Wales

No hyphen in nsw ( http://www.nsw.gov.au/ )

>  Victoria
>  Australian Capital Territory
>  Queensland
>  Tasmania
>  South Australia
>  Northern Territory
>  Western Australia
>  Eyre Highway
>  Yancowinna county
>  Lord Howe Island

That would work, but practically its not changing a great deal from the
current setup.
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Karl Goetz]

On Wed, 23 Mar 2011 12:28:18 +1100
Ben Finney  wrote:

> Christian PERRIER  writes:
> 
> > The timezone choice in D-I is supposed to be user-friendly and easy
> > to understand for the average citizen of the said country.
> 
> FWIW: the existing Australian timezone choice in D-I seems fine from
> the point of view of the Australians I've seen do installs (including
> myself).

I'll agree with that - of all the parts of the installer that i've seen
people step through, timezones is one that they haven't needed help
with.

> > When it comes at Australia, the choice was, up to now:
> >

[14 options]

> >
> > That's indeed insane..:-). Hobart (Tasmania), Melbourne (Victoria),
> > Sydney (NSW) and Canberra (ACT) have the *exact* same time rules
> > (including DST).

There might be 14 options, but its always clear which one you want.
(the capital for your state/territory or a 'special' timezone). is
there a reason you feel its insane?

> > I currently propose to offer the following choices in D-I:
> >
> >  Victoria, ACT, NSW, Tasmania (Eastern Time, DST)
> >  Queensland (Eastern Time, no DST)
> >  South Australia (Central Time, DST)
> >  Northern Territory (Central Time, no DST)
> >  Western Australia (Western Time)
> >  Central Western Standard Time (Eucla)
> >  Lord Howe Island
> >
> > Do you guys think this would be understandable to the average
> > Australian?
> 
> Yes. However, please ensure that no-one working on this gets the
> impression this reduction in options is to be relied on; it's at the
> whim of government that demonstrates frequent whimsy in adding as well
> as reducing options.

I was wondering - is the trimming to somehow benefit the d-i people, or
those installing debian?
I'm not sure the suggested system makes it any more obvious to people
then the existing one.

For most (all?) Australian states the capital is at least 50% of the
population [1]. People know which capital is theirs, and there is a
good chance they are in it.

[1] Adelaide has 90%+ of the states population within 50km of the cbd

> > An alternative was:

Please skip this alternative :)
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Re: Help identify packages that multiarch support will break

[Raphael Hertzog]

On Wed, 23 Mar 2011, Goswin von Brederlow wrote:
> > They can have conffiles but obviously the confffile must be the same
> > across all architectures (for a given version).
> 
> And if I change the conffile and upgrade does dpkg then ask twice if I
> want to keep my version?

No.

What about stopping to ask silly questions and try it for yourself if you
really want to find problems?

git clone git://git.debian.org/users/hertzog/dpkg.git -b pu/multiarch/full

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323124007.ga15...@rivendell.home.ouaza.com

Karaoques para PC

[Patricia Lezcano]

*hola que tal? pasa que ofrezco karaokes para pc con 9800 temas son
exclusivamente pistas originales desde los temas clasicos y están
actualizadas hasta el 2010..son en español ,portugues e ingles ..el paquete
consiste en 13 dvd y viene con el catalogo de las musicas!!normalmente
estaba vendiendo a 450mil pero por ahora las estoy ofreciendo a 250 mil gs
..este karaoke es el mismo que tienen todos los locoles nocturnos de la
movida porque ellos tambien me compraron la coleccion completa ahora tambien
te quería comentar que el delivery te sale gratis bueno desde ya muchas
gracias y cualquier cosa avisas a este numero 0982775651 gracias*

Bug#619388: ITP: cernlib -- CERNLIB data analysis suite

[Lifeng Sun]

Package: wnpp
Severity: wishlist
Owner: Lifeng Sun 

* Package name: cernlib
  Version : 2006
  Upstream Author : CERN - European Laboratory for Particle Physics
* URL : http://cernlib.web.cern.ch/cernlib/
* License : GPL-2+
  Programming Lang: Fortran, C
  Description : CERNLIB data analysis suite

CERNLIB is a suite of data analysis tools and libraries created for
use in physics experiments, but also with applications to other fields
such as the biological sciences.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323135757.6766.59895.reportbug@localhost

Bug#619393: ITP: paw -- Physics Analysis Workstation

[Lifeng Sun]

Package: wnpp
Severity: wishlist
Owner: Lifeng Sun 

* Package name: paw
  Version : 2.14.04
  Upstream Author : CERN - European Laboratory for Particle Physics
* URL : http://paw.web.cern.ch/paw/
* License : GPL-2+
  Programming Lang: Fortran, C
  Description : Physics Analysis Workstation

PAW is an interactive program providing interactive graphical
presentation and statistical and mathematical analysis tools.  It is
designed to work on objects familiar to physicists such as histograms,
event files (Ntuples), vectors, etc.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323144244.7372.4686.reportbug@localhost

Bug#619394: ITP: mclibs -- CERNLIB Monte Carlo libraries

[Lifeng Sun]

Package: wnpp
Severity: wishlist
Owner: Lifeng Sun 

* Package name: mclibs
  Version : 2006
  Upstream Author : CERN - European Laboratory for Particle Physics
* URL : http://wwwasd.web.cern.ch/wwwasd/cernlib/mc.html
* License : GPL-2+
  Programming Lang: Fortran, C
  Description : CERNLIB Monte Carlo libraries

This package provides various Monte Carlo libraries included in
CERNLIB.  Likely only physicists will be interested in these packages.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323145136.7559.26829.reportbug@localhost

Bug#619396: ITP: geant321 -- Particle detector description and simulation tool

[Lifeng Sun]

Package: wnpp
Severity: wishlist
Owner: Lifeng Sun 

* Package name: geant321
  Version : 3.21.14
  Upstream Author : CERN - European Laboratory for Particle Physics
* URL : http://wwwasd.web.cern.ch/wwwasd/geant/index.html
* License : GPL-2+
  Programming Lang: Fortran, C
  Description : Particle detector description and simulation tool

GEANT is a framework for simulating the passage of subatomic particles
through matter, for instance, particle detectors.  For maximum
flexibility, GEANT simulations are performed by linking FORTRAN code
supplied by the user with the GEANT library, then running the
resulting executable.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323150128.7814.36868.reportbug@localhost

berkeley db orphaned

[Ondřej Surý]

Hi,

it seems that previous maintainer of berkeley db packages has orphaned
them all. Is there a work on creating a pkg-bdb (pkg-db) group? I
would join and help, since I also maintain php5 and cyrus-imap and
both packages use the libdb, but it's a big chunk for one
person alone.

O.
P.S.: Please Cc: I am not subscribed to debian-flame^Wdevel.
-- 
Ondřej Surý 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=XTPg2UN6zeBswW4hytBPQ=n91_emnekcst...@mail.gmail.com

Re: Bug#619393: ITP: paw -- Physics Analysis Workstation

[Mika Pflüger]

Hi,

Am Wed, 23 Mar 2011 22:42:44 +0800
schrieb Lifeng Sun :
> Package: wnpp
> Severity: wishlist
> Owner: Lifeng Sun 
> 
> * Package name: paw
>   Version : 2.14.04
>   Upstream Author : CERN - European Laboratory for Particle Physics
> * URL : http://paw.web.cern.ch/paw/
> * License : GPL-2+
>   Programming Lang: Fortran, C
>   Description : Physics Analysis Workstation
> 
> PAW is an interactive program providing interactive graphical
> presentation and statistical and mathematical analysis tools.  It is
> designed to work on objects familiar to physicists such as histograms,
> event files (Ntuples), vectors, etc.

It seems that PAW is upstream dead (last activity on the website was in
2006, the last release of PAW was in 2002, the cernlib site states in
red: 'The development and support for CERNLIB has been discontinued.
Libraries will be continued to be provided "as is"'), additionally I
don't see it being GPL-2+ licensed, at least I couldn't find any file
stating this (I searched in the 2006 tarball obtained from
http://cernlib.web.cern.ch/cernlib/version.html, maybe there is another
version?). Additionally, in the tarball are quite a lot of files that
are definitively not GPL-2+, although they arguably don't belong to PAW.
An example would be the file
2006/src/packlib/fatmen/scripts/unix/ctab_root.dat
which contains:
# (C) COPYRIGHT International Business Machines Corp. 1989,1991
# All Rights Reserved
# Licensed Materials - Property of IBM
#
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
with no further licenses. This doesn't sound like GPL-2+

Additionally, it seems to be utterly undocumented - I wanted to test if
PAWs is useful at all nowadays but couldn't figure out how to build it.

Maybe I missed the right tarball or am just to thick, but to me it
looks rather unclear if this software is worth the hassle.

Cheers,

Mika

-- 
Own your own computer. Don't use Windows 7. 


signature.asc
Description: PGP signature

Re: Cross compiler ITP (armel)

[Mark Hymers]

On Wed, 23, Mar, 2011 at 08:15:52AM +0900, Charles Plessy spoke thus..
> Le Tue, Mar 22, 2011 at 11:54:47AM +, Mark Hymers a écrit :
> > 
> > I'm not entirely sure where this should be documented, it's not really a
> > policy thing as it's specific to the archive.  Suggestions welcome.
> 
> Since the binary package control files is documented in the Policy, that will
> also document the archive-related DM-Upload-Allowed field in its next version
> (see #588014), I think that it would be nice to have the Built-Using field
> documented there too.  I find it inconvenient to have the syntax of a file
> scattered accross documents.  I can write a patch for the Policy according to
> the minutes you will publish later.

Well, assuming that the policy team agree that it should go there, I'm
happy to review any wording you come up with.  To be honest, the details
are already in my recent posts to -devel although we'll also pull them
together in the minutes to d-d-a later on.

Mark

-- 
Mark Hymers 

"I've had people claim that they actually make the sun rise rise every
 morning.  I've offered to test them by shooting them.  So far all these
 people have not responded to my endeavours."
 James Randi on BBCi Live Chat


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323165805.ga6...@hymers.org.uk

Re: Bug#619393: ITP: paw -- Physics Analysis Workstation

[Mathieu Malaterre]

On Wed, Mar 23, 2011 at 6:11 PM, Mika Pflüger  wrote:
> It seems that PAW is upstream dead (last activity on the website was in

I believe there is a recent activity on debian-science to resurect that package:

http://lists.debian.org/debian-science/2011/03/msg0.html

Lifeng are you part of this debian-science effort ?

-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinnf2rvwpdslhpubszzsrhgok9crkctcekpa...@mail.gmail.com

Re: Bug#619396: ITP: geant321 -- Particle detector description and simulation tool

[Mika Pflüger]

Hi,

Am Wed, 23 Mar 2011 23:01:28 +0800
schrieb Lifeng Sun :
> Package: wnpp
> Severity: wishlist
> Owner: Lifeng Sun 
> 
> * Package name: geant321
>   Version : 3.21.14
>   Upstream Author : CERN - European Laboratory for Particle Physics
> * URL : http://wwwasd.web.cern.ch/wwwasd/geant/index.html
> * License : GPL-2+
>   Programming Lang: Fortran, C
>   Description : Particle detector description and simulation tool
> 
> GEANT is a framework for simulating the passage of subatomic particles
> through matter, for instance, particle detectors.  For maximum
> flexibility, GEANT simulations are performed by linking FORTRAN code
> supplied by the user with the GEANT library, then running the
> resulting executable.
> 
Additionally to my concerns towards cernlib in general (see answer to
#619393), I think that GEANT is not free software. At
http://cernlib.web.cern.ch/cernlib/conditions.html
it says:
(C) Copyright CERN except where explicitly stated otherwise. Permission
to use and/or redistribute this work is granted under the terms of the
GNU General Public License. FLUKA routines included in GEANT3 are joint
copyright of INFN and CERN and are not licensed under the GPL:
permission to use and/or redistribute outside GEANT3 should be
negotiated. The software and documentation made available under the
terms of this license are provided with no warranty. 

If necessary libraries for the use of GEANT are not licensed under the
GPL and are explicitly forbidden to redistribute and use outside of
GEANT ("should be negotiated" sounds like "is not allowed" in my ears)
this can only maybe pass into non-free, but I am not even sure
redistribution is allowed, the only license-related thing I could find
about fluka is in 2005/src/geant321/examples/gexam4/guphad.F:
(C) Copyright of the authors
[...]
*   - All the rights concerning FLUKA or parts of it are only of the   *
* authors and are independent from those of the GEANT code *

with no further permissions. Seems as if this is not redistributable.

Cheers,

Mika

-- 
Own your own computer. Don't use Windows 7. 


signature.asc
Description: PGP signature

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Joey Hess]

Rick Thomas wrote:
> For what it's worth, the timezone database (as evidenced by, among
> other things, the output of the "tzselect" command) is organized
> mostly in terms of country/city rather than country/larger-
> geographical-area.

This is also largely misunderstood, as often two cities with different
entries in the database observe identical time zone rules today. In some
cases they only differed for a week a century ago. I would not consider
the TZ database or tzselect anything resembling a useful UI, although
it is an interesting exercise in completism.

-- 
see shy jo, still in his own timezone!


signature.asc
Description: Digital signature

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Rick Thomas]

On Mar 23, 2011, at 1:42 PM, Joey Hess wrote:


Rick Thomas wrote:

For what it's worth, the timezone database (as evidenced by, among
other things, the output of the "tzselect" command) is organized
mostly in terms of country/city rather than country/larger-
geographical-area.


This is also largely misunderstood, as often two cities with different
entries in the database observe identical time zone rules today. In  
some
cases they only differed for a week a century ago. I would not  
consider

the TZ database or tzselect anything resembling a useful UI, although
it is an interesting exercise in completism.

--
see shy jo, still in his own timezone!


In that case, whatever d-i does for UI, it needs to warn folks that it  
may be necessary to do a "dpkg-reconfigure tzdata" after the install,  
if they care about getting the details exactly right of that week in  
2006 when Australia hosted the Commonwealth Games.


Call us crazy if you like, but some of us do care.


Rick


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4397de66-4e61-4f91-a081-7cf296917...@pobox.com

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Christian PERRIER]

Quoting Ben Finney (ben+deb...@benfinney.id.au):
> Christian PERRIER  writes:
> 
> > I'm just not fond of "Australia/Sydney" presented as a choice, I'd
> > rather have "New South-Wales".
> 
> (Regardless of what you choose, FYI it's “New South Wales”, no hyphen.)

Sure. If I finally decide to go for a list of states and territories
for AU, I'll look back at the ISO-3166-2 database and use the exact
wording there (which, I confirm, doesn't use hyphens, you're right).

> Why do you prefer that? Australia is highly urbanised; we're accustomed
> to “Sydney” as a stand-in for “New South Wales”. Moreover, it's very
> common for time zones around the world to be described by the dominant
> city of the region (“Tokyo time”, “London time”, etc). What makes you
> dislike it?

Probably a feeling that maybe that, time being decided by states, it
makes sense to refer to states. I agree this is somehow
borderlineand I think it's at least worth taking time to think
about this with the constant goal of keeping things as simple as
possible (leaving "dpkg-reconfigure tzdata" to very very picky people). 



signature.asc
Description: Digital signature

Bug#619426: ITP: sord -- library for storing RDF data in memory

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: sord
  Version : 0~svn68
  Upstream Author : David Robillard 
* URL : http://drobilla.net/software/sord/
* License : BSD
  Programming Lang: C
  Description : A lightweight RDF model library

Sord is a lightweight C library for storing Redland Resource
Description Framework (RDF) data in memory.
.
Sord includes man pages for the library (man sord) and a
simple command line utility (man sordi).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110323191435.9742.84376.reportbug@alessio-laptop

Bug#619429: ITP: serd -- lightweight RDF syntax library

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: serd
  Version : 0~svn128
  Upstream Author : David Robillard 
* URL : http://drobilla.net/software/serd/
* License : BSD
  Programming Lang: C
  Description : lightweight RDF syntax library

 Serd is a lightweight C library for RDF syntax which supports reading
 and writing Turtle and NTriples.
 .
 Serd is not intended to be a swiss-army knife of RDF syntax, but rather
 is suited to resource limited applications, or situations where a simple
 reader/writer with minimal dependencies is ideal (e.g. in LV2 hosts or
 plugins).
 .
 Serd is:
  * small: Serd is implemented in under 2500 lines1 of standard C code.
  * portable and dependency-free: Serd uses only the C standard library,
and has no external dependencies, making it a lightweight dependency
in every sense.
  * fast and lightweight: Serd (and the included serdi tool) can be used
to stream abbreviated Turtle (unlike many other tools which can not
stream since they must first build an internal model to abbreviate).
In other words, Serd can re-serialise an unbounded amount of Turtle
using a fixed amount of memory, preserving the abbreviations in the
input.
  * conformant and well-tested: Serd is written to the Turtle, NTriples
and URI specifications, and includes a comprehensive test suite which
includes all the normative examples from the Turtle specification, all
the "normal" examples from the URI specification, and additional tests
added specifically for Serd. The test suite has over 96% code coverage
(by line), and runs with zero memory errors or leaks.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110323193747.12019.58949.reportbug@alessio-laptop

Re: Who is (co-)maintaining lcdproc package ?

[Nick Leverton]

On Mon, Mar 21, 2011 at 08:48:48PM +0100, Dominique Dumont wrote:
> Depending on your answers, I'll upload a new version with an updated 
> maintainer/uploader list. (and with a correction in the bug list which is 
> missing commas)

Hi Dominique and all,

My situation is uncertain at the moment and I don't know if I'll be
using LCDproc in future :-(  Please go ahead and upload but I don't need
to be an uploader at the moment.  If I come up with another worthwhile
contribution we can see about it perhaps :-)

Thanks to everyone for the past and future maintainership of lcdproc,
which was a major cross-distro contribution to the project.

Nick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323204730.ga25...@leverton.org

Re: Bug#619393: ITP: paw -- Physics Analysis Workstation

[Lifeng Sun]

Hi,

On Wed, Mar 23, 2011 at 6:11 PM, Mika Pflüger  wrote:
> It seems that PAW is upstream dead (last activity on the website was in
> 2006, the last release of PAW was in 2002, the cernlib site states in
> red: 'The development and support for CERNLIB has been discontinued.
> Libraries will be continued to be provided "as is"'), additionally I
> don't see it being GPL-2+ licensed, at least I couldn't find any file
> stating this (I searched in the 2006 tarball obtained from
> http://cernlib.web.cern.ch/cernlib/version.html, maybe there is another
> version?). Additionally, in the tarball are quite a lot of files that
> are definitively not GPL-2+, although they arguably don't belong to PAW.
> An example would be the file
> 2006/src/packlib/fatmen/scripts/unix/ctab_root.dat
> which contains:
> # (C) COPYRIGHT International Business Machines Corp. 1989,1991
> # All Rights Reserved
> # Licensed Materials - Property of IBM
> #
> # US Government Users Restricted Rights - Use, duplication or
> # disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
> with no further licenses. This doesn't sound like GPL-2+
>
> Additionally, it seems to be utterly undocumented - I wanted to test if
> PAWs is useful at all nowadays but couldn't figure out how to build it.
>
> Maybe I missed the right tarball or am just to thick, but to me it
> looks rather unclear if this software is worth the hassle.

These ITPs would be tagged ITA rather than ITP if the CERNLIB-related
packages were not removed from unstable about three weeks ago[1].  The
former maintainer, Kevin B. McCarty, has made them DFSG conformed and
I will follow his work.  We are also planning to fork a free version
of CERNLIB. Thank you.

Mathieu, yes, I will set the Debian Science Team as co-maintainer.


[1] http://lists.debian.org/debian-science/2011/03/msg9.html



Kind regards,
- Lifeng

-- 


signature.asc
Description: GnuPG digital signature

Bug#619396: ITP: geant321 -- Particle detector description and simulation tool

[Lifeng Sun]

Hi,

On Wed, Mar 23, 2011 at 6:29 PM, Mika Pflüger  wrote:
> Additionally to my concerns towards cernlib in general (see answer to
> #619393), I think that GEANT is not free software.

Thank you for figuring out the license issue, please see answer to
#619393.



Kind regards,
- Lifeng

-- 


signature.asc
Description: GnuPG digital signature