Re: Bug:#700917: desktop-file-utils: call for (co-)maintainership [ITA]

[Paul Gevers]

On 05-05-13 04:30, Dmitry Smirnov wrote:

[Disclaimer: I haven't looked at the contents of your concern].

> Since beginning of 2013 I tried to raise concerns about it but got no
> reply from current maintainers whatsoever (see #700917).
> 
> I think now would be a good time to upload updated package that I
> prepared. I'm taking responsibility for the package by adding myself
> to Uploaders. Unless there are any objections I'll wait for a week (or
> longer) before uploading.

I think it helps to state that all three current maintainers are on the
LowNMU list [1]. For me at least that lowers the resistance against this
action a whole lot, although a simple ACK from them would be nice.

Paul
[1] http://wiki.debian.org/LowThresholdNmu



signature.asc
Description: OpenPGP digital signature

Re: Bit from the Release Team: I think I feel a song coming on... Yodel-ay-hee-hoo!

[Fili]

Ik had die website bekeken maar het leek vooral over alarm systemen te gaan. 
Die camera met recorder die sebas en ik hadden uitgekozen was volgens ons wel 
een goede keus voor het afgesproken budget. Wat mij betreft mag je die wel 
bestellen.

Groet, Fili

On 5 mei 2013, at 03:16, "Adam D. Barratt"  wrote:

> Hi,
> 
> As you may already know, we've passed responsibility for Wheezy to the
> Stable Release Managers; in other words, we've released!
> 
> As usual, there are too many people who need to be thanked for their
> work on getting us to this point to list them all individually, and we'd
> be sure to miss some.  Nevertheless, we'd like to particularly thank the
> installer team, the buildd and ftp teams, the CD team, the press team,
> the webmasters, the Release Notes editors, porters and all the package
> maintainers and translators who have contributed to making Wheezy a
> great release of which we should all be proud.
> 
> First point release
> ===
> 
> As was the case for Squeeze, we anticipate that the first point release
> for Wheezy will likely occur in approximately a month's time. That has
> yet to be finalised, but we hope to be able to confirm the plans soon.
> 
> Please co-ordinate fixes which you would like to see included in the
> point release with the Stable Release Team via a "pu" bug against the
> release.debian.org pseudopackage, including a debdiff of the current and
> proposed source packages.
> 
> Jessie!
> ===
> 
> The release of Wheezy also means that you can now upload to unstable
> those changes you've been holding off during the freeze.  Please don't
> rush to upload everything all at once, in order to reduce load on the
> buildds etc.  Automatic testing migration is not yet re-enabled, but
> that will happen during the next day or so.
> 
> As for Squeeze, we'd ask that you co-ordinate particularly large
> transitions or changes; if your plans involve major toolchain changes or
> otherwise have the potential to cause problems in unstable for a long
> time (e.g. due to FTBFS issues), please talk to us.  We know that there
> are a large number of changes which have been waiting for the release to
> happen and we're keen not to stand in the way of those but would also
> like to avoid a number of larger transitions becoming entangled.
> 
> In terms of expected larger changes, the Apache, KDE and GNOME teams
> have been staging new upstream releases in experimental. We anticipate
> requests for those releases to be moved to unstable soon. The toolchain
> maintainers are also planning a move to gcc 4.8.
> 
> That's it for now; it's time for the celebrations to begin, whether at a
> Release Party[PARTY] or otherwise. :-)
> 
> Adam, Neil, and your Debian Wheezy Release Team
> 
> [PARTY] http://wiki.debian.org/ReleasePartyWheezy


--
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/032a3853-329c-40e7-a935-3379fd9f9...@fili.nl

Bug#706819: ITP: libmagpie-perl -- RESTful Web Framework for Perl5

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libmagpie-perl
  Version : 1.131250
  Upstream Author : Kip Hampton 
