Re: About repackaging of the ‘orig’ tarball.

Hi Charles, Charles Plessy wrote: > Le Tue, Dec 08, 2009 at 05:36:54PM +0100, Damien Raude-Morvan a écrit : >> As a general guideline, generated files should be stripped from "original" >> source tarballs. [...] > I personnally tend to prefer to keep the Debian ‘orig’ tarball identical to > the

Re: git-core maintenance

Hi, Ramkumar Ramachandra wrote: > I found that the package git-core has several outstanding bugs filed > against it. Many of them are poorly tagged, and their status has not > been updated in quite some time. It might be helpful to read this: [1] > After that, I tried asking > the maintainer to

Re: git-core maintenance

Ramkumar Ramachandra wrote: > Just to clarify, the issue is not his seeming non-responsiveness, but > emails bouncing. Oh! Thanks for the clarification. Sorry for the confusion, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Troubl

Re: git and quilt

John Goerzen wrote: > On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote: >> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr >> package. > > I am doing the same, for the very simple reason that every other > approach I've seen violates the KISS (Keep It Simple,

dpkg source format 3.0 (git)

Henrique de Moraes Holschuh wrote: > Given the size of the .git dir when you're not using something like stgit > and have all objects properly packed, one could even consider shipping .git > inside the package if it is small enough. > > Is that a proper way to do this? Or would we need a new 3.0

Re: dpkg source format 3.0 (git)

Goswin von Brederlow wrote: > 1) Think about doing this for linux-2.6, XOrg or OOo and what it would > mean for the source size or usability. Indeed, the history is pretty large. A rough estimate (for something less rough, one should use a well packed bundle with only the objects of interest):

Re: dpkg source format 3.0 (git)

Jonathan Nieder wrote: > For usability: I imagine what is typically needed is the set of Vcs-Git > fields somewhere conveniently machine-readable, so one could just go > > apt-get source --git whatever > > and get a checkout of its packaging repository. ... which i

Re: Changes in dpkg Pre-Depends

Guillem Jover wrote: > Regarding xz-utils' size, I was just checking and it seems not all > programs are linking against liblzma, by passing --enable-dynamic to > both configure lines the package gets reduced to 396 KiB. Also by > not shipping xzdec and lzmadec the package gets down to 324 KiB. >

Bug#571060: xz-utils: give xzdec and lzmadec their own package

Package: xz-utils Version: 4.999.9beta+20100212-1 Severity: wishlist Guillem Jover wrote: > Also what's > the point of shipping the xzdec and lzmadec tools in the main package? > It seems they would make sense as part of another package as tiny > decompressors-only, but no in addition to the main

Optimization for slow platforms (Re: Changes in dpkg Pre-Depends)

Thomas Weber wrote: >>> Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit : Using non-PIC code for a 5% speed up looks like an acceptable trade off to me, but it really must be restricted only to architectures which need it. [...] > You have x86 hardware that is so old th

Re: Optimization for slow platforms

Marco d'Itri wrote: > If the programs are linked statically then they will have the same > memory footprint of programs linked with non-PIC libraries, so the > situation will not be worse in this sense. On non-i386 architectures, I will turn on --enable-dynamic to link to the current PIC library.

Re: Changes in dpkg Pre-Depends

Josselin Mouette wrote: > Le mardi 23 février 2010 à 20:32 +0100, Marco d'Itri a écrit : >> Anyway, there are often good reasons to use x86 on modern hardware >> (think about laptops and smaller VPSes). > > You mean, like saving memory? > > Wait… wouldn’t you save more memory by using shared lib

Re: Changes in dpkg Pre-Depends

Hi Russ, Russ Allbery wrote: > That being said, a 5% performance gain from using statically linked > non-PIC code doesn't strike me as very compelling even for older systems. Thank you for your candor; even a hunch like this one is the sort of thing I was interested to hear. I got the 6-7% diff

Tradeoffs of static linking (Re: Changes in dpkg Pre-Depends)

Russ Allbery wrote: [... explanation of the tradeoffs snipped ...] > Note, btw, that for some algorithms, you might gain significant speed, > more than the PIC difference, by being able to compile for more capable > processors (enabling SSE2 can make a huge difference, for instance). > Shared libr

Re: [New pre-depends] SElinux support for findutils.

