Re: Release file changes

>> I additionally opened a bug with apt to add support for SHA512SUM, so >> we can start using them. As soon as that is possible I intend to drop >> SHA256 and end up with SHA1/SHA512 only. > Unfortunately, the algorithm used for the GnuPG signatures (both in > InRelease and Release.gpg) is SHA-1.

Re: Release file changes

On 12398 March 1977, Joey Hess wrote: >> until today our Release files included 3 Hashes for all their entries: >> MD5SUM, SHA1, SHA256. I just modified the code to no longer include >> MD5SUM in *all* newly generated Release files. > When will that affect Release files for stable? Next point rele

Re: Release file changes

>>> until today our Release files included 3 Hashes for all their entries: >>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include >>> MD5SUM in *all* newly generated Release files. >> When will that affect Release files for stable? Next point release? >> Because that unfortunatly

Re: Cross-check autobuilt binary pkg with maintainer-provided pkg

>> This is a good reason to forbid source-only uploads, but there is another, >> which actually leverages what we do now, and the idea of not using the >> maintainer-provided binary packages in order to have better determinism on >> the build: > [...] > Sounds like a great idea, yes. > If ftpmaster

Re: The "node" command in Debian

On 12384 March 1977, Jérémy Lal wrote: > 5. nodejs package provides /usr/bin/nodejs, following policy. >nodejs-notrenamed package links /usr/bin/node to nodejs, and conflicts >with node package. And end up with two exactly identical binary packages (except for the filename) in the archive?

Upcoming FTPMaster meeting

Hello world, i just want to take the opportunity that everyone is watching the final preparations for Squeeze to announce our next FTPMaster meeting. Your beloved team of FTPMasters will meet from the 21st til 27th of March in the LinuxHotel in Essen. During the weekend one of the wanna-build admi