Chris Prather 
* URL : http://search.cpan.org/dist/Magpie/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : RESTful Web Framework for Perl5

 Magpie is a web framework for Perl5 that steals the shiny bits from
 many different web frameworks we at Tamarou have used over the last
 decade. It is based on the ideas expressed by the W3C TAG in
 "Architecture of the World Wide Web"
 , namely that the web
 is comprised of Resources that respond to certain methods (GET, POST,
 PUT, DELETE 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/20130505093552.4126.42514.report...@auryn.jones.dk

Bug#706823: ITP: libkiokux-model-perl -- simple application specific wrapper for KiokuDB

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libkiokux-model-perl
  Version : 0.02
  Upstream Author : Yuval Kogman 
* URL : http://kiokudb.github.io/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : simple application specific wrapper for KiokuDB

 KiokuX::Model is a base class making it easy to create KiokuDB database
 instances in your application. It provides a standard way to
 instantiate and use a KiokuDB object in your apps.
 .
 As your app grows you can subclass it and provide additional
 convenience methods, without changing the structure of the code, but
 simply swapping your subclass for KiokuX::Model in e.g.
 Catalyst::Model::KiokuDB or whatever you use to glue it in.


-- 
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/20130505104357.26216.58233.report...@auryn.jones.dk

Re: OCaml and running shipped binaries (was Re: multiarch and interpreters/runtimes)

[Mehdi Dogguy]

Le 2013-05-05 03:50, Adam Borowski a écrit :

On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:

As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of 
the

build process (i.e. ocaml doesn't build-depend on itself). So no need
for cross-compilation there. OCaml has very few build-dependencies
(there are Tcl/Tk/libX11, but they are optional) and should always be
buildable natively.


Wait, wait, wait... so OCaml ships precompiled binaries and runs them 
during
the build?  It seems so, as it FTBFSes if you remove the binaries from 
boot/.




If you do it without adapting the packaging… of course, it will FTBFS!

/me o_O


That's RC, I think.



It is not. (and it is not the only package doing that).

--
Mehdi


--
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/b52eb19b11a6911a67723cdaadeb2...@dogguy.org

Re: Debian on illumos (Dyson) LiveCD

[Игорь Пашев]

Hi, all!

In a shadow of Debian 7 release, Dyson - a Debian port to illumos kernel -
became self-hosted and now has an installer :-)

http://osdyson.org/projects/dyson/wiki/Dyson_Installer


-- 
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/CALL-Q8x7FR0BJ_eHQgX-B5rAES=pjdivvfb-almnmo6frkp...@mail.gmail.com

Developer repositories for Debian

[Joerg Jaspert]

Hello world,

Now with wheezy happy and out the door, we should finally tackle a long
open issue. Developer repositories (AKA PPA) for Debian.

In this proposal we describe how a "PPA" setup properly integrated into
Debian infrastructure *could* look like. Starting from general layout
then going into technical details later on. Obviously this needs much
more than just the FTPTeam to participate, we can think of at least DSA
and the Buildd people, but there might be any number more.

BACKGROUND:
Debian would benefit from having a way for DDs to *easily* be able to
prepare a set of packages, have them autobuilt and distributed to the
users, WITHOUT all the constraints an upload to experimental or unstable
includes.  We intend to provide mechanisms to facilitate this in a way
which will strike a balance between the ease of maintenance by
developers and the ease of use by users while making sure that the
integrity of the existing Debian suites is maintained and the potential
additional legal liability this infrastructure might add is limited.

DEFINITION OF TERMS (and they are lousy, go find better ones!):
 PPA: Personal Package Archive and used whenever something in this
  document applies to both, PPAMAIN and PPAEXT

 PPAMAIN: a PPA following all rules of the Debian archive and integrated
  into the archive. NEW packages need a full check, policy has
  to be followed, the usual deal.

 PPAEXT:  PPA external to the archive, not integrated. Packages do not
  need to follow the full set of rules of the main archive and no
  NEW processing is done. Maintainer creating a PPAEXT have to
  agree to the Terms of service first, any content is the
  responsibility of the maintainer, not Debian!

Current plan:
We intent to implement PPAMAIN first, and when this is fully working we
into to then setup a different archive to provide the PPAEXT
service. Alternatively a different team can run it, but as much of the
technic behind will be the same, we should ensure to not divide too
much.

Very lousy timeframe:
I plan to put time into this after my vacation, so starting somewhere
early in July. And then it depends how complicated it will be to
implement this into the Debian infrastructure. I know what it takes for
the archive, but I'm entirely out for the buildds and machines and
whatever else otherwise. My hope is to get it implemented and usable
archive side this year.

Obviously help is always welcome, so if you want to help out, keep an
eye on the discussion that I'm sure will arise from this mail - and join
the debian-dak list in July.

USAGE SCENARIOS:
To make it a little bit easier to understand where this is coming from /
leading us to, we thought of a few usage scenarios, together with the
location they should use.

Aggressive Backport:
This is the "dotdeb.org" scenario.  For whatever reason, people need
whatever the latest version of php/mysql/apache/nginx/selectyourpoison
is, compiled for (old)stable, in order to run on their otherwise
stable servers. User needs this because they want to run the lastest
version of CmsDuJour which requires brand new versions of php and
mysql but those packages won't ever get "moved back" into Debian
proper.

This can go to PPAMAIN, as it "only" backports a defined set of
packages already existing in the archive.

Aggressive Experimental:
This is the daily build of chromium scenario. It might be helpful to
build a certain set of packages very often in a very recent
version. Which shouldn't hit unstable yet or shouldn't block
transitions.
It probably works best with a limited set of architectures to not
needlessly overload buildds of smaller/slower architectures.

This would be another PPAMAIN, as it is merely a variation of the
backport variant.

Enthusiast Preview:
This is the "Iceweasel alpha" scenario which might eliminate many
uses of the current experimental suite or extra archives like
mozilla.debian.net. Developers can have PPAs for alpha/beta
releases, which don't get in the way of uploads to unstable that are
targeting potential fixes to bugs in unstable/testing.

This is for PPAMAIN. Same set of packages as in the archive, just
ones with more possible problems.

Preparing Transitions:
 Some base package(s) should be changed in a maybe incompatible
 way. All  of its reverse (Build-)Depends will be rebuild, updated,
 and fixed in  the PPA before they get transferred to unstable.

 PPAMAIN.

Not Policy Compliant:
A Vendor is distributing  software which is going to be difficult to
modify to fit Debian policy.  It's therefore not fit for
distribution along with the traditional Debian components, but the
PPA creator got the right to distribute this piece further. There
might not even be source, and it also insists on loading its config
from /usr/local/sucky.

PPAEXT, obviously.

Qu

Re: Developer repositories for Debian

[Joachim Breitner]

Hi,

let me comment

Am Sonntag, den 05.05.2013, 14:22 +0200 schrieb Joerg Jaspert:
> Preparing Transitions:
>  Some base package(s) should be changed in a maybe incompatible
>  way. All  of its reverse (Build-)Depends will be rebuild, updated,
>  and fixed in  the PPA before they get transferred to unstable.
>
> [..]
>
>  - a PPAMAIN can have its full package set transferred into its base
>suite  with one command, provided the base suite is configured to
>receive such  transfers. (Currently we imagine only unstable will be
>configured for it, but other suites might gain this feature
>too). Only packages with  versions NEWER than those existing in the
>base suite will be transferred. All version checks of the base suite
>must be fulfilled for the transfer to work.

with a big: „Yes, thanks in advance“ from the Haskell team. This will
allow us to keep the uninstallable count in unstable very low at all
times, even while we rebuild stuff for a new compiler.

Feature suggestion: Optionally only allow the package set transferred to
unstable if all transferred packages are installable in the final set,
or similar checks as applied in the unstable → testing transition.

And a question:

>  - a PPAMAIN must have packages with unique versions which  have to be
>greater than in the base suite. Package versions are global  for the
>archive, so the ppaname has to be included in the version  uploaded
>to the PPA.

What if it is decided by the maintainers of a certain package to do the
uploads always to a PPA first and from there, via the above command, to
unstable. Will it then be ok to use „normal“ version numbers?

Greetings and thanks for the happy news,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

ITP: Summary of ITPs for new tryton-modules-* -- Modules for the Tryton Application Platform

[Mathias Behrle]

This is a summary of new modules for Tryton. All those packages belong to the
base modules published by the Tryton project and enhance the features provided
by the modules, that are already packaged for Debian.



706831: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706831
* Package name: tryton-modules-sale-supply
  Version : 2.8.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/2.8/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Sale Supply Module)
 Tryton is a high-level general purpose application platform written in Python
 and using PostgreSQL as database engine. It is the core base of a complete
 business solution.
 .
 This module provides the possibility to generate purchase requests from
 sale orders regardless of stock level. It adds handling of customer shipments
 upon confirmation and receival of the purchased products.


