date:20140116

Serata sulla pacchettizzazione per Debian a Varese: 20 gennaio

2014-01-16 Thread Elena ``of Valhalla''


Lunedì 20 gennaio il LIFO di Varese organizzerà una serata di
introduzione alla pacchettizzazione per Debian.

Si vedrà la realizzazione di un pacchetto .deb semplice, ma si parlerà 
anche di come far entrare in Debian un nuovo pacchetto e della 
sua vita.

L'incontro si terrà presso la sede LIFO in piazza de Salvo, dalle 
21:15 in poi. La partecipazione è libera e gratuita, ma 
è fortemente consigliato avvisare della propria partecipazione 
per essere sicuri di trovare una sedia ed avere un numero 
di telefono da chiamare nel caso in cui non si trovi il posto :)

http://lifolab.org/corsi/2014-seminari.html

Alla fine della serata si terrà un piccolo keysigning party: 
portate documenti e il fingerprint della vostra chiave.

-- 
Elena ``of Valhalla''


signature.asc
Description: Digital signature

Re: Serata sulla pacchettizzazione per Debian a Varese: 20 gennaio

2014-01-16 Thread pioz

Bellissimo incontro, peccato sia un po' lontano da casa mia. Qualcuno
può organizzare un incontro simile nelle zone di Padova?

Il 16/01/14 15:18, Elena ``of Valhalla'' ha scritto:
 
 Lunedì 20 gennaio il LIFO di Varese organizzerà una serata di
 introduzione alla pacchettizzazione per Debian.
 
 Si vedrà la realizzazione di un pacchetto .deb semplice, ma si parlerà 
 anche di come far entrare in Debian un nuovo pacchetto e della 
 sua vita.
 
 L'incontro si terrà presso la sede LIFO in piazza de Salvo, dalle 
 21:15 in poi. La partecipazione è libera e gratuita, ma 
 è fortemente consigliato avvisare della propria partecipazione 
 per essere sicuri di trovare una sedia ed avere un numero 
 di telefono da chiamare nel caso in cui non si trovi il posto :)
 
 http://lifolab.org/corsi/2014-seminari.html
 
 Alla fine della serata si terrà un piccolo keysigning party: 
 portate documenti e il fingerprint della vostra chiave.
 



signature.asc
Description: OpenPGP digital signature

Re: Serata sulla pacchettizzazione per Debian a Varese: 20 gennaio

2014-01-16 Thread Francesco Cargiuli

Zona Padova sarei interessato anche io.

Francesco Cargiuli


Il giorno 16 gennaio 2014 15:36, pioz p...@pioz.it ha scritto:

 Bellissimo incontro, peccato sia un po' lontano da casa mia. Qualcuno
 può organizzare un incontro simile nelle zone di Padova?

 Il 16/01/14 15:18, Elena ``of Valhalla'' ha scritto:
 
  Lunedì 20 gennaio il LIFO di Varese organizzerà una serata di
  introduzione alla pacchettizzazione per Debian.
 
  Si vedrà la realizzazione di un pacchetto .deb semplice, ma si parlerà
  anche di come far entrare in Debian un nuovo pacchetto e della
  sua vita.
 
  L'incontro si terrà presso la sede LIFO in piazza de Salvo, dalle
  21:15 in poi. La partecipazione è libera e gratuita, ma
  è fortemente consigliato avvisare della propria partecipazione
  per essere sicuri di trovare una sedia ed avere un numero
  di telefono da chiamare nel caso in cui non si trovi il posto :)
 
  http://lifolab.org/corsi/2014-seminari.html
 
  Alla fine della serata si terrà un piccolo keysigning party:
  portate documenti e il fingerprint della vostra chiave.

Re: Serata sulla pacchettizzazione per Debian a Varese: 20 gennaio

2014-01-16 Thread Stefano Zacchiroli

On Thu, Jan 16, 2014 at 03:18:03PM +0100, Elena ``of Valhalla'' wrote:
 Lunedì 20 gennaio il LIFO di Varese organizzerà una serata di
 introduzione alla pacchettizzazione per Debian.

Ottima iniziativa, grazie Elena.

Visto l'interesse in questo thread, segnalo a chi non lo conoscesse
questo manuale (e pacchetto):

  http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.pdf
  http://packages.debian.org/sid/packaging-tutorial

che contiene un ottimo tutorial di pacchettizzazione Debian,
riutilizzabilissimo in contesti come questo. È pensato per una giornata
di workshop, con tanto di esercizi per gli studenti. È quindi un po'
lungo per una serata più mordi e fuggi, ma ci si può facilmente ispirare
ad esso (= scopiazzare allegramente).

Visto che siamo in tema, segnalo anche che qui:

  http://www.debian.org/doc/manuals/packaging-tutorial/

ci sono molte traduzioni del tutorial, ma ne manca una italiana (hint,
hint :-))

Buona pacchettizzazione!
-- 
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 »


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-devel-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-devel-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140116152321.ga5...@upsilon.cc

Re: Boutique Debian France

2014-01-16 Thread Raphael Hertzog