Re: how to communicate removals (Re: squeeze will have googleearth-package

>> So we should push the "removals from testing / additions to testing" mails >> to -devel instead of -testing-changes? Now that we're in freeze? > probably an extra section in the DPN during freezes would be quite useful > indeed, cc:ing -publicity for input. Something for wheezy though :) > S

Planet subscriptions

Hey, below a diff I just committed, removing a number of (dead) feeds from planets config. If you are one of them, feel free to enable your entry again as soon as it is working again, if you know one of them you might want to let them know. And the reasons for the removal is simply that each of t

Re: delegation for FTP Masters

>> As it's painful to track multiple delegation mails for a single group of >> people, I'm (re-)delegating all FTP masters at once. A reference to the >> present delegation will shortly be available at >> . > That's fine, but can you next time please tell us

Re: Bug#598044: ITP: autoconf-dickey -- automatic configure script builder (Thomas Dickey's version)

>>> Yet another autoconf version, as if the four that we already have in the >>> archive weren't enough. :-( But it is needed for ncurses if we ever >>> need to patch configure.in, see #580190. >> And its not possible to fixup the idiot who uses an own autoconf >> version? > Considering that his

Re: Backports service becoming official

>> From what concerns the BTS, Don's proposal in [2] (the main one, not >> the alternative solution) seems reasonable to me and others in the >> thread. The proposal also seems to assume a different Maintainer >> field for the bpo package, as hinted above, am I wrong Don? > Right. The idea here is

Re: A new Priority level, ‘backports’ ? (Re: unstable/testing/[pending/frozen/]stable)

> the addition of new suites has the disadvantage of dispersing our userbase. > Here is a proposition that conserves the current flow of package migration for > packages released in Stable, and that makes Testing the meeting point for all > the packages. > We could introduce a new priority level

Re: Debian ppa

> I still believe that this can and should be implemented. If someone is > interested, I'm happy to help; I assume the same holds for Joerg. True. -- bye, Joerg Yeah, patching debian/rules sounds like changing shoes while running the 100 meters track. -- Michael Koch -- To UNSUBSCRIBE, ema

Re: Any chance to redo an upload to unstable which should have went to experimental? [

On 12233 March 1977, Andreas Tille wrote: > - Forwarded message from Andreas Tille - > From: Andreas Tille > To: debian-devel-chan...@lists.debian.org > Date: Thu, 09 Sep 2010 07:32:12 + > Subject: Accepted gnumed-client 0.8.1-1 (source all) > gnumed-client (0.8.1-1) unstable; urgen

Re: backports.org moved to backports.debian.org

> The backports service still uses its own version of the keyring. Therefore > if you want to put packages onto backports you have to coordinate with the > backports team to have your uploads accepted. Please follow the procedure > outlined in [2]. Support for Debian Maintainers (DM) is expected

Re: backports.org moved to backports.debian.org

> The backports service still uses its own version of the keyring. Therefore > if you want to put packages onto backports you have to coordinate with the > backports team to have your uploads accepted. Please follow the procedure > outlined in [2]. Support for Debian Maintainers (DM) is expected

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

> Aren't the licenses of source files generally documented by upstream, > either by e.g. the COPYING file or inline within the files themselves? > Why is there a requirement to duplicate this information in the > copyright file? Thats certainly a nice dream, but in most cases not reality (having u

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

>> I don't think anyone disagrees with this, including the ftp-masters. The >> question is whether the source package also needs a copyright file of its >> own. > As we are distributing these files, it seems reasonable to document their > licence. But the Policy is not clear about that requiremen

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

>> No. There is no sensible way to do this. The problem is inherent: >> the binary packages in main have to be rebuildable using the source >> package (and supporting binary packages eg compilers) in main. >> If you have this situation you have to have two separate source >> packages; one in ma

Re: RFH: How to compile swf files from source

> In my package ampache it ships xspf_jukebox.fla and xspf_jukebox.swf and > I recently received bug #591202 which states: > "ampache ships a swf file but does not build it from source." > I am curious to know which part of Debian Policy states that this is > required? I have search but was una

Re: constantly usable testing

>> Have you ever actually tried to call people to arms and *form* the CUT >> team? > No. But it's been 3 years, so please don't wait for me to do it. ;) JFTR, with the great new machine ftpmaster got, we actually have the resources to run such a thing (archive wise, manpower is different). That i

Re: Bug#588946: ITP: wacom-source -- Wacom kernel driver in DKMS format

>> Package name: wacom-source >> Version : 0.8.8 >> Upstream Author : Ping Cheng >> License : GPL-2 >> Description : Wacom kernel driver in DKMS format >> This package builds an updated Wacom Kernel Module using >> DKMS. This replaces the out-of-date module inc

Re: ftp-master/release move

>> This affects all archive processing/handling, currently it is all turned >> off. We will inform you when it is back to normal, right now we expect >> this to happen on Sunday. > As a little update: > It looks pretty good and we already did a manual dinstall run. > We did not push the mirrors, t

Re: ftp-master/release move

On 12165 March 1977, Joerg Jaspert wrote: > This affects all archive processing/handling, currently it is all turned > off. We will inform you when it is back to normal, right now we expect > this to happen on Sunday. As a little update: It looks pretty good and we already did a manual

Re: "Waqf" General Public License in Debian?

>> Check again, this is meant for non-free, not main. > Still do not see how this would change anything... well of course rules > may say that we may put anything into non-free if it's distributable,... > but then we need some better rules. Every DD can start a GR to change the rules. To drop non

Re: "Waqf" General Public License in Debian?

On 12164 March 1977, Christoph Anton Mitterer wrote: > I really wonder how this (#579796), especially with such a license can > even be considered for going into Debian (especially seeing it in the > NEW queue yes I know, that this doesn't mean it has already been > acceptet). Check again, this i

Re: "Waqf" General Public License in Debian?

>> The above URL has the license. I think that the concepts in the preamble >> are >> interesting, offering software to please Allah and denying the concept of >> "ownership" of Intellectual Property. > Which is not only non-free in Debian, we can not distribute it. > A software license is not

Re: PGP v3 support dropped from Debian keyring

On 12163 March 1977, Jonathan McDowell wrote: > As announced that the end of April[0] we have dropped support for v3 > keys from the Debian keyring. At present this means debian-keyring.pgp > still exists, but is an empty file. Once we have confirmation from DSA + > FTP master that they have update

Re: broken upload

On 12161 March 1977, Russell Coker wrote: > Below are two messages I have received after attempts to upload a new > refpolicy package. I first tried via FTP but the 3G Internet connection I'm > using gives me a 10.0.0.0/24 address with NAT that doesn't support FTP, so I > ended up with a zero

Re: Essentiality of Bash

> Beyond making dash the default /bin/sh, which has already happened, is it > (still) a long-time goal to make bash not Essential, or did I dream that? > Because if it is, getting there means adding a lot of "Depends: bash" first, > and so Lintian should probably add an exception to the (build-)

Re: ries, AKA ftp-master.debian.org back, status

> When this long uploadqueue process is done I will run a manual dinstall, > closely monitoring the steps taken and after this the ftpmaster service > will be back up normal. And we are all set, all cronjobs of the release and ftp teams are back on now, the dinstall in the night went all nice wit

Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services back this weekend

Hello, as you might have noticed from my mail some days ago or the various updates sent to the -devel list, or maybe even just be the slightly-less activity on our mirrors, our ftpmaster host had been down. And for some reason I said > Will send a notice when service is back to normal. and so he

Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled

> What is it that ftp-master does that can only run on one computer at a time? > If > most of the services it provides could be distributed, you could spread the > load to > multiple machines, and get redundancy at the same time. Thank you, we never thought of that... On 12071 M

Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled

>> Now, should the technician not be able to resurrect ries, our backup >> plan extends to have the disks shipped over and replace the ones >> currently in rietz. > I'm wondering if Debian has the resources (DSA, local admins and > hardware) to have a hot-swappable backup machine for ftpmaster, sin

Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled

On 12065 March 1977, Joerg Jaspert wrote: > ries.debian.org, the host behind ftp-master.debian.org, has hardware > trouble, a failed memory module keeps resetting the machine at random > intervals. > Will send a notice when service is back to normal. And another update for you a

Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled

> ries.debian.org, the host behind ftp-master.debian.org, has hardware > trouble, a failed memory module keeps resetting the machine at random > intervals. We seem to have more than one broken module, as we already asked local admins to take DIMMs out, and then got another random reboot. The suppo

Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled

On 12065 March 1977, Joerg Jaspert wrote: > ries.debian.org, the host behind ftp-master.debian.org, has hardware > trouble, a failed memory module keeps resetting the machine at random > intervals. No, its not fixed, just thought of giving a little update: I did an initial check of s

Re: Bits from the Release Team: What should go into squeeze?

>> From a current point of view squeeze will release with kernel 2.6.32 > Would it be possible to, instead, release with kernel 2.6.33? Thats a kernel team decision. And they have .32, as that is (IIRC) supported not only by Debian but by many other distributions too. (and at some point you just

Re: Invite to join the Release Team

On 12053 March 1977, Luk Claes wrote: > You seem to send the message that you can judge from the sideline how > things should be run, so I hereby invite you to join the Release Team > and do a proper job. > If you don't take the challenge I'll interpret that as you being a > coward who does not d

Re: md5sums files

>> This script signs each file in the package individually, but it could >> also concatenate them all alphabetically and create just one signature. > There have been previous discussions on debian-devel about this. I > believe DAK does not allow packages signed using debsigs to be uploaded. > I'm

Re: [RFC] Collecting changelog entries in projectb

>> FTP team and I are currently writing a new feature in dak which will >> collect changelog entries and store them in projectb, to be later used >> for other purposes (e.g. to write point release changelogs, see [1]). > Isn't this why we have UDD? UDD is the wrong approach. And also, ever looked

Re: upload lost ???

On 12015 March 1977, Norbert Preining wrote: > /maildir-utils_0.6-1_amd64.changes is already present on target host: > maildir-utils_0.6-1_amd64.deb > Either you already uploaded it, or someone else came first. > Job maildir-utils_0.6-1_amd64.changes removed. > So *how* am I supposed to clean up

Re: upload lost ???

> Why didn't I got an email? Because we couldnt parse the changes file -> no mail address -> no mail. (dqueued with "Uploaded to localhost" doesnt care and would blindly mail everyone if just written in Maintainer:. dak does not) > And the reason is according to this file: > no signature fo

Re: Uploads without the architecture-dependant binary packages.

> I found it interesting that a package like git-core is autobuilt on all ports > since at upload time it only contains the source and architecture-independant > binary packages. I like it. I always feel sorry that no build logs are > available for the architecture I use for upload. > Before I sta

Re: Uploads without the architecture-dependant binary packages.

>> Before I start to do the same when possible, is it a bug or a feature ? Both. > That has always been a feature but recently the DAK has changed to throw > away the maintainer build debs (while still requireing them to be > uploaded) and running an autobuild on all archs. Oh, when did that ha

Re: Allow package bug scripts to unconditionally stop reportbug

> But now I'm wondering if there could be a use case of allowing the > scripts to unconditionally stop reportbug, for example using a > "special" exit code (140 f.e.) . 42 would be nicer. Besides, does that mean I just have to put a bugscript in all my packages exiting 42 and those bugs stop flo

Re: Debian vs. Ubuntu source control file

> That's only true with the v3 format. If you stick with v1, you can > patch debian/control at unpack time. > And in both cases, you are free to modify it manually during the build. Err, what? debian/control modified during build? Sure not. -- bye, Joerg anyone from the MIA team around? tbm?

Re: Debian vs. Ubuntu source control file

>>> What do you, folks, think of this case ? >> I would merge the change even if the package doesn't exist. > What about lintian crying in the rain ? More seriously, can we assume > that we'll never have package name collisions (ie. "foo", if exist on > two distributions, are guaranteed to be the

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

>> It would have been MORE than easy to have bz2 support in 1.0. There is >> absolutely no reason why it needs a 3.0 just for a different compression. >> But that wasnt wanted. > By whom? dpkg maintainers, archive admins, package maintainers? > tar.bz2 support is the only reason I see for conside

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

> (Personally, I'm not happy with 3.0 either, I see no sufficient benefit > to use it unless the upstream tarball is a .tar.bz2. It's not cleaner, > lsdiff -z is no different to tar -tzf. However, I will do what I can > to allow 3.0 to work within svn-bp for the few packages that may > benefit.)

Re: duplicate packages in Sources and Packages files

On 11964 March 1977, Lucas Nussbaum wrote: > The result of that change is that the structure of the Sources and > Packages files have changed: before, there was only one version of each > source or binary package in each suite (unstable, testing, stable). There > can now be several versions of the

Re: About repackaging of the ‘orig’ tarball.

On 11960 March 1977, Charles Plessy wrote: > In the following message sent on debian-devel > (<20091209003633.gb29...@kunpuu.plessy.org>), it has been suggested that we > repack upstream original source archives when they contain generated files in > order to ease your work. Can you confirm or inf

Re: Bits from the NM people

> Lets say this package is maintained on Launchpad that also "maintainance" for > debian or would this have to be on mentors.debian.org to be a valid > maintainance? (Just curios as there use to be some discussion between the > bloggers about that some time back) Where it is maintained is irr

Re: Lintian based autorejects

> I've noticed that for DELAYED/XX uploads, the lintian rejects are > triggered not when the package hits DELAYED/XX, but rather when the > package eventually hits the archive. The annoyance of this is that the > uploader losts "focus" on the specific fix. > Any chance/plan to fix this so that li

Re: Lintian checks and debian/copyright boilerplate

On 11933 March 1977, Russ Allbery wrote: > The next upload of Lintian will remove the check for "Author(s)", since > it's very prone to false positives and isn't checking what it's supposed > to be checking. Thank you very much to Manoj for his work on verifying > this tag. Is that the 2.2.18 we

Re: Bits from the FTPMaster meeting

On 11936 March 1977, Charles Plessy wrote: >> source-only uploads > I am curious on how the rebuild of the architecture-independant packages > happens. That depends on what we get out with in the end. Probably all buildds can build arch:all (so the buildd maintainer wants it), and there will be a

Re: Bits from the FTPMaster meeting

On 11935 March 1977, Joerg Jaspert wrote: > NEW/Byhand > -- > Due to the massive changes in the archive, NEW (and also Byhand) had to > be disabled. Certain assumptions made by the processing tools no longer > applied. The last week was used to work on this issue and we th

Re: Bits from the FTPMaster meeting

> Then can you (or someone else) please explain what exactly is meant by the > reference to bzip2 for binary packages in the following quote from the > original mail: > ! You can use either gzip as usual or bzip2 for the compression within > ! the binary packages - and now also for the source fi

Re: Lintian based autorejects

>> Please do. For now, and I think until squeeze or this tag no longer >> visible on lintian.d.o (ie no package affected), whatever comes first, >> this tag is in nonfatal. > I think you shall find that most already have bugs filed. Yes, and I really like that I do not have to do this my

Re: Lintian based autorejects

> I don't think it's appropriate to make, for instance, dir-or-file-in-var-www > instantly fatal without following the usual mass-bug-filing procedure. If > you'd like mass bugs to be filed based on these lintian tags but don't have > time, let me know if I can help (I can't promise to deal with a

Re: debian/rules "make -f" restriction

> Build a standard vdr-plugin-* package: > dpkg-buildpackage -tc -uc -us -rfakeroot > Build a development version of the vdr-plugin-* package from the same > source, but using the API of the development version of VDR and with a > different binary package name: > SPECIAL_VDR_SUFFIX=devel dpkg-buil

Re: debian/rules "make -f" restriction

> Are there any serious objections against just overriding and ignoring > the Linitan warning about not having "make -f" in the shebang line? It is not an overridable error, and I haven't seen any reason yet to convince me to make it one. You do have some reasons, but none I have seen that would

Re: Lintian based autorejects

On 11917 March 1977, Russ Allbery wrote: >> this is probably a question more for lintian maintainers, but... what >> should we do if lintian is buggy and falsely claims our package has >> one of these tags? > The same as what you would do with any other buggy package in Debian: file > a bug. I d

Re: Lintian based autorejects

On 11917 March 1977, Brian May wrote: > On Tue, Oct 27, 2009 at 02:57:35PM +, Simon McVittie wrote: >> - statically-linked-binary > This is not always a bug. e.g. dar-static is supposed to be statically linked! Thats why its a warning only and can be overridden. > My packages produce a n

Re: Lintian based autorejects

>> Those automated rejects will only be done on sourceful uploads to >> unstable and experimental. > Are there any plans to extend this on binary-only uploads? No. Not much helpful to reject buildd packages. -- bye, Joerg Von einem Besucher auf dem LT: Die 3 Microsoft-Leute auf Ihrem Stand müs

Re: Lintian based autorejects

On 11916 March 1977, Frans Pop wrote: > Looks like it's named "nowayout". Thats just because I didnt copy the very latest version of it over to ries. Done now. >> overridden. Those are tags corresponding to packaging errors serious >> enough to mark a package unfit for the archive and should nev

Re: Seeking advice on packaging of pion-net

On 11880 March 1977, Roberto C. Sánchez wrote: > Source: pion-net > Binary: libpion-net-dev, libpion-net-2.1.8, libpion-common-2.1.8, > libpion-net-2.1.8-dbg, libpion-common-2.1.8-dbg, libpion-net-doc > The problem, as I see it, with this arrangement is, that when a new > upstream released, like

Re: Automatic Debug Packages

On 11826 March 1977, Emilio Pozuelo Monfort wrote: > The proposal is (very briefly) to make dak accept .ddeb packages (containing > debugging symbols using build-ids), and to then modify helper tools to > automatically generate them and add them to the changes file. I've written > down > the deta

Re: Can you (re)confirm that packages re-uploaded to NEW are processed according to the date of their first upload?

> The web summary of the queue contents lists the packages by upload date, but I > remember reading from you in a previous discussion that the queue is processed > according to the date of the first upload. Unfortunately, I lost the > reference… > Can you confirm, or can somebody point me at the

Re: The wider implications of stuffing the NEW queue with issues it was not designed for.

On 11815 March 1977, Julien BLACHE wrote: >> Automatic rejection of packages with errors not justified by overrides is of > And what do you do with unjustified overrides? > Or can I just override every lintian test and upload my totally broken > package? The way we currently think about it there

Re: Should we improve our (internal) communication?

>> http://lists.debian.org/debian-devel-announce/2008/09/msg6.html > Thanks for the pointer, but I'm referring to >> the upload queue, is pointed elsewhere during that time, > not to the general reorganization of upload queues announced with that email. It is *exactly* the point of host-indep

Re: Should we improve our (internal) communication?

On 11813 March 1977, Sandro Tosi wrote: > Should we improve how we communicate in the project? Shouldn't there > be more information on what's moving "behind the scenes"? It's just me > that would like to know it? First there wasnt much notice (as people already said), but also second: The thing

Re: mail server broken: are debian reject messages logged ?

On 11813 March 1977, Philipp Kern wrote: > grep 'Subject: ITP:' /org/bugs.debian.org/spool/db-h/NN/NN.summary. If > you want, you could also match up the source package name. > Now you'll say that's not reliable. Maybe not, but a pretty strong indication > and very few misdirected mails won

Re: mail server broken: are debian reject messages logged ?

>> Yes, you can find them on merkel:/srv/ftp.debian.org/queue/reject/*.reason > there are not many files there. Is there a place where the rejection mails to > ‘NEW’ uploads are archived? Otherwise, how about sending them to the package's > ITP bug when available? There is no reliable way to dete

ia32-libs{-tools}, multiarch, squeeze

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello world, (Please remember that we can only speak for ourselves and not the security/release/any other teams, individuals or other sentient beings.) During the recent discussion about about ia32-libs{,-gtk,-tools} there were various requests for r

Re: ia32-libs transition

>>> Will you do security support and regular uploads for it too? Or just a >>> one shot upload? Will you stand against ftp-masters whish to remove >>> it? >> You are actively working with all you can do to not only let us hate it >> but actually consider removing it completly. Good job. > Not bein

Re: ia32-libs transition

On 11797 March 1977, Goswin von Brederlow wrote: > Will you do security support and regular uploads for it too? Or just a > one shot upload? Will you stand against ftp-masters whish to remove > it? You are actively working with all you can do to not only let us hate it but actually consider remov

Re: dupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb

On 11789 March 1977, Mathieu Malaterre wrote: > I had a network issue and had to re-run dupload a second time. Now a > partially *.changes files was updated, and I cannot do anything > anymore: Either wait for the files to time out - or read the README in the directory you try to upload to, loo

Re: RFC: DEP-3: Patch Tagging Guidelines

On 11782 March 1977, Raphael Hertzog wrote: > This is a proposal to formalize a set of meta-information > to be embedded in patches applied to Debian packages. Most > patch systems allow for a free-from description preceeding > the content of the patch and the plan is to make use of that > space t

Re: Let’s turn DEP5 into something useful

On 11780 March 1977, Josselin Mouette wrote: > So, how about dropping entirely anything that’s related to files and > only keep the amount of information we are requiring now? I feel sorry > for the giant bikeshedding thread about spaces and commas, but it is not > getting us anywhere. You mean

Re: Transitions Completed

On 11759 March 1977, Adeodato Simó wrote: > + Frans Pop (Thu, 21 May 2009 20:54:22 +0200): >> > From: Debian Installer >> Although this usage probably predates D-I, I do find it quite confusing in >> practice, and for example when googling, that we currently have two >> completely unrelated usa

Re: deprecating /usr as a standalone filesystem?

>> So, does anybody still see reasons to continue supporting a standalone >> /usr? > There had been lots of responses to that. > You havent presented any supporting your request, so why do you > want it? Please provide a detailed real-world case. A partial list of > invalid reasons is: - "Some up

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

On 11742 March 1977, Luk Claes wrote: > Maybe we should also consider changing the default MTA to postfix? As much as i like postfix and hate exim: no. If we change, please go to something like nullmailer|ssmtp|whateversimple. -- bye, Joerg joshk: okay. I've manned a Debian booth before. I n

Re: deprecating /usr as a standalone filesystem?

On 11741 March 1977, Marco d'Itri wrote: > So, does anybody still see reasons to continue supporting a standalone > /usr? There had been lots of responses to that. You havent presented any supporting your request, so why do you want it? Please provide a detailed real-world case. A partial list o

Re: ITP: developers-reference-es -- Spanish translation of the Debian Developers' Reference

On 11737 March 1977, Leandro Doctors wrote: > * Package name    : developers-reference-es >  Version         : 3.4.1 >  Upstream Author : Andreas Barth, Adam Di Carlo, Raphaël Hertzog, > Christian Schwarz, Ian Jackson > * URL             : http://www.debian.org/doc/developers-reference/* License  

Re: ITP: developers-reference-es -- Spanish translation of the Debian Developers' Reference

On 11737 March 1977, Leandro Doctors wrote: > * Package name    : developers-reference-es >  Version         : 3.4.1 >  Upstream Author : Andreas Barth, Adam Di Carlo, Raphaël Hertzog, > Christian Schwarz, Ian Jackson > * URL             : http://www.debian.org/doc/developers-reference/* License  

Re: Can we ship sources of a PDF file in the Debian diff?

On 11735 March 1977, Charles Plessy wrote: > +If you think your package needs some explanations for the administrators of > the > +new package queue, include them in your changelog, reply to the email you > +receive as a maintainer after your upload, or reply to the rejection email in > +case you

Re: Can we ship sources of a PDF file in the Debian diff?

On 11734 March 1977, Andreas Tille wrote: >How to address the fact that a rejection issue is solved now? Reply to the rejection mail *or* have a changelog entry "fixed lalala as mentioned by ftpmaster". -- bye, Joerg Free beer is something that I am never going to drink and free speech is s

Re: Can we ship sources of a PDF file in the Debian diff?

On 11734 March 1977, Charles Plessy wrote: > In my profession we often say “The person who does not make mistakes usually > does not do any work at all.”, so it is fine with me. Can I re-upload a > version > for main that you would fast-track to resolve the issue? > Also, can you tell us where t

Re: Can we ship sources of a PDF file in the Debian diff?

> If you ask me things are quite clear: From a Debian point of view the > source includes *.orig.tar.gz, *.dsc and *.diff. The files are connected > via md5sum in *.dsc. So shipping the source of a PDF in the diff should > be acceptable from a Debian point of view (even if it would be nice to >

Re: Bug#525192: ITP: vtg -- Vala Toys for gEdit

>>> * Package name    : vtg >>>   Description     : Vala Toys for gEdit >> The package name doesn’t sound really helpful. How about something like >> gedit-plugins-vala? > I fully agree. However, upstream name is vtg. I am not familiar with > policy about upstream package name, and whether we can

Re: Location of Packages and Translation files seem to have changed since yesterday

On 11714 March 1977, Andreas Tille wrote: > Moreover I noticed that the translation files I obtained from >http://ftp.de.debian.org/debian/dists/sid/main/i18n/ > are not available as gz any more but only as bz2. Yes. It made no sense to ship the others and the uncompressed files too, no known

Re: Location of Packages and Translation files seem to have changed since yesterday

On 11714 March 1977, Martin Bagge wrote: >>This FTP server belongs to Academic Computer Club, Umeå >> University. Technical information is available here. > because that's true. ACC is the sponsor of ftp.debian.org. No its not. It is one site that hosts a Debian mirror. And it is one site tha

Re: New architectures

On 11711 March 1977, Vincent Bernat wrote: > How packages that run on Linux only should handle those new architectures? The same as with any other portability problem. Either fix it, or if it really doesn't work out mark it as such. P-a-s is one way for it. -- bye, Joerg I've annoyed Ganneff e

Re: NEW processing

> You're right, in hindsight this wasn't a good idea, but then we knew we still > had time until the announcement would come out and the debug package had > already been added to SVN. There is also *always* the way to ping us if there is something special. Either by mail or on irc, explaining the

Re: NEW processing

On 11700 March 1977, Changwoo Ryu wrote: >> IMHO, except package with just SONAME bump, packages in NEW queue are >> better processed in a FIFO manner. Just my two cents. > OTH, do we really need a manual check for SONAME bump? Was there any > upload rejection in the past on new binary package ad

Re: Proposal: Enhance requirements for General resolutions

> Seconded. Please follow the mail headers in the original mail and send this to the place where vote stuff belongs: debian-v...@lists.debian.org. That is, if you want it to count anything. :) -- bye, Joerg [2.6.15.4 direkt nach 2.6.15.3] Linus muss Gentooler hassen. wieso? Naja, die dürfte

Re: Sponsorship requirements and copyright files

First, let me apologize for my last mail in this thread, it had been a little too rude/harsh/direct. My fault, sorry. (We all should calm down, flaming won't help) On 11696 March 1977, Russ Allbery wrote: > Joerg Jaspert writes: >> We require, and have seen nothing to convince us o

Re: Sponsorship requirements and copyright files

>> No. It is not up to the Debian maintainer to decide that some >> contributor has written enough of the code to also be mentioned in the >> (C) lines in a particular file. But as soon as upstream lists them >> either in a file header or the AUTHORS file the Debian maintainer has to >> copy that

Proposal: Enhance requirements for General resolutions

Hi, I have felt for some time that the low requirement for seconds on General Resolutions is something that should be fixed. Currently it needs 5 supporters to get any idea laid before every Debian Developer to vote on. While this small number was a good thing at the time Debian was smaller, I thi

<    1   2   3   4   5   6   >