Re: Changes to cia.navi.cx -> cia.vc
This one time, at band camp, Paul Wise said: > On Sun, Sep 9, 2012 at 7:39 AM, Dmitrijs Ledkovs wrote: > > > cia.navi.cx is deprecated, but now has stopped working. > > > > You should use cia.vc instead. > > > > Looking on vasks there are many team tooks that submit to cia.navi.cx > > (mail mail or RPC), please update those to use cia.vc. hostname > > instead. > > If the Alioth admins (CCed) want to fix this in all repositories, they > could just run this sed command that I pasted into #alioth on IRC a > while ago: > > sed -i -e 's/^\([^#]*\)cia\.navi\.cx/\1cia.vc/' /svn/*/hooks/*cia* There were only a few still using cia.navi.vc. Changed now. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Feature suggestion: TCP-FIT congestion control
On Sun, Sep 09, 2012 at 04:06:36AM +0400, a...@mvpro.net wrote: > I see, that Debian Wheezy comes with new congestion control named 'yeah', > it's rather good innovation, but by my tests TCP-Fit congestion control > should be the best for now. The question is not only one of finding the local optimum, but also how the chosen congestion control algorithm monopolizes the available bandwidth, hurting other users. (Yeah, that might make introducing new congestion control algorithms harder, but it's a solvable problem.) 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/20120909095313.ga10...@hub.kern.lc
Bug#687081: ITP: python-django-grappelli-safe -- admin interface enhancement for Django
Package: wnpp Severity: wishlist Owner: Per Andersson * Package name: python-django-grappelli-safe Version : 0.2.10+git20120907.89b0bde Upstream Author : Stephen McDonald * URL : http://github.com/stephenmcd/grappelli-safe/ * License : BSD Programming Lang: Python Description : admin interface enhancement for Django The Django admin interface is a powerful application in order to manage your website data. Grappelli adds a consistent and grid-based look & feel and some nifty features. . The fork grappelli_safe was created to provide a snapshot of the Grappelli to be used in conjunction with the Mezzanine Content Managament System for Django. -- 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/20120909115405.17570.10883.report...@pong.oshw.org
Re: Changes to cia.navi.cx -> cia.vc
On Sun, Sep 9, 2012 at 4:11 PM, Stephen Gran wrote: > There were only a few still using cia.navi.vc. Changed now. Excellent, thanks! -- 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/caktje6gjzy7_4zmsaxp3nzoe4-ukfpnhah-1eid+bzqqmp0...@mail.gmail.com
Re: greater popularity of Debian on AMD64?
On Sat, 2012-09-08 at 22:46 -0300, Henrique de Moraes Holschuh wrote: > On Sun, 09 Sep 2012, Russell Coker wrote: > > On Sat, 8 Sep 2012, Henrique de Moraes Holschuh wrote: > > > If "64-bit PC" is too vague, the alternative designator for the amd64 arch > > > is the vendor neutral "x86-64". The vendor-neutral designator for all of > > > i386, i486, i586, i686, amd64 and x32 is "x86" (i.e. it is for both 32-bit > > > and 64-bit). i286, i186 and 8086 are too old to bother with :-) > > > > Why should we be vendor-neutral? AMD invented the AMD64 instruction set. > > > > Intel invented the 386 instruction set and we call it i386. > > > > Why be vendor-neutral for things that AMD invents when we aren't vendor- > > neutral for things that Intel invents? > > I don't know, and I don't care either way. I am fine with amd64. > > But I object to "32-bit PC" and "64-bit PC". i686, amd64, x86-32, x86-64... > at least those are correct. But none of them are widely understood. > 32-bit PC and 64-bit PC mean nothing, I think a lot more people know which of those they have. > and it will make the mess worse when we start shipping x32. If, not when, x32 is in the archive, it can only be a partial architecture, and will be of no interest to the regular Debian user. So I don't expect any mess there. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Re: greater popularity of Debian on AMD64?
On Sun, 09 Sep 2012, Ben Hutchings wrote: > On Sat, 2012-09-08 at 22:46 -0300, Henrique de Moraes Holschuh wrote: > > On Sun, 09 Sep 2012, Russell Coker wrote: > > > On Sat, 8 Sep 2012, Henrique de Moraes Holschuh wrote: > > > > If "64-bit PC" is too vague, the alternative designator for the amd64 > > > > arch > > > > is the vendor neutral "x86-64". The vendor-neutral designator for all > > > > of > > > > i386, i486, i586, i686, amd64 and x32 is "x86" (i.e. it is for both > > > > 32-bit > > > > and 64-bit). i286, i186 and 8086 are too old to bother with :-) > > > > > > Why should we be vendor-neutral? AMD invented the AMD64 instruction set. > > > > > > Intel invented the 386 instruction set and we call it i386. > > > > > > Why be vendor-neutral for things that AMD invents when we aren't vendor- > > > neutral for things that Intel invents? > > > > I don't know, and I don't care either way. I am fine with amd64. > > > > But I object to "32-bit PC" and "64-bit PC". i686, amd64, x86-32, x86-64... > > at least those are correct. > > But none of them are widely understood. > > > 32-bit PC and 64-bit PC mean nothing, > > I think a lot more people know which of those they have. Yeah, and it can be fixed by "32-bit PC (i386/i686)" and 64-bit PC (amd64/x86-64)". > > and it will make the mess worse when we start shipping x32. > > If, not when, x32 is in the archive, it can only be a partial > architecture, and will be of no interest to the regular Debian user. So > I don't expect any mess there. I hope you're right. And yes, x32 as a partial arch would be fine. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120909152547.ga23...@khazad-dum.debian.net
Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: maps Version : 12.07.4 Upstream Author : Sigurd Gartmann * URL : https://launchpad.net/maps * License : GPL Programming Lang: Python Description : OpenStreetMap client for the GNOME Desktop This application uses Mapquest for search and directions search, the open API using Openstreetmap data and not requiring an API key. Maps are standard tiles from OpenStreetMap. . It will also show GPX tracks if dragged to an open program. . When viewing results, in most cases a single click in the result listing will highlight the result. For searches, a double click will save the location to 'My places'. During directions search, a double click in the results will set proper locations to be able to search for directions. -- 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/20120909172157.8469.43561.reportbug@Aspire-1410
Bug#687104: ITP: libjs-uploadify -- JavaScript library for file upload
Package: wnpp Severity: wishlist Owner: Per Andersson * Package name: libjs-uploadify Version : 3.2+dfsg Upstream Author : Reactive Apps, Ronnie Garcia * URL : http://uploadify.com/ * License : MIT Programming Lang: JavaScript, Flash Description : JavaScript library for file upload Uploadify is a jQuery plugin that allows you to easily add multiple file upload functionality to your website. . Features: * Multiple file uploads * Drag and drop * Real-time progress indicators * Custom upload restrictions * Extreme customization . This package contains the Flash version of Uploadify. -- 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/20120909171218.10140.71397.report...@pong.oshw.org
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Sun, 09 Sep 2012 19:21:57 +0200, Alessio Treglia wrote: > Package: wnpp > Severity: wishlist > Owner: Alessio Treglia > > * Package name: maps It would be nice if you could use a less generic name. :) Thanks, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Sun, Sep 9, 2012 at 7:39 PM, David Paleino wrote: > It would be nice if you could use a less generic name. :) Honestly, I've been thinking about that even before you raised your objection :-) Any suggestions? Would 'maps-client' be a good name? -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- 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/CAMHuwowWjXYsrFA=SvDP6Nn4UgNr6ZnN=wanxisput+przx...@mail.gmail.com
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On 09/09/2012 19:54, Alessio Treglia wrote: > On Sun, Sep 9, 2012 at 7:39 PM, David Paleino wrote: >> It would be nice if you could use a less generic name. :) > > Honestly, I've been thinking about that even before you raised your > objection :-) > > Any suggestions? Would 'maps-client' be a good name? > gnome-maps ? Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Sun, Sep 9, 2012 at 8:09 PM, Jean-Christophe Dubacq wrote: > gnome-maps ? I'd avoid gnome-maps, as upstream != GNOME -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- 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/camhuwowir1zu-zfzbgvlon6fgsj6vyqzjrvo4ris1ns0w__...@mail.gmail.com
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
Hi there! On Sun, 09 Sep 2012 20:09:11 +0200, Jean-Christophe Dubacq wrote: > On 09/09/2012 19:54, Alessio Treglia wrote: >> On Sun, Sep 9, 2012 at 7:39 PM, David Paleino wrote: >>> It would be nice if you could use a less generic name. :) >> >> Honestly, I've been thinking about that even before you raised your >> objection :-) >> >> Any suggestions? Would 'maps-client' be a good name? >> > gnome-maps ? Or, if this is tightened to OSM, 'gnome-osm-maps'. Thx, bye, Gismo / Luca pgpJnDupmL4ea.pgp Description: PGP signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On 09/09/2012 20:26, Alessio Treglia wrote: > On Sun, Sep 9, 2012 at 8:09 PM, Jean-Christophe Dubacq > wrote: >> gnome-maps ? > > I'd avoid gnome-maps, as upstream != GNOME > I am not a specialist, but it looks to me like p gnome-inm-forecast - the Spanish weather forecast applet for the GNOME Desktop whose homepage is http://kutxa.homeunix.org/trac/gnome-inm-forecast is official gnome either. (I picked this one among others; I have no grudge against that package, nor against any package using the gnome- namespace whose upstream is not GNOME). Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On 09/09/2012 20:48, Jean-Christophe Dubacq wrote: > I am not a specialist, but it looks to me that > p gnome-inm-forecast - the Spanish weather forecast > applet for the GNOME Desktop > > whose homepage is http://kutxa.homeunix.org/trac/gnome-inm-forecast > > is official gnome either. is *not*, of course. Sorry for the noise, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
OK, so let's go on picking 'gnome-osm-maps'. Thank you all folks! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- 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/camhuwowjkkkqokq9to3wbeln7ppug7r20t0fwnss4vgym8m...@mail.gmail.com
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On 12-09-09 at 08:09pm, Jean-Christophe Dubacq wrote: > On 09/09/2012 19:54, Alessio Treglia wrote: > > On Sun, Sep 9, 2012 at 7:39 PM, David Paleino wrote: > >> It would be nice if you could use a less generic name. :) > > > > Honestly, I've been thinking about that even before you raised your > > objection :-) > > > > Any suggestions? Would 'maps-client' be a good name? > > > gnome-maps ? maps-gtk (similar to evince-gtk) Even if the author calls it GNOME, it seems linking only against GTK+ libraries and thus usetul also for those (like me) actively avoiding the bloat of GNOME libraries. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: greater popularity of Debian on AMD64?
On 9 September 2012 16:49, Ben Hutchings wrote: > On Sat, 2012-09-08 at 22:46 -0300, Henrique de Moraes Holschuh wrote: >> But I object to "32-bit PC" and "64-bit PC". i686, amd64, x86-32, x86-64... >> at least those are correct. > > But none of them are widely understood. But they are googleable, whereas "32-bit PC" matches stuff not directly relevant. >> 32-bit PC and 64-bit PC mean nothing, > > I think a lot more people know which of those they have. Do they, I wonder? Anyway, while it seems a nice idea to try and collapse the entire distinction between the two architectures into a single number, I'm not really sure who is helped here. The current architecture names are well established, also outside Debian. They're everywhere, in the output of gcc, packages names, library names, etc. Then there's the assumption that no other architecture can be a PC? I'd say, a single unambiguous label is better than a vague label for marketing purposes. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ -- 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/cadwg95t+5gfrivw4-+crk04cqwyanl9vkpcyxcy5sbpvhxj...@mail.gmail.com
Re: Files-Excluded field and security implications of uscan and debian/copyright.
On Fri, Sep 07, 2012 at 03:15:27PM +0100, Ian Jackson wrote:
> Charles Plessy writes ("Re: Files-Excluded field and security implications of
> uscan and debian/copyright."):
> > Le Fri, Sep 07, 2012 at 08:44:36AM +0900, Charles Plessy a écrit :
> > > in the case of the Files-Excluded field, the contents of the field
> > > are directly executed.
> >
> > I mean: the contents are transferred to an expression that is
> > directly executed.
>
> This is a bug in the implementations that do that, surely ?
???
I would love to get a pointer to the actual line[1] which executes
content from debian/copyright. TTBOMK, all expressions are part of the
seeking string of a find statement, nothing more.
Kind regards
Andreas.
[1]
http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl;hb=HEAD
--
http://fam-tille.de
--
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/20120909210444.gb3...@an3as.eu
Re: greater popularity of Debian on AMD64?
On Sun, 2012-09-09 at 23:06 +0200, Martijn van Oosterhout wrote: > On 9 September 2012 16:49, Ben Hutchings wrote: > > On Sat, 2012-09-08 at 22:46 -0300, Henrique de Moraes Holschuh wrote: > >> But I object to "32-bit PC" and "64-bit PC". i686, amd64, x86-32, > >> x86-64... > >> at least those are correct. > > > > But none of them are widely understood. > > But they are googleable, whereas "32-bit PC" matches stuff not > directly relevant. I don't suggest to remove the dpkg architecture names from documentation; that really would be unhelpful. In some places it would be appropriate to use both. But press material and introductory material shouldn't assume familiarity with those names. > >> 32-bit PC and 64-bit PC mean nothing, > > > > I think a lot more people know which of those they have. > > Do they, I wonder? Anyway, while it seems a nice idea to try and > collapse the entire distinction between the two architectures into a > single number, I'm not really sure who is helped here. See #575760. > The current > architecture names are well established, also outside Debian. They're > everywhere, in the output of gcc, packages names, library names, etc. There are many alternate strings used: amd64/x86_64/x64 and i386/i486/i586/i686/x86_32/x86. > Then there's the assumption that no other architecture can be a PC? 'PC' long since ceased to mean 'personal computer'. Servers with x86 processors are called 'PC servers' while personal computers with cellular networking are called 'smartphones'. > I'd say, a single unambiguous label is better than a vague label for > marketing purposes. Ambiguity depends on the context and knowledge of the recipients. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Towards d-i wheezy beta 3
Hello, tiny wrap-up for beta 2: the release happened one week after the prospective date. Some tiny delays on various fronts added up and explain that, but the overall results don't seem too bad to me. That's why I'm going to propose the same timing for beta 3: 3 weeks for development and bug fixes (let's call it a “merge window”), 1 week for dealing with udeb-related unblock requests, building/testing images and preparing release announcement. The FTP Team Sprint is scheduled 2012-09-14 → 2012-09-21, but that should still leave enough time for development. Dates would be: 2012/09/29-30: d-i wheezy beta 3 merge window closes. 2012/10/06-07: d-i wheezy beta 3 is released. Features expected to be merged: - UEFI support (Steve). Before anyone asks, and as far as I can tell: it's not about supporting secure boot. - IPv6 support in d-i (Philipp). - Possibly more xz-related unblocks (Ansgar). If anybody wants to see something land into this release, it would be nice to mention it now instead of after the end of the merge window. Mraw, KiBi. signature.asc Description: Digital signature
Re: Towards d-i wheezy beta 3
Cyril Brulebois, le Mon 10 Sep 2012 00:07:46 +0200, a écrit : > Features expected to be merged: > - UEFI support (Steve). Before anyone asks, and as far as I can tell: >it's not about supporting secure boot. > - IPv6 support in d-i (Philipp). > - Possibly more xz-related unblocks (Ansgar). > > If anybody wants to see something land into this release, it would be > nice to mention it now instead of after the end of the merge window. I'd like to merge the console font switch support for wider speech language support. Samuel -- 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/20120909221049.gi5...@type.wlan.youpi.perso.aquilenet.fr
Bug#687118: ITP: python-django-filebrowser-safe -- asset manager for Django
Package: wnpp Severity: wishlist Owner: Per Andersson * Package name: python-django-filebrowser-safe Version : 0.2.12+dfsg Upstream Author : Stephen McDonald * URL : http://github.com/stephenmcd/filebrowser-safe/ * License : BSD Programming Lang: Python, JavaScript Description : asset manager for Django The FileBrowser is an extension to the Django administration interface which adds the following functionality: * browse directories on your server and upload/delete/edit/rename files * include images/documents to your models/databes using the FileBrowseField * select images/documents with TinyMCE . The fork filebrowser_safe was created to provide a snapshot of FileBrowser to be used by Mezzanine Content Management System. -- 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/20120909214817.32151.89087.report...@pong.oshw.org
Re: Files-Excluded field and security implications of uscan and debian/copyright.
Le Sun, Sep 09, 2012 at 11:04:44PM +0200, Andreas Tille a écrit :
> On Fri, Sep 07, 2012 at 03:15:27PM +0100, Ian Jackson wrote:
> > Charles Plessy writes ("Re: Files-Excluded field and security implications
> > of uscan and debian/copyright."):
> > > Le Fri, Sep 07, 2012 at 08:44:36AM +0900, Charles Plessy a écrit :
> > > > in the case of the Files-Excluded field, the contents of the field
> > > > are directly executed.
> > >
> > > I mean: the contents are transferred to an expression that is
> > > directly executed.
> >
> > This is a bug in the implementations that do that, surely ?
>
> ???
>
> I would love to get a pointer to the actual line[1] which executes
> content from debian/copyright. TTBOMK, all expressions are part of the
> seeking string of a find statement, nothing more.
Hi Andreas,
the find commands are executed via backsticks, which potentially can execute
any arbitrary command. I personally have not found a way to exploit this (*),
but given my lack of training in the field, I do not consider this significant,
so I asked for others opinions.
My main question anyway is whether it would be useful to make a distinction
between fields that have a content that is more likely to be passed to shell
commands, and fields where the content is less likely to be so.
(*) Yes I looked, and maybe the most straightforward way would be to make a
fake file name containing backsticks, in order to execute a helper script in the
debian directory.
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/20120909232043.ga32...@falafel.plessy.net
Re: Towards d-i wheezy beta 3
On Mon, 10 Sep 2012, Cyril Brulebois wrote: > Features expected to be merged: > - UEFI support (Steve). Before anyone asks, and as far as I can tell: >it's not about supporting secure boot. > - IPv6 support in d-i (Philipp). > - Possibly more xz-related unblocks (Ansgar). > > If anybody wants to see something land into this release, it would be > nice to mention it now instead of after the end of the merge window. I'd like to see it recommend the instalation of (or just install by default) system processor microcode update packages when non-free is enabled on a x86 arch (i386 or amd64) and the running processor is either Intel or AMD (easily identified by a grep in /proc/cpuinfo). I'm willing to help write and test this, but I need a few pointers. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120909233838.ga...@khazad-dum.debian.net
Re: let uscan exclude some upstream files (Was: uscan enhancement)
On Thu, Sep 06, 2012 at 10:34:38PM +0200, Andreas Tille wrote: > It specifies: > > Files-Excluded: > __MACOSX > [a-z]*.jar > > with the purpose to save ReadSeq.jar inside the source package. This > works with the old method: > > $ find . -name "[a-z]*.jar" > ./rdp_classifier_2.5/lib/junit.jar > ./rdp_classifier_2.5/lib/commons-cli.jar > ./rdp_classifier_2.5/rdp_classifier-2.5.jar > > but failes when trying your patch: > > $ find . -path "./[a-z]*.jar" > ./rdp_classifier_2.5/lib/junit.jar > ./rdp_classifier_2.5/lib/commons-cli.jar > ./rdp_classifier_2.5/lib/ReadSeq.jar > ./rdp_classifier_2.5/rdp_classifier-2.5.jar > I admit I did also not followed the DEP5 discussion very closely but the > current code could deal nicely with the specific removal which is not > the case with your proposal and I have no clue how to reasonably specify > the fact that all *.jars except one should be removed (besides > specifying every single file). I realize that http://dep.debian.net/deps/dep5/ is now obsolete. Here is the current version. -- http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field This is the same pattern syntax as fnmatch(3) without the FNM_PATHNAME flag, or the argument to the -path test of the GNU find command, except that [] wildcards are not recognized. Multiple Files paragraphs are allowed. The last paragraph that matches a particular file applies to it. More general paragraphs should therefore be given first, followed by more specific overrides. Exclusions are only supported by adding Files paragraphs to override the previous match. -- So, my patch is more conformant than the old method. Moreover, brackets should be escaped before passing them to find. For the moment, only one Files-Excluded is allowed in the unique header paragraph [2]. Exclusions are impossible. Maybe a solution would be to define a fake "not-shipped-by-debian" license instead. This would not only solve your problem, but also allow per-file-set comments as discussed before ([1], [2]), and using unchanged existing parsers. Your example would become: -- debian/copyright Files: * License: GPL3+ Full license text. Files: __MACOSX License: not-shipped-by-debian Optionaly explain here why __MACOSX is rejected. Files: *.jar License: not-shipped-by-debian Optionaly explain here why jar files are rejected. Files: rdp_classifier_2.5/lib/ReadSeq.jar License: GPL3+ Full license text. -- (excluded pattern are separated to demonstrate per-file-set comments) (in real life, "Text of GPL3+" would be in a separate paragraph) Allthough I agree with [5], in case we decide to put these patterns into a separate file or into debian/watch options, a similar approach could be used, like: -- debian/uscan-excluded-files Exclude: __MACOSX *.jar Include: rdp_classifier_2.5/lib/ReadSeq.jar -- [1] https://lists.debian.org/debian-devel/2012/08/msg00625.html [2] https://lists.debian.org/debian-devel/2012/08/msg00699.html [5] https://lists.debian.org/debian-devel/2012/08/msg00620.html -- 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/20120910013530.GA22092@pegase
Re: greater popularity of Debian on AMD64?
On Sun, Sep 09, 2012 at 11:06:17PM +0200, Martijn van Oosterhout wrote: > >> 32-bit PC and 64-bit PC mean nothing, > > > > I think a lot more people know which of those they have. > > Do they, I wonder? Anyway, while it seems a nice idea to try and No, they do not. -- 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/20120910014153.ga24...@scru.org
RE: CD1 without a network mirror isn't sufficient to install a full desktop environment
Just a quick suggestion. As a compromise, instead of enabling Xfce as the "universal default" in tasksel *entirely* ... How about only enabling Xfce as default for the CD* distribution, and leaving the default as GNOME for all non-CD distributions? (DVD, netinst, ...) That will express true "bipartisanism" ... instead of explicitly being biased towards one direction or another simply at the whim of (a) certain decision maker(s), especially over a technicality. Yes, you can argue this might incur a "split" between install bases and, thus, possibly be less "easy" to support ... But both GNOME and Xfce are officially integrated into Debian, and so should both be considered equally ... GNOME has a longer-standing status, specifically with Debian, and other GNU/Linux distributions at large. It's also an officially-supported GNU project, as well as being more "authoritative", in the sense that it's the base of GTK+ which is utilized by Xfce. According to popcon, Xfce is more common on Debian than GNOME... And considering the recent controversy surrounding v3, many have opted for alternatives such as Xfce, MATE, Cinnamon, Unity, or etc... I, personally, feel as if GNOME is sort of going the "KDE path" as far as becoming somewhat bloated. Xfce's lightweight-focused approach can be appreciable, but modern high-level functionality shouldn't necessarily be compromised by lack-of/restricted resources. Simply the fact that it's an OPTION is terrific. But, from the premise of this entire letter, shouldn't exactly be *forced*. Thus, I reiterate that it might be a good idea to maybe consider the possibility of thinking about the potential for ... Xfce being set to default tasksel in CD* distributions, while GNOME remaining default in others. At *least* as a compromise during a ``transitional'' period, whereupon the eventuality of settling on a single/unified default may come into play yet once again. :D
Re: Towards d-i wheezy beta 3
On 10 September 2012 06:07, Cyril Brulebois wrote: > If anybody wants to see something land into this release, it would be > nice to mention it now instead of after the end of the merge window. Is there potential to see pkgsel use apt-get instead of aptitude (following the same change in tasksel)? There is already a patch committed. I'll give this more of a test this week with some induced errors during the installation. Can also add --fix-missing to make apt-get more robust, but I personally don't think that is a good idea. Regards -- 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/CAN3veRejAOyCvyZ72aDtESJ3a47RcTjYyoWtsvQ15_m=u9q...@mail.gmail.com
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
also sprach Luca Capello [2012.09.09.2029 +0200]: > Or, if this is tightened to OSM, 'gnome-osm-maps'. except the 'm' on "osm" is already a "map", so maybe osm-client. -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems now I lay me back to sleep. the speaker's dull; the subject's deep. if he should stop before I wake, give me a nudge for goodness' sake. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
volume control not working:debian 6.0.4
Hi, I have ported Debian for my target x86 board,and facing some problem in volume-control when i click on it's icon I am getting error: "The volume control did not find any elements and/or devices to control. This means either that you don't have the right GStreamer plugins installed, or that you don't have a sound card configured. You can remove the volume control from the panel by right-clicking the speaker icon on the panel and selecting "Remove From Panel" from the menu." although if i play any media file through rythmbox music player or movie player it plays audio... please help me also,to access audio i need to add user in audio group (/etc/group). Regards.
support request (Re: volume control not working:debian 6.0.4)
On Mon, Sep 10, 2012 at 11:12:32AM +0530, magina antimage wrote: > please help me I'm afraid that the debian-devel list is not meant for support. If you believe you have found a bug, then feel free to report a bug. http://bugs.debian.org/ If you need support, then please see this link : http://www.debian.org/support Regards, Bart Martens -- 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/20120910054854.ga1...@master.debian.org
Re: Towards d-i wheezy beta 3
Quoting Daniel Hartwig (mand...@gmail.com): > Is there potential to see pkgsel use apt-get instead of aptitude > (following the same change in tasksel)? There is already a patch > committed. I'll give this more of a test this week with some induced > errors during the installation. I hesitated for beta2 then finally didn't upload after talking with Cyril. But it's probably the good moment to do this.if you can make wider testing than I did (which was a base system install and a quick install of a desktop system, the latter without comparing the list of installed packages). signature.asc Description: Digital signature
