[Email blocked, contains executable attachment] [Virus email-worm:w32/mydoom.gen!a] Returned mail: see transcript for details
This message and the file attached to the message, was NOT sent to the recipient, because it contains an "Executable Attachment" file type that is currently being blocked. A copy was also sent to the Quarantine folder “EXEstrip”. Subject: [Virus email-worm:w32/mydoom.gen!a] Returned mail: see transcript for details Recipient: reghunthan.subh...@metlifealico.com Date: 2013-09-04 - 05:42:06 Please contact local helpdesk for support. Alico Security -- 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/mailbox-22053-1378273326-202938@defrapp
Bug#721800: ITP: r-bioc-biostrings -- GNU R string objects representing biological sequences
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-biostrings Versioy : 2.28.0 Upstream Author : H. Pages * URL : http://bioconductor.org/packages/2.12/bioc/html/biostrings.html * License : Artistic-2.0 Programming Lang: R Description : GNU R string objects representing biological sequences Memory efficient string containers, string matching algorithms, and other utilities, for fast manipulation of large biological sequences or set of sequences. This package belongs to a serious of BioC preconditions for new version of r-cran-cummerbund and is maintained by Debian Med team in svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-biostrings/trunk/ -- 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/20130904073921.18674.28313.report...@mail.an3as.eu
Bug#721801: ITP: r-bioc-genomicranges -- BioConductor representation and manipulation of genomic intervals
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-genomicranges Version : 1.12.4 Upstream Author : P. Aboyoun * URL : http://bioconductor.org/packages/2.12/bioc/html/genomicranges.html * License : Artistic-2.0 Programming Lang: R Description : BioConductor representation and manipulation of genomic intervals The ability to efficiently store genomic annotations and alignments is playing a central role when it comes to analyze high-throughput sequencing data (a.k.a. NGS data). The package defines general purpose containers for storing genomic intervals as well as more specialized containers for storing alignments against a reference genome. Another precondition for new version of r-cran-cummerbund maintained in svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-genomicranges/trunk/ -- 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/20130904074528.18828.52260.report...@mail.an3as.eu
Bug#721806: ITP: r-bioc-affy -- BioConductor methods for Affymetrix Oligonucleotide Arrays
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-affy Version : 1.38.1 Upstream Author : Rafael A. Irizarry * URL : http://bioconductor.org/packages/2.12/bioc/html/affy.html * License : Artistic-2.0 Programming Lang: R Description : BioConductor methods for Affymetrix Oligonucleotide Arrays This is part of the BioCOnductir GNU R suite. The package contains functions for exploratory oligonucleotide array analysis. As previous ITPs this is part of preconditions for r-bioc-cummerbund and prepared ind SVN: svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-affy/trunk/ -- 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/20130904085042.20679.90659.report...@mail.an3as.eu
Bug#721807: ITP: rateit -- Tool for performing MUSHRA tests
Package: wnpp Severity: wishlist Owner: Marius Gavrilescu * Package name: rateit Version : 0.1 Upstream Author : Jean-Marc Valin * URL : http://rateit.sourceforge.net/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: C Description : Tool for performing MUSHRA tests RateIt is a GUI tool for performing subjective testing of audio samples based on the MUltiple Stimuli with Hidden Reference and Anchor (MUSHRA) methodology as specified in ITU-R recommendation BS.1534-1. -- Marius Gavrilescu signature.asc Description: Digital signature
Re: Looking for ideas for merging a micro package...
Am Dienstag, den 03.09.2013, 22:18 -0700 schrieb Russ Allbery: > tony mancill writes: > > > Thank you for pointing this out. I just recently uploaded a script, > > splitpatch, that I argued should be accepted as-is (i.e. as a "micro > > package") because of the dependency on ruby. > > > Given that ruby is becoming more popular for scripting, what do folks > > think about a catch-all package for ruby scripts? I don't have a good > > feel for what the right trade-off is between: > > > * reducing load on the archive by consolidating these tiny packages > > > * making good use of maintainer's time, the implication being that > > coordinating multiple (otherwise unrelated?) ruby scripts is going to be > > more of a time commitment for the maintainer(s) > > > and > > > * making it easy (or even possible) for users to find these scripts when > > the package name doesn't match upstream > > I think it makes a ton of sense to have several of these catch-all > packages split by implementation language. The biggest advantage is to > the maintenance of the catch-all package; most of us only consider > ourselves highly experienced in, or comfortable in, one or two languages, > and therefore it's harder to find maintainers who are comfortable with > packages that mix a bunch of languages. It's also helpful to be tied in > to the maintenance community for that language to weigh things like good > modules to rely on or not rely on, how burdensome dependencies are, etc. > There's also a minor advantage for the user who may not want to introduce > a whole new interpreter to systems that are tight on space or that need to > be kept simple. > > A moreutils-ruby (or some similar name) seems like a great idea to me. > > I would check with Joey first, though, just in case he disagrees with that > reasoning and would prefer to include the scripts directly in moreutils. > > (splitpatch might make more sense in devscripts, but devscripts I think > has the same set of constraints, albeit with different base languages. > Python and Perl at the moment, I think.) devscript had only Perl and Shell scripts initially, but then gained Python scripts. I don't see any reason to not accept ruby script. ruby would pull in another ~ 13 MB of storage, but devscripts targets developer machines. -- Benjamin Drung Debian & Ubuntu Developer -- 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/1378285972.3306.3.camel@deep-thought
Re: to those who want to support Debian longer...
Hi Moritz, On Do 29 Aug 2013 19:25:57 CEST Moritz Mühlenhoff wrote: Indeed, actions speak louder than words. Here's four specific packages, where the security team could need some help for an oldstable-security update: [...] - Several Drupal 6 fixes need to be backported [...] I can help with this in case the current maintainer (Luigi) is unable to. Can you be more explicit (probably off-list off d-devel) what you have in mind for drupal6 security patching? Thanks, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpmyUfQKmzO2.pgp Description: Digitale PGP-Unterschrift
Bug#508644: Sorting out mail-transport-agent mess
Package: general Followup-For: Bug #508644 Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20130904094355.19034.42831.report...@t430.radi8.net
Re: to those who want to support Debian longer...
On 08/29/2013 07:18 PM, Holger Levsen wrote: > Hi, > > please start with helping supporting the current stable release better: > > http://udd.debian.org/bugs.cgi?release=wheezy&rc=1 shows 255 RC bugs in > wheezy, just four months after this counter was basically at zero. Hi, As much as I would like to have this number of problem go down, this has nothing to do with *security* support of the very-old-stable distro as we discussed. Besides this, the plan is to support *some* of the very-old-stable for security, and to only track problems for the packages which nobody cares. At least *I* do not intend to support absolutely all of the packages. For example, taking examples from your list, if we were talking about Squeeze EOL, I wouldn't care about python-pip and python-virtualenv, though I could care more about other python modules which I would use in production (no example here, sorry). That being said, I also would like to highlight the fact that it's quite difficult to convince the release team that all of these bugs needs to be fixed. For example (on one of my packages, so please don't use a stick to beat me on it, and stick to the current discussion), see #710507. I have made a fix for it, as well as many others in the same source package, but no reply from the release team for more than 20 days (see #719632 for the p-u discussion). I don't think this is an isolated case. Though that's annoying that it is stalled, because there's a CVE included in the list of fixes. I'm in no way complaining about the release team. I know they are busy, that they try to minimize problems introduced by changes, and that peer review takes a lot of time. Though the fact is, because of it, some people (not including myself) have completely (and understandably) given up updating stable, and the list of bug you see there could be partly due to it. I'm not sure what is the way forward. On one side, relaxing the rules to get fixes in could be dangerous, and on the other hand, blocking fixes isn't nice. I'd vote for a bit more relaxed policy, but I would understand anyone thinking otherwise. Cheers, Thomas P.S: Also (and with all due respect I have for someone like you, Holger) please avoid pointing fingers at a group of people that have the will to do things. This is counter productive. -- 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/52270549.8070...@debian.org
Re: Replacing a binary package by another one(was: Communication issue?)
On 04/09/13 at 12:13 +0900, Norbert Preining wrote: > On Mi, 04 Sep 2013, Ben Hutchings wrote: > > How much do those packages weigh, Norbert? Are TeX transitional > > packages particularly heavy? > > In kg? In bit? In work time? > > > I really don't know why you think TeX is exempt from the usual > > requirements to support clean upgrades between Debian releases. > > Please try it before complaining. Clean upgrades are working with > dist-upgrade I tried: - in wheezy, install texlive-lang-danish - change sources.list to point to sid - apt-get update ; apt-get dist-upgrade - texlive-lang-danish gets removed (as well as texlive-common and texlive-doc-base), but texlive-lang-european doesn't get installed. You need transitional packages here. Lucas -- 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/20130904105800.ga28...@xanadu.blop.info
Re: Replacing a binary package by another one(was: Communication issue?)
On Mi, 04 Sep 2013, Lucas Nussbaum wrote: > > > requirements to support clean upgrades between Debian releases. > - texlive-lang-danish gets removed (as well as texlive-common > and texlive-doc-base), but texlive-lang-european doesn't get > installed. Yes, and? Was the dist-upgrade disturbed? We are talking about normal systems, that is having telxive or texlive-full installed. Not pathological cases of only t-l-d installed. > You need transitional packages here. I *can* provide transitional packages to make it nice for the user experience. I don't remember a requirement in the Debian policy for that. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- 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/20130904110416.gc12...@gamma.logic.tuwien.ac.at
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
Hi, On Mittwoch, 4. September 2013, Norbert Preining wrote: > Yes, and? Was the dist-upgrade disturbed? > We are talking about normal systems, that is having telxive or texlive-full > installed. Not pathological cases of only t-l-d installed. wheezy has: Package: texlive-lang Binary: texlive-lang-african, texlive-lang-arabic, texlive-lang-armenian, texlive-lang-cjk, texlive-lang-croatian, texlive-lang-cyrillic, texlive-lang- czechslovak, texlive-lang-danish, texlive-lang-dutch, texlive-lang-finnish, texlive-lang-french, texlive-lang-german, texlive-lang-greek, texlive-lang- hebrew, texlive-lang-hungarian, texlive-lang-indic, texlive-lang-italian, texlive-lang-latin, texlive-lang-latvian, texlive-lang-lithuanian, texlive- lang-mongolian, texlive-lang-norwegian, texlive-lang-other, texlive-lang- polish, texlive-lang-portuguese, texlive-lang-spanish, texlive-lang-swedish, texlive-lang-tibetan, texlive-lang-english, texlive-lang-vietnamese, texlive- lang-all, ptex-bin sid has: Package: texlive-lang Binary: texlive-lang-african, texlive-lang-arabic, texlive-lang-cjk, texlive- lang-cyrillic, texlive-lang-czechslovak, texlive-lang-english, texlive-lang- european, texlive-lang-french, texlive-lang-german, texlive-lang-greek, texlive-lang-indic, texlive-lang-italian, texlive-lang-other, texlive-lang- polish, texlive-lang-portuguese, texlive-lang-spanish, texlive-lang-all, ptex- bin, thailatex which other binary packages build by texlive-lang do you consider "pathological to use"? > I *can* provide transitional packages to make it nice for the user > experience. I don't remember a requirement in the Debian policy for that. #569219 and #323066 suggest this is a best practice for years. https://wiki.debian.org/PackageTransition might be helpful too. cheers, Holger, who considers just to build-depend on texlive-lang-all | and be done with this signature.asc Description: This is a digitally signed message part.
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Mi, 04 Sep 2013, Holger Levsen wrote: > which other binary packages build by texlive-lang do you consider > "pathological to use"? I considered the installation of one -lang package by itself without actual latex package pathological. > Holger, who considers just to build-depend on texlive-lang-all | and be > > done with this Since TL2005 that is nearly 8 years ago we practiuically haven't change anything in the naming. And now that there are a few changes ... sudenly the world collapses. Ohh, I have to be careful otherwise Ian comes agian after me threatening me with consequences ... soo scary. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- 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/20130904115204.ga14...@gamma.logic.tuwien.ac.at
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On 04/09/13 at 20:52 +0900, Norbert Preining wrote: > On Mi, 04 Sep 2013, Holger Levsen wrote: > > which other binary packages build by texlive-lang do you consider > > "pathological to use"? > > I considered the installation of one -lang package by itself without > actual latex package pathological. OK, let's try again: - in wheezy, install texlive and texlive-lang-dutch - dist-upgrade to sid: texlive-lang-dutch is removed, texlive-lang-european is not installed That's wrong. > > Holger, who considers just to build-depend on texlive-lang-all | and be > > > > done with this > > Since TL2005 that is nearly 8 years ago we practiuically haven't change > anything in the naming. > > And now that there are a few changes ... sudenly the world collapses. It's not about world collapse. It's about doing upgrades without removing functionality when it's possible, which is something we care about in Debian AFAIK. Why should texlive be different? Lucas -- 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/20130904121047.ga6...@xanadu.blop.info
Bug#721831: ITP: python-sockjs-tornado -- server side counterpart of SockJS-client browser library
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-sockjs-tornado Version : 1.0.0 Upstream Author : Serge S. Koval * URL : https://github.com/mrjoes/sockjs-tornado * License : MIT Programming Lang: Python Description : server side counterpart of SockJS-client browser library SockJS-tornado is a Python server side counterpart of SockJS-client browser library running on top of Tornado framework. SockJS provides slightly different API than tornado.websocket. -- 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/20130904124944.10683.21665.report...@buzig.gplhost.com
Re: Looking for ideas for merging a micro package...
Benjamin Drung debian.org> writes: > devscript had only Perl and Shell scripts initially, but then gained > Python scripts. I don't see any reason to not accept ruby script. ruby > would pull in another ~ 13 MB of storage, but devscripts targets > developer machines. I absolutely do not want to see anything related to ruby on my systems. And the people I know who are ruby fanboys always tell to *uninstall* the packaged ruby anyway and install it via this ugly curl|sudo bash thingy *shudder* because apparently the packaged version troubles their ugly method. So both the ruby haters and the ruby fanboys will not like this. I’d not mind having a source package (like moreutils) generate multiple binary packages, one of which would contain the ruby… stuff. As long as it doesn’t get needed… In fact… there’s “micro” stuff written all the time; I’ve been approached about packaging scripts, several times, and rejected because waldi (my original sponsor) explained about the expensiveness of packages, especially binary packages. If we could make some sort of effort to collect them… (maybe as native package in collab-maint?) bye, //mirabilos -- 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/loom.20130904t15132...@post.gmane.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: flashproxy Version : 1.2 Upstream Author : David Fifield * URL : http://crypto.stanford.edu/flashproxy/ * License : MIT Programming Lang: Python, JavaScript, Go, Shell Description : ephemeral browser-based pluggable transport for Tor Flash proxies are a new way of providing access to a censorship circumvention system such as Tor. A flash proxy is a miniature proxy that runs in a web browser. It checks for clients that need access, then conveys data between them and a Tor relay. Tor has bridge relays, but in some cases even these can be blocked despite the fact that their addresses are handed out only a few at a time. The purpose of this project is to create many, generally ephemeral bridge IP addresses, with the goal of outpacing a censor's ability to block them. Rather than increasing the number of bridges at static addresses, we aim to make existing bridges reachable by a larger and changing pool of addresses. -- 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/20130904144428.5225.22272.reportbug@localhost.localdomain
Re: Replacing a binary package by another one(was: Communication issue?)
[Norbert Preining] > On Di, 03 Sep 2013, Peter Samuelson wrote: > > texlive-lang-european? It doesn't look like it to me (no Breaks or > > Conflicts), but I haven't actually tried it. > > conflicts there are, texlive-base conflicts with all the old packages. I misspoke. There is a Conflicts in texlive-base, but what is probably needed is Provides in texlive-lang-european. As I understand it, that will prompt apt to DTRT on upgrade. Since nobody is worried about versioned dependencies here, I think that would suffice. No need for 30 transitional packages. But I haven't tested it. -- 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/20130904175546.ge6...@p12n.org
Re: Looking for ideas for merging a micro package...
[Thorsten Glaser] > I absolutely do not want to see anything related to ruby on my > systems. Why? Is this just an emotional reaction, or is it the 13 MB of dependencies, or something else? I wonder if anyone feels the same way about, say, libraries written in FORTRAN, or binaries linked against libX11. -- 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/20130904180235.gf6...@p12n.org
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
clone 709758 -1
reassign -1 src:texlive-lang
retitle -1 Transitional packages for going-away texlive-lang-*
thanks
I'm cloning the original bug report to make a new report for this
issue as described by Lucas:
Lucas Nussbaum writes ("Re: Bug#709758: Replacing a binary package by another
one(was: Communication issue?)"):
> OK, let's try again:
> - in wheezy, install texlive and texlive-lang-dutch
> - dist-upgrade to sid: texlive-lang-dutch is removed, texlive-lang-european
> is not installed
> That's wrong.
Thanks,
Ian.
--
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/21031.15009.165271.106...@chiark.greenend.org.uk
Re: Replacing a binary package by another one(was: Communication issue?)
On Wed, Sep 04, 2013 at 12:55:46PM -0500, Peter Samuelson wrote: > [Norbert Preining] > > On Di, 03 Sep 2013, Peter Samuelson wrote: > > > texlive-lang-european? It doesn't look like it to me (no Breaks or > > > Conflicts), but I haven't actually tried it. > > conflicts there are, texlive-base conflicts with all the old packages. > I misspoke. There is a Conflicts in texlive-base, but what is probably > needed is Provides in texlive-lang-european. As I understand it, that > will prompt apt to DTRT on upgrade. Unless apt has gotten smarter recently (which is not out of the question), no. It's a common misconception that apt will care about Provides/Replaces for selecting new packages on dist-upgrade, but while it seems like a nice idea, TTBOMK it's never been implemented. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Looking for ideas for merging a micro package...
On Wed, Sep 04, 2013 at 01:02:35PM -0500, Peter Samuelson wrote: > [Thorsten Glaser] > > I absolutely do not want to see anything related to ruby on my > > systems. > Why? Is this just an emotional reaction, or is it the 13 MB of > dependencies, or something else? > I wonder if anyone feels the same way about, say, libraries written in > FORTRAN, or binaries linked against libX11. From experience, lots of people feel the same way about binaries linked against libX11. I think FORTRAN is probably less of an issue for people, because it's a much smaller runtime (Installed-Size: 1195). But I would also not like to see devscripts depend on ruby - not just because I don't want to have the runtime installed for a language that I don't speak[1], but because letting people write devscripts in whatever language they feel like turns that package into a maintenance nightmare down the line, by further fragmenting your pool of maintainers. Sure, accepting scripts in ruby means you will get contributions from people who write in ruby who might otherwise not have contributed, and you may have people participating in maintenance who would like to help in ruby and otherwise wouldn't help. But on the flip side, for the package to be well-maintained you now *have* to have maintainers working in each of perl, python, and ruby, and the members of the maintenance team are now that much less able to step in for one another. And on a completely unrelated note, discussions at DebConf about multiarch handling of interpreters reveals that devscripts has its own special problems just by depending on perl + python. Maybe people should see the fix required for this before deciding to make devscripts depend on more interpreters. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] And whose community, for that matter, has turned me off from ever learning signature.asc Description: Digital signature
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On 2013-09-04, Steve Langasek wrote: > Unless apt has gotten smarter recently (which is not out of the question), > no. It's a common misconception that apt will care about Provides/Replaces > for selecting new packages on dist-upgrade, but while it seems like a nice > idea, TTBOMK it's never been implemented. Over in RPM land, I think they have a Obsoletes relation for a 'you should consider this package a successor to package' I have missed such a thing from time to time. /Sune -- 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/slrnl2f0p4.hsi.nos...@sshway.ssh.pusling.com
Re: Looking for ideas for merging a micro package...
On Wed, Sep 04, 2013 at 01:16:12PM +, Thorsten Glaser wrote: > Benjamin Drung debian.org> writes: > > devscript had only Perl and Shell scripts initially, but then gained > > Python scripts. I don't see any reason to not accept ruby script. ruby > > would pull in another ~ 13 MB of storage, but devscripts targets > > developer machines. > I absolutely do not want to see anything related to ruby on my > systems. How is that relevant for Debian? > Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Roll call for porters of architectures in sid and testing
Hi, I am an active porter for the alpha architecture in that I run two buildd servers and I intend to continue this for the lifetime of the jessie release: For alpha, I - test some packages on this architecture - maintain buildds I am not a DD/DM Bill MacAllister -- Bill MacAllister Infrastructure Delivery Group, Stanford University -- 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/717d01a4fc1ba4fcc23b1...@trainmaster.stanford.edu
Re: Looking for ideas for merging a micro package...
Peter Samuelson dixit: >> I absolutely do not want to see anything related to ruby on my >> systems. > >Why? Is this just an emotional reaction, or is it the 13 MB of >dependencies, or something else? Something else, mostly technical, the rest personal. >I wonder if anyone feels the same way about, say, libraries written in >FORTRAN, or binaries linked against libX11. I know about people who have similar reactions against pretty much any programming language in existence, X11 binaries (indeed), dynamically linked binaries, copyleft code and non-free stuff. bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“ PS: سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ -- 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/pine.bsm.4.64l.1309042013020.14...@herc.mirbsd.org
Bug#721870: ITP: node-normalize-package-data -- Normalizes metadata typically found in a package.json file - Node.js module
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-normalize-package-data Version : 0.2.2 Upstream Author : Meryn Stol * URL : https://github.com/meryn/normalize-package-data * License : BSD-2-clause Programming Lang: JavaScript Description : Normalizes package metadata - Node.js module This module is used by node-read-package-json to normalize data it reads from a package.json file typically found in Node.js modules, but in principle it could come from any source. . Node.js is an event-based server-side javascript engine. -- 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/20130904210516.16649.3742.reportbug@imac.chaumes
Bug#721874: ITP: node-github-url-from-git -- Convert github git or gist url to an http url - Node.js module
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-github-url-from-git Version : 1.1.1 Upstream Author : TJ Holowaychuk * URL : https://github.com/visionmedia/node-github-url-from-git * License : Expat Programming Lang: JavaScript Description : Convert github git or gist url to an http url - Node.js module This module is a simple regular expression for parsing and converting a git repository url from github to an http url. It supports gists as well. It is used by npm and node-normalize-package-data. . Node.js is an event-based server-side javascript engine. -- 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/20130904221028.21788.72390.reportbug@imac.chaumes
Re: Roll call for porters of architectures in sid and testing
Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For SPARC64, I - test a lot of the packages for KDE4 Desktop - testing and currently preparing patches for Iceweasel - test Vanilla build of the Linux kernel, trying to find out why everything after 2.8 breaks certain builds. - currently own a Sun Blade 2500, a Netra X1, and a SunFire T2000 - help port random projects to Sparc64 For Alpha, I - test basic functionality of Xorg and XFCE - port random projects to Alpha I am not a DD/DM On Sun, Sep 1, 2013 at 3:33 AM, Niels Thykier wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > As we announced in [LAST-BITS], we would like to get a better idea of > that status of the ports, to make an informed decision about which > port can be released with jessie. One of the steps is to get an > overview of which of the porters are (still) active for each > port. Once the results from the role-call are in, we will request > other information about the status of the ports. In the meantime, feel > free to update and collect info about the ports in the Debian wiki[WIKI]. > > If you are (or intend to become) an active porter for the lifetime of > jessie, then please send a signed email explaining your involvement in > the port to the Release Team before > 1st of October 2013. Please explain the level of your involvement in > the port. > > Feel free to use the following template as your reply: > > """ > Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the jessie release: > > For , I > - test (most|all) packages on this architecture > - fix toolchain issues > - triage arch-specific bugs > - fix arch-related bugs > - maintain buildds > - ... > > > > > """ > > Niels, on behalf of the release team > > [LAST-BITS] > http://lists.debian.org/debian-devel-announce/2013/08/msg6.html > > [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > > iQIcBAEBCAAGBQJSIu2TAAoJEAVLu599gGRC86EP/j/7FEZ9pxpTEHrBI41GTu6r > nENS5kAZAuxFQHfYLtKexBcgneGd6cgdmr3cIoh1ZL9lJgXq74X8FL5IbWNqUw9S > o9UQWpZJiwIIlH4fqSgFVLIphI0DQr7dXI7xcDIm4kl6Fdruo1tGxX8xqL23jzdP > nQb3jrXv3bj5943MfWeCbODILv2N6qev9VtWeQ6Wmh8PvxRUl7VqgdQaeHtlMsUp > TQT5fz0cw8gc2amlwlOZxaGDV2C8mHboJIKMEsu79BK4SlFSED9rXn4juFPUnAgG > uADsMdBBqEIgSMN42cPHQju+KLfJe/+xScmlzzDS/d7aWWs02TibcQ1ZnPi+bcgp > bd/Wa0lms+Fc2OpcuFle9Lwo+2B+ka1Dd3itm+D0SbmrxoGi6CuMMwydLcQbSJ73 > hHw9HJEIQr2x/ZItNPJrSvvj50rwYXcmFbxtVAwv2pFXfQ37iukYgAaaMvnwpNNJ > 6dM1coCF9skNkXLO8rkZ+5aupGgjpS9BdKKAEQrPy/aoaW9KNCZrLQeA4C3QySBU > OcCNBv7taSjVAVNszKtRIQpu2gzFGAV0u9Gj41qW1JzDHYrmAvMyGxrndOxTmaFr > p05QWgcMsPhNvdHjd6sWLyzJ5NYUKksCPMRgCc0BEd6moIyrt7UFsp2+guJZPBJ0 > pffEJGK2iGtrWmJfElof > =TUeZ > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20130901073351.a92862...@thykier.net > >
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
severity 721838 whishlist tags 721838 pending thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- 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/20130905004837.gh1...@gamma.logic.tuwien.ac.at
Bug#721889: ITP: php-patchwork-utf8 -- UTF-8 strings handling for PHP
Package: wnpp Severity: wishlist Owner: David Prévot * Package name: php-patchwork-utf8 Version : 1.1.11 Upstream Author : Nicolas Grekas * URL : https://github.com/nicolas-grekas/Patchwork-UTF8 * License : Apache-2.0 or GPL-2 Programming Lang: PHP Description : UTF-8 strings handling for PHP Patchwork UTF-8 provides both a portability layer for Unicode handling in PHP, and a class that mirrors the quasi complete set of native string functions, enhanced to UTF-8 grapheme clusters awareness. . Patchwork UTF-8 provides pure PHP implementations for mbstring, iconv, and intl. The following set of portability-fallbacks allows an application to run on a server even if those extensions are not enabled: . * utf8_encode, utf8_decode, * mbstring: mb_convert_encoding, mb_decode_mimeheader, mb_encode_mimeheader, mb_convert_case, mb_internal_encoding, mb_list_encodings, mb_strlen, mb_strpos, mb_strrpos, mb_strtolower, mb_strtoupper, mb_substitute_character, mb_substr, mb_stripos, mb_stristr, mb_strrchr, mb_strrichr, mb_strripos, mb_strstr, * iconv: iconv, iconv_mime_decode, iconv_mime_decode_headers, iconv_get_encoding, iconv_set_encoding, iconv_mime_encode, ob_iconv_handler, iconv_strlen, iconv_strpos, iconv_strrpos, iconv_substr, * intl: Normalizer, grapheme_extract, grapheme_stripos, grapheme_stristr, grapheme_strlen, grapheme_strpos, grapheme_strripos, grapheme_strrpos, grapheme_strstr, grapheme_substr. . The Patchwork\Utf8 class implements the quasi-complete set of native string functions that need UTF-8 grapheme clusters awareness. Function names, arguments and behavior carefully replicates native PHP string functions. . Some more functions are also provided to help handling UTF-8 strings . * isUtf8(): checks if a string contains well formed UTF-8 data, * toAscii(): generic UTF-8 to ASCII transliteration, * strtocasefold(): unicode transformation for caseless matching, * strtonatfold(): generic case sensitive transformation for collation matching . Mirrored string functions are: strlen, substr, strpos, stripos, strrpos, strripos, strstr, stristr, strrchr, strrichr, strtolower, strtoupper, wordwrap, chr, count_chars, ltrim, ord, rtrim, trim, str_ireplace, str_pad, str_shuffle, str_split, str_word_count, strcmp, strnatcmp, strcasecmp, strnatcasecmp, strncasecmp, strncmp, strcspn, strpbrk, strrev, strspn, strtr, substr_compare, substr_count, substr_replace, ucfirst, lcfirst, ucwords, number_format, utf8_encode, utf8_decode. I intend to maintain it under Debian PHP PEAR umbrella, and get rid of the embedded copy from the current version of owncloud. Regards David signature.asc Description: Digital signature
