Re: virtualbox, backports, and fasttrack

Hi, Pirate Praveen wrote: > On Wed, Oct 2, 2019 at 23:23, Bernd Zeimetz wrote: >> Hi Lucaus, >>> I hope that will make quick >>> progress and turn into an official service soon. >> >> basically a good idea, but > > I'm part of the Fast Track team and I'll try to an

Re: Proposal: Repository for fast-paced package backports

Dominik George wrote: > Jonathan Nieder wrote: >> 2. I am happy with the current charter of backports and I think it's >> possible to move forward with fastpaced without having to change >> that charter. > > Yep. That's exactly why the proposal cha

Re: Proposal: Repository for fast-paced package backports

Hi, Pirate Praveen wrote: > I agree with you, it is the best outcome. But when people with power > (-backports ftp masters) are not willing to consider it, we have to > go with plan B, which is less than ideal, but can move things > forward. Just to avoid this being thought of as an idiosyncrasy

Re: Debian Policy 4.1.4.0 released

Hi, Sean Whitton wrote: > On Mon, Jul 02 2018, Jonathan Nieder wrote: >> I'm a bit confused: wasn't it already specified pretty precisely? > > Please take a look through the bug's discussion. It's explained why the > wording was not thought to be good enoug

Re: Debian Policy 4.1.4.0 released

Hi, Sean Whitton wrote: > On Wed, Apr 11 2018, Russ Allbery wrote: >> I'm pretty reluctant to specify this sort of optional target that >> works differently in every package that uses it back in Policy because >> it's really not standardized, nor do I think it's possible to >> standardize. If we

Re: Proposal: A new approach to differential debs

Hi, Julian Andres Klode wrote: > Today's research has shown that rolling hashes do not perform well > on executables because of changing offsets and so on destroying the > hashes. There were no measurable space savings when adding fairly > similar firefox releases to either a casync or borg repos

Re: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

Hi, Ansgar Burchardt wrote: > as a more radical change one could also ask the question where to > maintain the maintainer information. Currently we handle this in the > source package via the Maintainer and Uploaders field, and via team > memberships. > > This has several limitations: for teams,

Re: About a mass bug report not based on Sid or Jessie.

Hi, Wookey wrote: > or perhaps we should collectively decide that dh-autoreconf should > just be used everywhere unles there is a damn good reason not to? Yes, please. At least that's what I do for packages I have something to do with. It makes getting the benefit of upstream autotools fixes (

Re: GnuTLS in Debian

Thomas Goirand wrote: > Most upstream authors who > cares about licensing, do not agree with Debian's view about GPL and > OpenSSL incompatibility, and this is what counts. Is that true? When does it even come up? What do this majority of upstream au

Re: GnuTLS in Debian

Russ Allbery wrote: > Has anyone asked the Git maintainers whether they object to their software > being linked with a libcurl that uses OpenSSL? I am not the author of the most of Git. As a minority author: - libcurl provides a quite similar API with OpenSSL as with GnuTLS. I wish it provi

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 > +

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: 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

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: epoch fix?

Scott Kitterman wrote: > The "really" mechanism is useful for derivatives that don't want to get a > higher epoch than Debian, but in Debian, I totally agree. Just because it > makes sense for a derivative, doesn't mean it makes sense for Debian. It makes sense for Debian, too. Epochs were i

Re: git as a source package format?