706832: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706832
* Package name: tryton-modules-sale-supply-drop-shipment
  Version : 2.8.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/2.8/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Sale Supply Drop Shipment
  Module) 
 Tryton is a high-level general purpose application platform written
 in Python and using PostgreSQL as database engine. It is the core base of a
 complete business solution.
 .
 This module provides the possibility to handle drop shipments, that are used
 when products are sent directly from the supplier to the customer without
 going through the warehouse.


706833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706833
* Package name: tryton-modules-account-asset
  Version : 2.8.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/2.8/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Financial and Accounting
  Module)
  Tryton is a high-level general purpose application platform written
  in Python and using PostgreSQL as database engine. It is the core base of a
  complete business solution.
  .
  This module adds the possibility to handle the depreciation of fixed assets.


706834: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706834
* Package name: tryton-modules-project-invoice
  Version : 2.8.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/2.8/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Project Invoice Module)
 Tryton is a high-level general purpose application platform written in Python
 and using PostgreSQL as database engine. It is the core base of a complete
 business solution.
 .
 This module adds the possibility to create invoices from projects.


706835: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706835
* Package name: tryton-modules-product-attribute
  Version : 2.8.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/2.8/
* License : GPL-3+
  Programming Lang: Python
  Description :  Tryton Application Platform (Product Attribute Module)
 Tryton is a high-level general purpose application platform written in Python
 and using PostgreSQL as database engine. It is the core base of a complete
 business solution.
 .
 This module provides the possibility to assign attributes and attribute sets
 to products (properties like colors, dimensions, etc.).