Bonjour Jean-Philippe,

On Thu, 16 Jan 2014, Jean-Philippe Garcia Ballester wrote:
   Je trouve dommage que cette initiative fort intéressante reste
   cloisonnée au monde du logiciel libre et ne mette pas en avant d'autre
   mouvements alternatifs (coton biologique, commerce équitable,
   meilleurs conditions de travail des salariés, production locale,
   développement durable, travail d'insertion, le choix ne manque pas).

   Financer le logiciel libre en vendant des produits issus de
   l'exploitation de la pauvreté et néfastes pour l'environnement
   (transport et produits phytosanitaires nécessaires à la culture du
   coton) me semble contradictoire.

Le fait que le site ne mentionne pas ce type d'engagement ne veut pas
dire qu'il s'agit systématiquement d'importations de produits exploitant
la pauvreté. Merci d'éviter les raccourcis trop rapides.

La plupart de nos prestataires sont français et produisent en France
(hors des produits venant de Debian.CH, parapluie/couteaux).
Ensuite nous n'avons pas trop prêté attention à l'origine des
matières premières mais je suis certain que le conseil d'administration
verrait cela d'un bon œil que tu t'investisses dans ces opérations
de merchandising pour trouver des prestataires offrant de telles
garanties.

Cordialement,
 Raphaël — président de Debian France.
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140116104434.ga24...@x230-buxy.home.ouaza.com

Re: xpdf removed from testing? - Back again?

2014-01-16 Thread Svante Signell

On Wed, 2014-01-15 at 22:09 +0100, Svante Signell wrote:
 On Mon, 2014-01-13 at 17:47 +, Ian Jackson wrote:
  Svante Signell writes (Re: xpdf removed from testing?):
   On Mon, 2014-01-13 at 16:59 +, Neil Williams wrote:
That's 7 entirely sufficient reasons and one problem that arguably makes
fixing the other seven harder. So 7.5 reasons to remove it from testing.
   
   OK; OK, I understand completely. As a follow-up: according to popcon
   there are about 10 000 installations of that package. Any
   interest/chance that patches will help re-introduce this package, or is
   it just a waste of effort? What is the opinion of the maintainers?
  
  If the existing maintainer doesn't have the effort to stop the package
  being removed from testing then clearly they need help.
 
 Noted, action taken!
 
  If you provide patches, with a view to xpdf staying in the archive,
  you should probably be prepared for the maintainer to offer you the
  package :-).
 
 I might be interested to continue working on this package, as a start
 with the maintainers blessing, see below.
 
  I would love to help but my I'm out of the special waterproof tuits
  required for swamp-draining.  Good luck.
 Thanks!
 
 Yay, xpdf builds again (and prints) :-)
 
 I cleaned out the duplicated code between xpdf and poppler (which is a
 continuation of xpdf becoming a PDF rendering library). Some more
 cleaning is still needed, to actually remove all irrelevant code (and
 update relevant code). Is it possible to create a new code base from my
 changes and the many patches?
 
 The patched version of xpdf has been tested with both libpoppler19
 (0.18.4-10) and libpoppler37 (0.22.5-3). libfontconfig version is
 2.11.0-2.

Additionally, the build system needs an upgrade to use auto{,re}conf,
standards version 3.9.5, etc. I'm willing to do that too. Should I send
a mega-patch against 3.0.3-11 in a bug report or is there a better
way?  



-- 
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/1389860201.9619.53.ca...@g3620.my.own.domain

Re: [mass bug] New license problem/sourceless fil/privacy problems detected by lintian

2014-01-16 Thread Emmanuel Bourg

Thank you for the new Java check, that will be really useful.

Do you test if the jar files contain Java classes?