Santiago Vila wrote: > On Sat, 3 Apr 2010, Andreas Metzler wrote: [...] >> This requires linkage against libselinux1. There is no problem with >> priorities, both packages are Priority: required. >> >> Since findutils is essential, the respective dependency ends up in >> Pre-Depends. Which is why

The 'git' Debian package in squeeze and possible mass bug filing

Hello, Gerrit Pape wrote: > I'm about to provide a new git binary package from the git-core (the > distributed revision control system) source, so that 'apt-get install > git' installs the git content tracker in squeeze. A new version 1.7.0.4-2~exp0 of git has been uploaded to experimental, with

Re: The 'git' Debian package in squeeze and possible mass bug filing

Julien Cristau wrote: > On Wed, Apr 7, 2010 at 23:10:31 -0500, Jonathan Nieder wrote: > >> Now that there is a package available to test with, I would like to >> file bugs for the affected packages suggesting this change. I suggest >> an RC severity since it would be nice

Re: The 'git' Debian package in squeeze and possible mass bug filing

Hi Michael, Michael Biebl wrote: > Hm, making git-core a dummy/transitional package, which pulls the "git" > package > on upgrades sounds like a better idea to me. > Otherwise git won't be updated when going from lenny to squeeze. Gerrit Pape implemented what I think is a nicer method: git-core

Re: The 'git' Debian package in squeeze and possible mass bug filing

Joey Hess wrote: > You forgot to include packages that Suggest git-core in the list. The only package with a versioned Suggest of git-core I found was moap, which I did include. Still, I wouldn’t be surprised if I missed something for some other reason. For what it’s worth, the list of affected

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

Hi, Simon Richter wrote: > The problem at hand is the proposed (and implemented) solution for > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332223 . [lxterm having higher priority than konsole on KDE systems] > > I'm unconvinced that bumping the priority on the other terminal > emulators is

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

clone 348775 -1 reassign -1 xdg-utils 1.0.2+cvs20100307-3 retitle xdg-utils please introduce (sane) xdg-terminal tags -1 + upstream quit Paul Wise wrote: > In xdg-utils CVS there is an xdg-terminal script, not sure why that > isn't available in Debian yet: When no desktop is in use, it uses $TER

Re: Bug#605009: serious performance regression with ext4

Hi Ted, Ted Ts'o wrote: > 1) Suppose package contains files "a", "b", and "c". Which are you > doing? > > a) extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a); > extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b); > extract c.dpkg-new ; fsync(c.dpkg-new); rename(

Re: fails to purge not RC

Hi, Holger Levsen wrote: > On Donnerstag, 16. Dezember 2010, Jonathan Nieder wrote: >> Could you elaborate? I would think that making "dpkg --purge" exit >> with nonzero status would be serious, though perhaps of the can-defer >> kind. > > It's annoyin

Getting warned about and contributing to decisions (Re: Why is help so hard to find?)

Hi Chris, Chris Carr wrote: > Sorry to de-lurk with a tangential question, but how can I as an > interested observer subscribe to the conversations where these decisions > get made Good question. Subscribe to the PTS for the affected packages[1] and test the versions in unstable and experimenta

Re: ObsoleteConffilesOfInstalledPackages

Mike Bird wrote: > Some people have expressed interested in obsolete config files > associated with currently installed packages. [...] Correct behavior is to remove obsolete _unmodified_ conffiles, as Roger mentioned. Which of the conffiles mentioned below were modified? No way to know just ye

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