Charles Plessy wrote: >It would be definitely a big undertaking, but the point > I want to make is that one can not say that Git repositories could not > be redistributed by Debian and at the same time be satisfied with the > way we handle our packages currently. (And to make

Re: Derivatives, MongoDB and freezes

Steve Langasek wrote: > But for new packages, where Canonical is striking out on its own > to deliver significant new functionality and the folks working on these > packages are not DDs, there's a clear pragmatic argument for doing the work > directly in Ubuntu rather than blocking the

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

Holger Levsen wrote: > On Montag, 1. April 2013, Steve M. Robbins wrote: >> Rather than accept the harm, surely the release team could simply roll >> back the upload in some manner? > > As I understand it, only by introducing an epoch in the package version. Or by using the 9.0.0+really0.99-1 ve

Re: Bug#702607: make source code of all Debian projects visible (on gitweb) [DCS]

Hi, Charles Plessy wrote: > Also, GitHub being proprietary software, it would be great to have a mirror on > a platform running Free software. Done. :) http://repo.or.cz/w/debiancodesearch.git git://repo.or.cz/debiancodesearch.git repo.or.cz runs Girocco from

Re: Built-Using and Cython

Nikolaus Rath wrote: > Russ Allbery writes: >> The main thing we want to avoid is having Build-Using for every single >> package in the archive because of libgcc, because that seems pointless and >> annoying. Similarly, I doubt we need that for the inline code in eglibc >> headers, given that no

Re: Built-Using and Cython

Hi Nikolaus, Nikolaus Rath wrote: > If a debian package uses Cython in its build process, does it need to > declare Built-Using: cython? I don't think typical licenses require that, no. The policy text could use a lot of help in this area. See http://bugs.debian.org/688251 if you have ideas fo

Re: Bug#697433: Is the Package-List field necessary for uploads ?

Russ Allbery wrote: > In response to the other follow-up, I don't think this is the right place > (or bug) to discuss udeb package behavior or what portions of Policy they > comply with. Surely it is relevant to people reading policy that it does not comply with them all (or in other words that t

Re: Something like nocompress DEB_BUILD_OPTION

Hi Dmitrijs, Dmitrijs Ledkovs wrote: > This should be a standard interface via DEB_BUILD_OPTIONS, because > dh_builddeb / dpkg-deb is not the only way to build compliant binary > packages. Policy §4.9 explains: Both binary-* targets should depend on the build target, or on the appropriate b

Re: major linux problems summary 2012

Hi Karol, Karol Szkudlarek wrote: > I'm Debian/Ubuntu/Linux enthusiasts which loves using free operating > systems on my machines, but today in 2012 I'm struggling with many > problems with setup/tunning my Dell Latitude E6510 and Ubuntu and I > have some thoughts general thoughts about Linux lac

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

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

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

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

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

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#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

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: 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

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#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

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

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: 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: 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: 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: 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

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

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: 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: 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: > 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

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: 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

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: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

Hi Wookey, Wookey wrote: > I recently noticed that when building with dpkg-buildpackage there is > no need for the > > DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) > DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) Don't you mean "?="? [...]

Bug#664257: multiarch tuples are not documented/defined

Goswin von Brederlow wrote: > Did you read the wiki page? Yes. Is the kind of information on which calling convention, basic system library structures, and so on form the ABI for a given tuple that I was giving examples of not what the upstream gcc folks were looking for? I'm not sure I underst

Bug#664257: multiarch tuples are not documented/defined

Matthias Klose wrote: > While we strive to get multiarch ready for squeeze, there is > currently nothing to point to what the multiarch tuples actually > mean, neither on the Debian side nor on some kind of standards side > like the FHS or LSB. This has to be documented on the Debian side, > and

Re: description of "general" pseudo-package is misleading (leads people to use it as a catch-all)

Don Armstrong wrote: > http://www.debian.org/Bugs/Reporting already tells people to contact > -user if they are unable to determine which package their bug report > should be filed against. I suppose text could be added to reportbug to > mimic this... perhaps changing: Very nice. Filed as http:/

Re: description of "general" pseudo-package is misleading (leads people to use it as a catch-all)

(moving Mikko to bcc to avoid spamming him) Don Armstrong wrote: > retitle 661241 vlc probably using wrong sound output by default (but not > clear from reporter) > reassign 661241 vlc [...] > Mikko Koho: I'm guessing as to what your problem is, but you're going > to have to provide more informat

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