706836: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706836
* Package name: tryton-modules-account-fr
  Version : 2.8.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/2.8/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Financial and Accounting
  Module for France) Tryton is a high-level general purpose application
  platform written in Python and using PostgreSQL as database engine. It is the
  core base of a complete business solution.
 .
 This package contains the module with a chart of accounts for France.


706837: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706837
* Package name: tryton-modules-account-stock-anglo-saxon
  Version : 2.8.0 
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/2.8/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Account Stock Anglo Saxon
  Module) 
  Tryton is a high-level general purpose application platform written
  in Python and using PostgreSQL as database engine. It is the core base of a
  complete business solution.
 .
 This package adds the anglo-saxon accounting model for stock valuation.


706838: http://

reportbug outside the reporbug channel

[Jerome BENOIT]

Hello List,

I have just get a bug report for one of my packages via a the direct channel:
the report bug was directly sent to me:
I politely replied and I forwarded to the mainstream maintainer.
May I, and how, forward it to the reportbug debian machinery to share it ?

Thanks in advance,
Jerome


-- 
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/5186565c.7050...@rezozer.net

Re: reportbug outside the reporbug channel

[Paul Wise]

On Sun, May 5, 2013 at 8:53 PM, Jerome BENOIT wrote:

> I have just get a bug report for one of my packages via a the direct channel:
> the report bug was directly sent to me:
> I politely replied and I forwarded to the mainstream maintainer.
> May I, and how, forward it to the reportbug debian machinery to share it ?

Users sometimes get grumpy when people make their reports public and
they didn't want them to be. Best point them at the bug reporting
documentation:

http://www.debian.org/Bugs/Reporting

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6efxyvcgpfdblrcqabpzhaxx1bpg+keyz2qhkjpqrt...@mail.gmail.com

Bug#706861: ITP: calcelestial -- calcelestial calculates positions, rise & set times of celestial bodies.

[Steffen Vogel]