I'd suggest adding an exception (or lowering the severity) for the jar
files found under a '*/src/test*' or */src/it/*'  directory, as they are
usually legitimate test objects. It's often found in Java components
manipulating jar files (jdependency, libcommons-compress-java,
plexus-classworlds, maven-shade-plugin, maven-archiver...).

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature

Re: xpdf removed from testing?

2014-01-16 Thread Simon McVittie

On 15/01/14 21:09, Svante Signell wrote:
 I cleaned out the duplicated code between xpdf and poppler (which is a
 continuation of xpdf becoming a PDF rendering library). Some more
 cleaning is still needed, to actually remove all irrelevant code (and
 update relevant code). Is it possible to create a new code base from my
 changes and the many patches?

This (and the build-system fixing you mentioned in another mail) sounds
like a job for a new upstream project, rather than something that is
in-scope for Debian packaging. If you[1] want to be its upstream
maintainer, I would suggest either forking xpdf under a new name[2] of
your choice, or asking its (former?) upstream maintainers to give you
custody of the official continuation of xpdf.

If nobody wants to be the de facto upstream maintainer of this fork,
then I don't think it's appropriate to keep it in Debian either: I think
there's a limit to the sort of changes that it's appropriate to make via
distro patches. Refactoring and deleting unnecessary code is a great
thing to do as an upstream, but not as a distributor.

If, as an upstream, your only release mechanism is via Debian, that's
your decision, of course; but even if it is, I think a fork that behaves
like its own upstream project should be identified as such.

I haven't used xpdf for years, so I have no informed opinion on the
choice between it's worth taking over and fixing vs. let it die,
switch to something else.

S

[1] all uses of you refer to any prospective maintainer, not just Svante

[2] not necessarily a new name for the package/binary (particularly if
the current upstream is completely dormant), but it'd be polite to at
least have a conventional name for your version in its documentation,
similar to the way {AGPL,Aladdin,ESP,GNU} Ghostscript are labelled


-- 
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/52d7cd2d@debian.org

Re: Roll call for porters of architectures in sid and testing

2014-01-16 Thread Aníbal Monsalve Salazar

Hi,

Just for the record.

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the jessie release:

For mips/mipsel, I
- test packages on these architectures on my own machines at home and at
  ImgTec
- fix toolchain issues together with other developers at ImgTec
- triage arch-specific bugs
- fix arch-related bugs
- will maintain buildds

I am a DD.

Aníbal Monsalve Salazar


signature.asc
Description: Digital signature

mass-filing bug reports to use dh-autoreconf during the build

2014-01-16 Thread Matthias Klose

Last year, I started to file bug reports for the arm64 port, which required new
versions of the config.sub and config.guess scripts.  All of these can be fixed
by using the autotools-dev package for the update.  Now, another port requires
not just updates to the config.* scripts, but an update to libtool.m4  and then
regenerating the configure file (see #726404).  I would like to file bug reports
for these and user-tag them, proposing as user / usertags

  User: debian-devel@lists.debian.org
  Usertags: autoreconf

For packages using recent versions of autoconf and automake, the patches are
simple, calling dh_autoreconf in the rules file and adding a b-d on
dh-autoreconf.  Packages using older autotools versions may need setting of
environment vars to call the appropriate old autotools scripts.  Other packages
need additional b-d's to pick up .m4 files for the regeneration of the configure
scripts.  There may be small number of packages where the files needed to
regenerate the configure scripts are not in the archive (gutenprint might be
such an example)

I expect that some hundred bug reports would be filed for this.

  Matthias


-- 
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/52d81606.4030...@debian.org

Re: [mass bug] New license problem/sourceless fil/privacy problems detected by lintian

2014-01-16 Thread Bálint Réczey

Hi Bastien,

2014/1/15 Bastien ROUCARIES roucaries.bast...@gmail.com:
Hi,

I have just implemented a few new check in lintian:
detecting non free file based on md5sum[1]. These file are non free.
I have filled a few bugs and I plan to fill more on it, when I get more
reports.
Please send bug to lintian to add more file to detect. We could also
detect non distributable file if needed.

Another tags of interest are detection of flash object [2][3]
I have filled bug when I could not find the source. I plan to fill more

Moreover lintian detect minified javascript (based on extension).[4]
I am slowly manually checking if source is present and fill bug when
appropriate.
I plan to detect more minified javascript based on contents analysis
(line too long some comments) in newer lintian version.

I have also created tags for .jar and .py(c|o) object but I will not
open bug and manually check (I am not an expert in these kind of
stuff). Please java team and python get a glimpse at these tags [5][6]

Last but not least I have splitted the privacy-breach tags. Lintian
gives now some piece of advice depending of the problem.

Feel free to open bugs against lintian in case of false positive or
other problems [7]

Thank you

[1] http://lintian.debian.org/tags/license-problem-md5sum-non-free-file.html
[2] http://lintian.debian.org/tags/source-contains-prebuilt-flash-object.html
[3] http://lintian.debian.org/tags/source-contains-prebuilt-flash-project.html
[4]
http://lintian.debian.org/tags/source-contains-prebuilt-javascript-object.html
[5] http://lintian.debian.org/tags/source-contains-prebuilt-java-object.html
[6] http://lintian.debian.org/tags/source-contains-prebuilt-python-object.html
[7] Please read first about privacy-breach-logo
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735321#10

Thank you for implementing the lintian checks and notifying maintainers
through bug reports.
I'm about to fix the one created against xbmc because I already planned
removing some other embedded but unused libraries anyway, but I would
like to suggest using the important severity as a start for such bugs.
Later the severity could be upgraded if there is no action on the maintainer's
side.

The rationale behind this proposal is that considering xbmc, source creates
a new 24MB source package and ~30MB of binary packages per architecture.
I expect more similar checks to be implemented and more bugs to be
opened against many packages.
Opening the bugs as important, thus not RC ones would allow maintainers
to collect more fixes to fewer package updates not having to worry about
automated removal of their packages from testing.

I agree that the detected issues are RC, and I also agree with the current
autoremoval procedure but IMO having more time to fix these issues
would allow using the project's resources and maintainters' time better.

Cheers,
Balint

--
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/CAK0OdpxETE1U11zEQu6sBfxXhmygYT9GYpu4a+NvzkRsMHo=u...@mail.gmail.com

1 2 >

1 - 100 of 132 matches

Mail list logo