(please drop cc's other than debian-policy in replies if you want to work on that) Hi Wookey, Wookey wrote: > Debian policy (8.2) says: > --- > It is recommended that supporting files and run-time support programs > that do not need to be invoked manually by users, but are neverthele

The "node" command in Debian

(please follow-up to debian-devel only) Hi Debianites, As you may know[0], there are currently two packages in Debian experimental providing a "node" binary. [0] http://lists.debian.org/debian-devel/2010/08/msg00568.html The node.js project --- One is from the node.js project. I

Detecing missing Build-Conflicts (Re: Upcoming FTPMaster meeting)

Roger Leigh wrote: > The other side to this is that fixing such bugs gains us very litle. > > If we have a guaranteed clean build environment + package build deps, > we have as complete consistency as is practicable. > > If we have a random build environment + package build deps, we might > occasi

Wanted: maintainer for git's emacs support

Hi, None of the current Debian git maintainers seem to use emacs. This means git's emacs support[1] does not get as much care as it deserves: see for example bugs #611936, #611931, #611932, #611933, #611934, #577834, and #611935. The upstream maintainer is very friendly and responsive though he

Re: Call for projects for Google Summer of Code 2011

Paul Wise wrote: > That is unlikely to be useful, upstream has explicitly said they are > targeting Linux only. More precisely[1]: "Will this run on [insert non-Linux OS here]? Unlikely. As pointed out, systemd uses many Linux specific APIs […] That said, git supports

Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?

Hi, Steve Langasek wrote: > So in this case the pre-dependency > should *not* be set, as it only serves to complicate the upgrade path. I think this example might deserve a closer look. Documentating the required dpkg version seems useful for backporters and others who would use the package in

Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?

To recap, there was some discussion about whether a versioned Pre-Depends on dpkg-maintscript-helper [dpkg (>= 1.15.7.2)] is a good idea for packages in wheezy, with no definite conclusion. The main complication was such Pre-Depends are not needed for squeezy-to-wheezy upgrades. Still I believe a

Re: Library depending on -data packages

(dropped cc's; hopefully that's okay.) Hi! Luca Capello wrote: > I see these situations as a misuse of Depends: where Recommends: would > be perfectly fine, otherwise Recommends: are useless. But given that it > seems no one agrees with me, is such a behavior documented somewhere? Checking poli

Re: Library depending on -data packages

Hi, Simon McVittie wrote: > Which way to break the circular dependency needs to be considered > case-by-case; > neither answer is universally right. Here (with this statement of the problem) I disagree --- using Depends to mean Enhances is _always_ wrong. For example: > The existence of opena

Re: Library depending on -data packages

Simon McVittie wrote: > Or are you saying > that things with special::auto-inst-parts should never have even a weakened > dependency on the package of which they're an implementation detail? Yes. (Well, a Suggests is okay.) > In situations where the data and the engine have a many-to-many relat

Bug#664257: multiarch tuples are not documented/defined

Hi Matthias, Steve McIntyre wrote: > I've updated http://wiki.debian.org/Multiarch/Tuples with lots more > information such as links to external ABI specs where I could find > them. I think the Multiarch/Tuples wiki page is now in a sane state, though as always it could presumably be improved ev

Re: Volunteer-initiated team maintenance as a solution for packages with low activity

Michael Gilbert wrote: > Plus I don't have to find hosting for my work elsewhere, > which is kind of a pain and unwanted. This at least is easy to address. Alioth automatically notices per-user git repositories under ~/public_git[1]. Something similar works for other version contr

Bug#664257: multiarch tuples are not documented/defined

reassign 664257 debian-policy 3.9.3.1 affects 664257 = tags 664257 = upstream quit Goswin von Brederlow wrote: > It is a bug in Debian: The multiarch tuples are not documented/defined > in Debian. Fine, reassigning to policy. Never say I didn't do anything for you... :) Policy maintainers, see

Re: RFC: OpenRC as Init System for Debian

Marco d'Itri wrote: > We can all be "uneasy" about it until we are blue in the face, but since > Red Hat maintains most Linux core components and we do not, there is not > much we can do about it. I'll repeat what I said last time you made this (in my opinion strange) argument: Red Hat employs

Re: Definition of _boot_

Svante Signell wrote: > In line with the recent discussion, lets aim at defining what _boot_ is: Why? Unless you are suggesting documentation is unclear, I don't see how this has any impact on the development of Debian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a

Re: RFC: OpenRC as Init System for Debian

Marco d'Itri wrote: > This has been happening more and more after SuSE has become irrelevant. > > I will cite just a few simple examples: > - no good strategy to prevent lockstep udev/kernel upgrades, since RHEL > does not support upgrading to the next major release > - configuration files in /

Re: Node.js and it's future in debian

Carsten Hey wrote: > I don't think that there ever will be a consensus in all those > discussions without discussing in a reasonable way (which failed in the > past multiple times). Note that a consensus does not imply everyone agreeing. I am starting to see a consensus already and would welcome

Re: Node.js and it's future in debian

Carsten Hey wrote: > I was talking about a consensus among the maintainers of the affected > packages. Even if all but the maintainers of one of the affected > packages would agree to a solution, there would be no way to implement > this solution without asking the tech-ctte or (what would be not

Re: Node.js and it's future in debian

Steve Langasek wrote: > On Tue, May 01, 2012 at 03:30:50PM -0500, Jonathan Nieder wrote: >> Wait, really? What happened to respect by maintainers for the >> project? > > "The project" is not "a set of random maintainers who have a filename > conflict wi

Re: Node.js and it's future in debian

Hi again, Steve Langasek wrote: > [Dropped Cc; what does any of this have to do with the DPL?] I was alerting him to a conversation that was going nowhere fast, in the hope that he might use his power to participate in discussions amongst the Developers in a helpful way It has

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

Hi, (Caveat: I am not a dpkg-source maintainer.) Sune Vuorela wrote: > On 2012-05-15, Norbert Preining wrote: >> Is there a rational behind not allowing any fuzz? > > I think it makes perfect sense to expect the patches to apply perfectly, > so we don't rely on patch & quilt to be able to unfuz

Re: Wheezy release: CDs are not big enough any more...

Bjørn Mork wrote: > Timo Juhani Lindfors writes: >> You also need to have root access to some machine to create the USB >> media. > > No, you don't. On a default Debian system you need to be a member of > the "floppy" group. From /lib/udev/rules.d/91-permissions.rules : > > # default permissio

Re: Handling of changelogs and bin-nmus

Raphael Hertzog wrote: > As such, I suggest that we handle "binary rebuild" differently: > - debian/changelog is left unmodified since it's the source changelog > => it defines the ${source:Version} substvar > - debian/changelog.binary-rebuild (or any other better name) is created > when we wa

Re: Handling of changelogs and bin-nmus

Andreas Barth wrote: > Do we have other tools than dpkg that parse the changelog to find out > the package version? Yes, debian/rules parses the changelog in a low-tech way in some source packages. Someone with access to the lintian lab might be able to say how many packages would be hurt by not

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

retitle 678519 after about a month, routing gets wedged # not a general problem affecting a large portion of the archive reassign 678519 base tags 678519 + squeeze quit Hi Henrique, Henrique de Moraes Holschuh wrote: > On Fri, 22 Jun 2012, Rudy Zijlstra wrote: >> let system run with IPv4 & IPv6

Use of the "general" and "base" packages (Re: general: after about 1 month...)

Hi Holger, Holger Levsen wrote: > On Sonntag, 24. Juni 2012, Jonathan Nieder wrote: >> retitle 678519 after about a month, routing gets wedged >> # not a general problem affecting a large portion of the archive >> reassign 678519 base > > reassigning bugs from genera

Bug#679173: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X

tags 679173 + wheezy moreinfo quit Hi Jean Pierre, HOAREAU jean pierre wrote: >* 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? Could

Bug#679173: [Jean Pierre Hoareau: Re: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X]

submitter 679173 Jean Pierre Hoareau quit Forwarding with permission. --- Begin Message --- Dear Jonathan, Thanks for your quick answer, and sory for ma late answer due to a failure on my mailbox "jphoar...@free.fr". Use my primary mailbox "*hoarea...@free.fr*" for all new communication abou

Bug#679173: blueman-manager: File Send and all later operations time out (Re: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X)

reassign 679173 blueman quit Hi Jean Pierre and blueman maintainers, Jean Pierre Hoareau wrote > You wil find her under some detail about what hapen when I try to > send a file to my "HTC ONE X" smartphone . I think you are able to > reproduce this fail if you use the same hardware. Thanks m

Re: Recommends for metapackages

Hi, Jonas Smedegaard wrote: > No, I do not find it right for Debian to mandate meta-packages to only > recommend when some users need only a subset of the offerings of said > meta-package: There will _always_ be some users needing only a subset of > things, rendering all dependencies "wrong" b

Bug#637232: Multiarch breaks support for non-multiarch toolchain

affects 637232 + release-notes quit Hi, Matthias Klose wrote: > On 08/09/2011 07:31 PM, Aurelien Jarno wrote: >> I got fed up by people reporting bug on libc6, while this problem results >> from a decision Debian to implement multiarch. People should work on >> implementing a compatibility wrapp

Bug#637232: Multiarch breaks support for non-multiarch toolchain

Hi, Goswin von Brederlow wrote: > On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote: >> a) Help upstream authors of toolchain components with hardcoded >> header and library search paths to implement multiarch. [...] > What I don't understand is why co

Priority field of xz-utils package

(please direct replies to debian-devel only) Ever since dpkg started using liblzma directly (dpkg 1.16.4), the xz command is no longer needed in a minimal Debian system. Based on its list of reverse-dependencies, it would presumably even be safe to lower its priority to optional. I think "standa

Microcode and the installer (Re: Towards d-i wheezy beta 3)

(replying to -devel and -boot only) Henrique de Moraes Holschuh wrote: > On Mon, 10 Sep 2012, Philipp Kern wrote: >> If we do that the same should also happen for firmware-linux-nonfree. Loading >> the radeon KMS module without firmware available results in an unusable >> (text) console. (Yes, it

Re: mass bug filing about packages manipulating/deleting shipped files

Nicholas Bamber wrote: > Moreover as I understand it the version of piuparts that runs these > tests is not yet in sid. Surely it is unreasonable to expect people to > fix these bugs - in the middle of a freeze no less - without this tool. Doesn't debsums catch it? -- To UNSUBSCRIBE, email to

Re: Temporary solution for changelog problem in binNMUs

Hi, Ian Jackson wrote: > The real problem is that these changelog files are primarily intended > for human beings. They should live in /usr/share/doc, and their > location should be transparent. I was convinced of this until I remembered that package descriptions are very similar in this respec

Re: Temporary solution for changelog problem in binNMUs

Ian Jackson wrote: > Jonathan Nieder writes ("Re: Temporary solution for changelog problem in > binNMUs"): >> One problem that that doesn't solve is what to do when a package would >> be able to borrow its /doc/ directory from another package >> (usi

Bug#718394: ITP: buck -- Facebook's build system for large Java projects

Package: wnpp Severity: wishlist Owner: jrnie...@gmail.com * Package name: buck Version : 0.20130612-1 Upstream Author : buck-bu...@googlegroups.com (Facebook) * URL : http://facebook.github.io/buck/ * License : Apache-2.0 Programming Lang: Java Description

Re: Built-Using description too aggressive

Hi, Charles Plessy wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -5563,7 +5563,13 @@ Replaces: mail-transport-agent > > > > - A Built-Using field must list the corresponding source > + When the licensing terms of the incorporated parts require to provide > +

Re: On Sid and Experimental

Hiya, Manjul Apratim wrote: > I cannot help but view too many apt pins > as an intentional recipe for disaster! If you really want to experience life on the edge, you can try this: echo 'APT::Default-Release "experimental";' \ >/etc/apt/apt.conf.d/preferexperimental.conf

Re: ITP: susv4 -- Fetch and install SUSv4 (POSIX.1:2008) documentation

Hiya, David Weinehall wrote: > Description : Fetch and install SUSv4 (POSIX.1:2008) documentation > > The Single Unix Specifications are not permitted to be generally > redistributed, so this is an installer that fetches them and installs > them in a Debian appropriate way. See

Re: regression: "sh -c" change causes FTBFS

Stéphane Glondu wrote: > On 10/06/2011 04:07 PM, Jonathan Nieder wrote: >> ksh93 -c "/bin/sleep 100 >dev/null" does skip a fork(). I suspect >> bash does not skip a fork in this case for the same reason that >> >> bash -c 'echo hi; /bin/sleep

Bug#637965: general: Kernel panic when unmounting partitioned Hitachi X500 USB disk

reassign 637965 linux-2.6 forcemerge 634681 637965 quit Hi José, José Hipólito Moyano wrote: > When my hitachi X500 500GB USB external disk is unmounted, it has more than > 50% > probability of cause a kernel panic. "general" is not the package for kernel bugs. > Call Trace: > [] ? __blk_put

Bug#616317: base: commit= ext3 mount option in fstab has no effect.

reassign 616317 initscripts quit Roger Leigh wrote: > On Sun, May 08, 2011 at 05:24:09AM +0100, Ben Hutchings wrote: >> Could we not have init remount root based on /etc/fstab? [...] > Also, with the version of initscripts in experimental, the domount > mount helper can remount filesystems with t

Bug#626736: general: can't ping windows machine by name

retitle 626736 debian-reference: please explain how to set up NETBIOS name resolution reassign 626736 debian-reference 2.46 severity 626736 wishlist quit Hi Sergey, sergey wrote: > I had the next situation some time ago: several computers with > Windows and one GNU/Linux system connected to rou

Bug#635157: cups: please support Brother HL-2130 laser printer out of the box

retitle 635157 Brother HL-2130 laser printer support severity 635157 important severity 618640 important reassign 635157 cups quit Hi, micha...@gmail.com wrote: > Using Squeeze and wanted to install a new Brother HL-2130 laser printer. > Noticed that the printer is not in the printer list from D

Bug#635462: general: Update manager freezes when started

reassign 635462 update-manager-gnome tags 635462 + moreinfo quit Hi Eric, Eric Wilson wrote: > Package: general This report concerns one package rather than a large portion of the archive, so "general" is not the right package. > Update manager opens then freezes while checking for updates Co

Bug#601455: general: can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo

tags 601455 - patch retitle 601455 multiple, annoyingly different ways to disable an init script quit Hi Mathias, Mathias Kub wrote: > When I try to stop a daemon after I disabled it in /etc/default/foo, > I get an error-message that I can not stop it, because it is > disabled. > > Shouldn't I b

Bug#601455: general: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo

Hi, peter green wrote: > Though there are some situations where it is nessacery. Consider vtund for > example which has seperate enable/disable flags for running in server and > client modes (with the potential for multiple seperate client instances). Thanks for this clarification. Luckily vtun

Re: segfault error 4 in libpthread-2.13.so X86_64

Dallas Clement wrote: > Will report back what I find. Please don't. This is the wrong list --- it is about development _of_ Debian, not development _on_ Debian. You might find the libc-help list[1] to be more helpful. Or if your questions are Debian-specific, debian-user[2] can be a great help

Re: Minified files and source code requirement

Russ Allbery wrote: > I think a better line is whether the source tarball includes all the > pieces required for someone with appropriate skills to make modifications > to the software with reasonable ease. The advantage of that, as opposed > to trying to weigh whether upstream has additional adv

Is anyone maintaining (the ham radio tool) node?

Hi, In February, I wrote[1]: > Both LinuxNode (package "node") and node.js (package "nodejs") are > designed to be accessed through the command name "node". [...] > If there is any way I can help, please feel free to ask. No response from the "node" package maintainers. My offer still stands, b

Re: Is anyone maintaining (the ham radio tool) node?

Hi Pat, Patrick Ouellette wrote: > The binary on the ham radio side is not "LinuxNode" in package "node" it is > simply "node" in package "node" > > Since you are still concerned with this issue, and neither side has shown a > willingness to change, I would say the time has come for both packages

Re: Is anyone maintaining (the ham radio tool) node?

Patrick Ouellette wrote: > You claim to not use either package, but yet you advocate for the node.js > package to keep the executable name "node" - this is strange to me. Sorry, I must have been unclear. I was only explaining my preference. I wasn't lying. I also said: >> However, if the only

Re: Is anyone maintaining (the ham radio tool) node?

(+cc: nod...@packages.debian.org. Sorry for the noise.) Jonathan Nieder wrote: > Patrick Ouellette wrote: >> You claim to not use either package, but yet you advocate for the node.js >> package to keep the executable name "node" - this is strange to me. > > Sorr

Re: Is anyone maintaining (the ham radio tool) node?

Cyril Brulebois wrote: > Vincent Bernat (14/11/2011): >> See how communities may react to this. Ruby community does not like our >> packaging just because we enforce stability over freshness. What would >> think node.js community if we are using /usr/bin/nodejs instead of >> /usr/bin/nod

Re: Two groups of users, one distro in the middle

Hi, Alex Pennace wrote: > According to [1], this isn't the first time the nodejs folks ran into > a name problem. Up until March of 2009 they were using the name > "server," I suspect this was just a working title for the program being developed, in the half month before Ryan was able to come up

Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

Wolfgang Tichy wrote: > Thanks for your answer. I think the intel compiler does support the -B > and -I options. So I think your suggestion would work. However, I am > not sure if I like this solution. It's only a workaround. A fix would involve contacting the Intel developers to get icc to sear

Re: what if a package needs to be "recalled"

Russell Coker wrote: > Isn't this one of the reasons for the epoch field? No. If chromium 14.0.835.202~r103287-1 actually worked[1], the thing to do would be to upload a package with version number 15.0.874.106~r107270+really14.0.835.202~r103287-1. That way, the blip in version numbering can be

Re: Piklab

Salvo Tomaselli wrote: > Perhaps you could consider maintaining it? Unless you're suggesting that Richard maintain KDE3, too, that doesn't seem like very practical advice. Following the links from , I see that piklab was removed because it unfortunately has

Re: Piklab

Salvo Tomaselli wrote: > Il 22.11.2011 12:31 Richard ha scritto: >> Can piklab be added to the distro, its stable and runs Ok on wheesy/sid. [...] > Perhaps you could consider maintaining it? My last reply completely missed the point. According to [1] the program was already ported to Qt 4. Sor

Re: Is anyone maintaining (the ham radio tool) node?

Ian Jackson wrote: > I think the best way to fix this is to prepare both renaming uploads > in advance, and allow either of the two contending maintainers to > upload both packages simultaneously. Thanks, that sounds sensible to me. Since this still seems to be stalled, I would like to hear from

Re: Is anyone maintaining (the ham radio tool) node?

Jérémy Lal wrote: > I can prepare a patch for nodejs package. Thanks! [...] > - I can't help but talk about "npm", an essential development tool distributed > in latest nodejs (can be compared to ruby's gem). It allows one to install and > publish npm packages to a common registry. > It will nee

Bug#646622: Changelog for new upstream release should include summary of upstream changelog

retitle 646622 apt-listchanges: please parse upstream changelog, too (perhaps with packages' help) reassign 646622 apt-listchanges 2.85.8 quit Hi, Nemo Inis wrote: > I have a suggestion from an end-user point of view: > > All too often when checking incoming updates (in Synaptic or other tools)

Re: suggestion: build-blockers field in control file

peter green wrote: [...] > This leads to the building of > uninstallable packages which in turn leads to problems with testing > transition of packages. > > Currently there are two workarounds for this situation > > 1: manually alter the package's architecture list to limit building to those > arc

Re: from / to /usr/: a summary

Hi, Just a quick side-note. Marco d'Itri wrote: > Some changes are coming from upstream and we will have to either embrace > them or actively revert them. There is a third option: help upstream to maintain what they consider the "legacy" alternative. Many upstreams, including at Red Hat, seem

Re: from / to /usr/: a summary

Marco d'Itri wrote: > In this case, it has been made repeatedly clear by the upstream > maintainers that they have no desire to accept code to support this and > other things. _If_ upstream is taking the stance that portability to other platforms is something they want nothing to do with, then th

Bug#652011: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

Roger Leigh wrote: > The question that needs answering is this: > > "what are the reasons, today, for a separate /usr?" No, I don't think an answer to that precise question today would be especially helpful. As far as I can tell, it is not especially unsensible to use separate partitions for /

Bug#652011: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

Two clarifications: Jonathan Nieder wrote: > Roger Leigh wrote: >> The question that needs answering is this: >> >> "what are the reasons, today, for a separate /usr?" > > No, I don't think an answer to that precise question today would be > especi

Re: authbind (LD_PRELOAD) and multiarch

Osamu Aoki wrote: > Also, for such input method plugins, we have a hook and configuration script > "im-config" to initialize such input method environment while starting X. Could you spell this out more? What environment variables will im-config set that include architecture names? Which archit

Re: Outstanding /dev/.udev bugs for /run migration

Roger Leigh wrote: > There are 19 packages still using /dev/.udev after udev transitioned > to /run/udev. Unless there are any objections, I'd like to raise the > severity of these bugs from important to serious, given that the /run > migration is a release goal. If "given that the /run migratio

clarifying copyright policy (Re: status of DEP5: Machine-readable debian/copyright)

Charles Plessy wrote: > I would love the answer to this question documented somewhere, but I think > that it would not belong to the DEP 5 document. If you would like, you > can send the question to the FTP Master team and CC the bug number #462996 > (“Document requirements for copyright file.”).

Bug#658980: [skge] transmit queue 0 timed out

severity 658980 important reassign 658980 src:linux-2.6 3.1.8-2 quit burek wrote: > I was watching a movie online, using VLC media player and it > just stopped playing. [...] The debian was completely cut off of > the internet. Ping couldn't resolve any host, ifconfig reported > nothing u

Re: Please test gzip -9n - related to dpkg with multiarch support

Henrique de Moraes Holschuh wrote: > Maybe you can switch to sha256 and add the new functionality while at > it? Detect which mode (md5sum raw, sha256 uncompress) by the size of > the hash. Old debsums won't work with the new files, but is that really > a problem? That's what stable updates and

Re: Please test gzip -9n - related to dpkg with multiarch support

Ian Jackson wrote: > Another relevant question is whether there are other files that are > shared, and which don't want to move, besides ones in /usr/share/doc. One example is header files in /usr/include, from -dev packages. In the simple examples I've seen, putting them in /usr/include/, works

  1   2   >