Package: wnpp
Severity: wishlist
Owner: Steffen Vogel 

  Package name: calcelestial
  Version : 0.3
  Upstream Author : Steffen Vogel 
  URL : http://github.com/stv0g/calcelestial
  License : GPL
  Programming Lang: C
  Description : calcelestial calculates positions, rise & set times of 
celestial bodies.

I wrote this tool to easily schedule the switching of my lighting for home 
automation.
Its the successor of my previous tool called sun which was limited to rise/set 
times of the sun [1]
calcelestial is a lot more powerful tool as its supports more planets and the 
calculation of position.

Its a little tool following the unix paradigm. Its designed to be used in 
conjunjtion with cron, at
date etc. Calculations are done with the libnova library to minimize code 
duplication.

For me this tool is extremly useful as you might note with these examples:

Schedule a BIOS wakeup 10 minutes before the sunrise in Berlin:
  nvram-wakeup -s $(date -d "-10 min $(calcelestial -p sun -m rise -q Berlin)" 
+%s)

Shutdown the system 10 minutes after sunset:
  shutdown $(date -d +10 min $(calcelestial -p sun -m set --lat=50.55 
--lon=-6.2) +%H:%M)

Enable my lighting at cilil twiglight:
  echo ~/bin/enable-lightning | at $(calcelestial -p sun -m set -q Frankfurt -H 
civil)

The sourcecode is hosted at github [2].
My package is already available at Debian mentors [3].
Im looking for a sponsor.

Regards
   Steffen

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696593
[2] https://github.com/stv0g/calcelestial
[3] http://mentors.debian.net/package/calcelestial


-- 
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/20130505142125.5087.127.report...@styx.lan

Re: Developer repositories for Debian

[Joerg Jaspert]

On 13202 March 1977, Joachim Breitner wrote:

>>  - a PPAMAIN can have its full package set transferred into its base
>>suite  with one command, provided the base suite is configured to
>>receive such  transfers. (Currently we imagine only unstable will be
>>configured for it, but other suites might gain this feature
>>too). Only packages with  versions NEWER than those existing in the
>>base suite will be transferred. All version checks of the base suite
>>must be fulfilled for the transfer to work.
> with a big: „Yes, thanks in advance“ from the Haskell team. This will
> allow us to keep the uninstallable count in unstable very low at all
> times, even while we rebuild stuff for a new compiler.

Yep, one of the reasons for it (though not with haskell especially in
mind, there are more packages that profit from it).

> Feature suggestion: Optionally only allow the package set transferred to
> unstable if all transferred packages are installable in the final set,
> or similar checks as applied in the unstable → testing transition.

That would mean having a kind-of-britney run, and only if that succeeds
move it over. Should be doable, i think.

>>  - a PPAMAIN must have packages with unique versions which  have to be
>>greater than in the base suite. Package versions are global  for the
>>archive, so the ppaname has to be included in the version  uploaded
>>to the PPA.
> What if it is decided by the maintainers of a certain package to do the
> uploads always to a PPA first and from there, via the above command, to
> unstable. Will it then be ok to use „normal“ version numbers?

Good question. The thought behind this is that a ppa haskell1 can
contain package debhelper as well as a ppa ruby42 can contain it. Both
with different changes to it. Which should work, and the easiest way to
ensure that is that each new upload to a ppa includes its ppaname.

-- 
bye, Joerg
Cabal:
 Those people, who, when they do something currently outside of
the official rules for behavior [your choice here] 1) are
exempted from censure, or 2) (more accurately) by their actions
define a new set of rules for acceptable behavior in such context.


--
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/87ip2x4hk0@gkar.ganneff.de

Re: Developer repositories for Debian

[Stefano Zacchiroli]

On Sun, May 05, 2013 at 04:48:01PM +0200, Joerg Jaspert wrote:
> > Feature suggestion: Optionally only allow the package set transferred to
> > unstable if all transferred packages are installable in the final set,
> > or similar checks as applied in the unstable → testing transition.
> 
> That would mean having a kind-of-britney run, and only if that succeeds
> move it over. Should be doable, i think.

That's a possibility, yes.