clone 601455 -1 retitle 601455 can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo quit peter green wrote: > regardless of any plan to discourage use of the /etc/default > mechanism (I think removing it altogether is not really reasonable) > I think the original bug o

Bug#661241: general: Sounds gets quiet, problem uncontrolable

retitle 661241 description of "general" pseudo-package is misleading (sounds too much like a catch-all) reassign 661241 reportbug 6.3.1 submitter 661241 ! quit Hi, Mikko Koho wrote: > Sometimes I switch sounds off from panel, when I'm trying get them back > machine > is still quiet. VLC-mediap

Re: Pre-depends for iptables-persistent on dpkg >= 1.15.7.2~

Hi, Jonathan Wiltshire wrote: > In a recent bug report [0] Colin Watson requested this change in order to > remove some 'if dpkg-maintscript-helper supports' crutches. > > This change is academic for Debian but assists our friends in Ubuntu-land > (it also makes the postinst simpler, but the diff

Bug#660651: Problems with either samba and/or cups and printing from windows

reassign 660651 samba tags 660651 + moreinfo quit Hi Christian, Christian Andretzky wrote: > Sorry for using the general tag, but I've no idea which of the named packages > is responsible > for the problem. That doesn't make it a general issue. Reassigning to samba, since one has to start som

Bug#660558: hostname changed to unknownXXXXXX after upgrading packages

reassign 660558 upgrade-reports tags 660558 + wheezy quit David Paleino wrote: > This bus is unlikely to be caused by wicd. It is, in fact, been patched to > deal > with the bug Ben is referring to. > > http://patch-tracker.debian.org/patch/series/view/wicd/1.7.1-1/02-workaround_dhclient_bug.pat

Re: Multiarch file overlap summary and proposal

Jonathan Nieder wrote: > David Kalnischkies wrote: >> Why would it be intuitive to add a specific value for the arch attribute with >> apt-get install foo # arch |= native >> but remove all values of the attribute with >> apt-get remove foo# arch &= ~all-a

Re: Multiarch file overlap summary and proposal

David Kalnischkies wrote: > Why would it be intuitive to add a specific value for the arch attribute with > apt-get install foo # arch |= native > but remove all values of the attribute with > apt-get remove foo# arch &= ~all-architectures > ? > > Isn't it more intuitive to have it this way:

Re: Multiarch file overlap summary and proposal

David Kalnischkies wrote: > You generously left out the paragraph describing how APT should > detect that the package foo is in fact a library and not, say, a > plugin, a dev-package, a dbg-package or a future-coinstallable binary. > And the foo:* default would be okay and intuitive for all of tho

Re: Bug#655999: [bugs.debian.org] Reporting documentation - "What package does your bug report belong to?" points to user support groups

Wouter Verhelst wrote: > On Wed, Feb 15, 2012 at 11:12:28AM -0500, Filipus Klutiero wrote: >> Hum, interesting. I am aware that the ITS deals with errors in the >> package given, like when the user does a typo, but I'm not aware >> that one can "knowingly report against an unknown package". Could

Re: Bug#658728: linux-image-3.2.0-1-amd64: No more sound - please reopen

Hi Hans, Hans-J. Ullrich wrote: > I saw this bug was already closed by you. I don't know where you got that impression. Bug 658728 is still open, and there is not a patch available yet. However: [...] > My chipset is ALC 268. Bug 658728 is not likely to be relevant to you --- it's just plain

Re: Summary: dpkg shared / reference counted files and version match

Hi, Jakub Wilk wrote: > How about: > * Because this the obvious and elegant way of doing things. It makes > multiarchification easy for packagers, and invisible for uses, > including those users who don't care about multi-arch (unless they > rely on paths to the libraries, which they never should

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

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

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

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.”).

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

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

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

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 /

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

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: 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

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: 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

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: 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: 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: 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

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: 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

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: 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?

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?

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

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: 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

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

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

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#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#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#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#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#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

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

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

  1   2   >