If OTOH you only want to check for installability, you might simply run
dose-distcheck on the involved packages (similarly to what the buildds
do, except they do that for build dependencies, while you likely want to
do that for binary package dependencies). Doing so might be simpler than
having to support other britney runs/installations.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian on illumos (Dyson) LiveCD

[Adam Borowski]

On Sun, May 05, 2013 at 04:12:45PM +0400, Игорь Пашев wrote:
> In a shadow of Debian 7 release, Dyson - a Debian port to illumos kernel -
> became self-hosted and now has an installer :-)
> 
> http://osdyson.org/projects/dyson/wiki/Dyson_Installer

I just tried it and ported some stuff to it, it seems that its libc is
pretty bizarre.  For example math functions in C++ require quite a bunch
of manual work (you need to explicitely cast all arguments unless they
happen to be float, double or long double).

Do you intend to switch to glibc?  If no, there'll be quite a lot of porting
work (as most upstreams don't bother about Solaris).  If yes, most of that
effort will become wasted.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130505211655.ga16...@angband.pl

Re: Git checkout/clean and double-buildability.

[Adam Borowski]

On Sun, May 05, 2013 at 04:30:05AM +0200, Lucas Nussbaum wrote:
> On 05/05/13 at 03:06 +0200, Adam Borowski wrote:
> > On Sun, May 05, 2013 at 10:00:07AM +0900, Charles Plessy wrote:
> > > Anyway, given that our infrastructure builds binary packages from a fresh
> > > unpacked source package, I would prefer if we keep the compromise that
> > > imperfect "clean" targets are not release-critical problems.
> > 
> > Note that for a big majority of packages, double builds work just fine.
> 
> [citation needed] :)
> 
> > In fact, that's most of what "make" is for: coping with partially
> > complete trees.
> 
> I think that it depends on what kind of double-builds you are
> talking about. For binary-only builds, I agree with you. But if you try
> to rebuild the source package after a binary build, I'm quite sure that
> a large number of packages will fail to build.

Yeah, I meant binary-only builds.  That's where partial builds are important
-- only C/C++ code will be ccached.

I agree with Charles that for source builds, the "clean" target is often
duplicating work that could be better done by git.  Yeah, 3.0 (git) would
solve this nicely.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130505212153.gb16...@angband.pl

Re: Debian on illumos (Dyson) LiveCD

[Игорь Пашев]

2013/5/6 Adam Borowski :

> I just tried it and ported some stuff to it, it seems that its libc is
> pretty bizarre.  For example math functions in C++ require quite a bunch
> of manual work (you need to explicitely cast all arguments unless they
> happen to be float, double or long double).
>
> Do you intend to switch to glibc?  If no, there'll be quite a lot of porting
> work (as most upstreams don't bother about Solaris).  If yes, most of that
> effort will become wasted.

Yes, I intend to switch to glibc.


-- 
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/CALL-Q8y57894A==dw4wdnbwlbetfpnf7wnyf9w0zzs7cz3s...@mail.gmail.com

Proposal: a team maintaining packages managing media types (MIME).

[Charles Plessy]

Le Sun, May 05, 2013 at 12:30:43PM +1000, Dmitry Smirnov a écrit :
> 
> I'm quite concerned that `desktop-file-validate` utility (provided by
> "desktop-file-utils" package) is checking .desktop files against
> outdated specification. On some occasions such "validation" recommend
> changes conflicting with the current specification (see more in
> #690279).

Hello Dmitry, Ross, Loïc, Josselin, Luk, Sebastian, and everybody,

How about taking the opportunity of this new release cycle to start a packaging
team to organise the work on packages providing media type (MIME) support ?

The mime-support package (which I maintain) is on Alioth on collab-maint (Git),
already writable to all DDs (but please ask first).  We could bring
mime-support, file, desktop-file-validate and shared-mime-info under a common
umbrella if you are interested.

The IANA does not provide a machine-readable list of media types and file
extensions, which makes the maintainance tedious.  I think that we would
benefit strongly from joining efforts (perhaps using shared-mime-info as a
proxy).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20130506002446.ga10...@falafel.plessy.net