Re: ppc64 not in any-powerpc ?

On 12/09/14 10:48, Mathieu Malaterre wrote: > I could not find the answer anywhere. Why is arch:ppc64 not in the > `any-powerpc` definition ? I would have guessed arch:ppc64 to be very > close to arch:powerpc... That would be like making any-i386 include (linux-)amd64 or (linux-)x32, which we don'

Re: Trimming priority:standard

common enough to appear in priority standard. +1 Right now rpcbind is listening on the network in a default jessie install, and I don't like that. /Simon signature.asc Description: PGP signature

Re: PackageKit cleanup: Do you use these functions?

On 12/09/14 12:43, Matthias Klumpp wrote: > Now, if the user reboots, the system enters a special mode where > updates are installed using PK (progress is shown on Plymouth), then > it reboots again and enters the desktop. I've done some work on a similar feature for unattended-upgrades

Re: PackageKit cleanup: Do you use these functions?

On 12/09/14 14:29, Simon McVittie wrote: > In an ideal world libraries wouldn't break > ABI either, but they do; in an ideal world libraries and applications > wouldn't have security flaws that need stable-updates, but they do. As > much as I'd like people to impleme

Re: Trimming priority:standard

On 12/09/14 14:56, Theodore Ts'o wrote: > What if we create a tasksel > task called "Unix" that installs these traditional Unix commands from > the BSD 4.x era? It would include dc, m4, /usr/dict/words, telnet, > etc. I was just about to suggest that myself. at, cron, an MTA, and locate seem good

Re: Trimming priority:standard

On 12/09/14 18:19, Theodore Ts'o wrote: > One thought... there will probably be trademark concerns with "unix".[1] > So we might have to choose a name for the tasksel task to be someting > like "unix-like". Perhaps task-traditional -- Traditional Unix utilities ? Or Un*x if you're that worri

Re: Proper notation for common licenses

On 22/09/14 17:15, Markus Koschany wrote: > A while ago I have started to use this > format [1] for common licenses when I saw that fellow maintainers did > the same. > > [1] Examples: > > License: GPL-2+ > On Debian systems, the complete text of the GNU General Public > License version 2 can be

Re: Proper notation for common licenses

On 22/09/14 18:48, Jonas Smedegaard wrote: > Quoting Markus Koschany (2014-09-22 19:25:20) >> Version 1: >> >> License: GPL-2+ >> This program is free software; you can redistribute it and/or [...] >> This program is distributed in the hope that it will be [...] >> You should have received a copy

Re: Proper notation for common licenses

On 23/09/14 09:01, Joachim Breitner wrote: > (Although I find that unfortunate, and makes me much less motivated to > find out whether a license that looks like a BSD license is actually > one of them on the list, if I still have to include it in the file.) There are enough subtly different varian

Re: Seeking help with OpenVPN scripts and systemd

On 24/09/14 11:45, Martin Wuertele wrote: > Last time I used n-m for OpenVPN it could only launch one VPN, not > multiple ones. Has that changed? Yes, I've had home and office VPNs up at the same time. (Obviously if you have more than one VPN that wants to provide the default route, or more gener

Re: versions / suffixes in experimental

On 25/09/14 08:16, Daniel Pocock wrote: > > Is there any convention for version numbers in experimental? > > E.g. when uploading to backports, we add a suffix like "A.B.C~bpo70+1" > so that the system can cleanly upgrade to version A.B.C when upgrading > to the next stable release. > > I have a

Re: versions / suffixes in experimental

On 25/09/14 13:21, Henrique de Moraes Holschuh wrote: > On Thu, 25 Sep 2014, Simon McVittie wrote: >> Approach 1, which is (IMO) better when the changes you are making in >> experimental are truly experimental, like enabling features or patches >> whose medium-term future

Bug#763273: ITP: responses -- A utility library for mocking out the `requests` Python library.

Package: wnpp Severity: wishlist Owner: Simon Chopin * Package name: responses Version : 0.2.2 Upstream Author : David Cramer * URL : https://github.com/dropbox/responses/ * License : Apache 2.0 Programming Lang: Python Description : Utility library

Re: bash exorcism experiment ('bug' 762923 & 763012)

On 02/10/14 17:30, shawn wilson wrote: > I'm pretty sure dash never got a rewrite? So this just happened to be > a "feature" that got ripped out of dash. You seem to be under the impression that dash is some sort of fork or derivative of bash. It isn't; I don't think they even have a common ancest

Re: Tests running as (real) root?

On 12/10/14 22:29, Svante Signell wrote: > setuid has worked for ages. For example how many X servers have been > compromised the last 30 years? Apart from via , ,

Re: question about versioned dependencies in debian/control

On 22/10/14 14:58, Harald Dunkel wrote: > Depends: ... git-man (>> ${source:Upstream-Version}), > > git (1:2.1.2-0~xgo70+1) unstable; urgency=low 1:2.1.2-0~xgo70+1 is less than 1:2.1.2, because 1:2.1.2 is equal to 1:2.1.2-0 in version number order, and 0~x is less than 0. You can confirm th

Re: Debconf code for getting usernames list

On 23/10/14 11:50, Nikos Andrikos wrote: > What is the proper way to check that each member of the $RET list is a > valid username and if not prompt the user to specify a new correct > list? This might be helpful: # usage: if is_username_valid root; then echo yes; fi is_username_valid () { ge

Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)

On 29/10/14 12:08, Ian Jackson wrote: > The contents of the default ignore > list is in dpkg-source, but it is not enabled unless the caller says > -I. git-buildpackage passes -I. To be completely clear (because I misread it twice in a row), you mean that it is not enabled unless the caller uses

Re: Arch-dependent files in /usr/share

On 02/11/14 18:42, Andreas Barth wrote: > (I however also don't think that this is pretty bad, but of course it > is a FHS violation, and should be fixed.) For Multi-Arch: foreign or non-Multi-Arch packages, I don't personally think this should be considered priority > normal, or (unless it's utte

Re: systemd - suggestions for the next version

On 03/11/14 14:36, Hans wrote: > My system has /, /boot, /home, /usr and /var on seperated partitions. > The partitions /home, /usr and /var are luks-encrypted. Encrypting '/usr' but not '/' doesn't make a great deal of sense; '/' contains critical system libraries (in /lib), system account detail

debootstrap and cdebootstrap vs systemd

o create a root file system using debootstrap is IMO a rather central feature of the Debian distribution, and I'd prefer not to give it up. I don't have a lot of time in the coming months, but I could probably clear a weekend. Would it make sense to organize a meeting (Linuxhotel?) to

Re: Bad weather in testing ?

On 07/11/14 16:15, Ralf Treinen wrote: > There is only one package in the "each" category, and this is a false > positive due to multiarch: lib32nss-mdns, which exists only on amd64 > (this is why it shows up in the each category) and depends on an i386 > package, which is deliberate in this case.

Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936

On 09/11/14 08:21, Ben Finney wrote: > * Package name: xkcdpass ... > A flexible and scriptable password generator which generates strong > passphrases, inspired by XKCD 936: Does this have significant advantages over pwqgen, in the passwdqc package? How many bits of entropy does

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

On 09/11/14 13:53, Kaj Ailomaa wrote: > So, who determined that audio group will not be used as a default user > group in Debian As far as I know, nobody yet. Marco was expressing what he thinks should happen in future, not what has happened already. I agree with his opinion on this. > and when y

Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936

On 09/11/14 14:25, Clint Byrum wrote: > With that, I have to remember that Nobody is capitalized, and that the > spaces are replaced by $ and 5. The other approach accepts that we are > forgetful and so uses spaces. But it also has the weakness that if the > approach and the separators are suspecte

Re: Please more fish (was: so long and thanks for all the fish)

ion is whether we're running on a server, desktop or laptop system, which basically limits us to starting programs on conditions because we cannot really define a one-size-fits-all power policy. Simon [1] https://joeyh.name/blog/entry/a_programmable_alarm_clock_using_systemd/ -BEGIN PGP SIG

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

On 09/11/14 23:34, Christian Hofstaedtler wrote: >>> On the other hand, it would break typical uses of using sound remotely. >> >> This usually happens via UPnP or similar, though - the actual audio is >> ultimately done by a local user. So the audio group is unrelated to this >> usecase. > > It v

Re: Bad weather in testing ?

On 09/11/14 08:38, Ralf Treinen wrote: > On Fri, Nov 07, 2014 at 06:11:45PM +0000, Simon McVittie wrote: >> On 07/11/14 16:15, Ralf Treinen wrote: >>> There is only one package in the "each" category, and this is a false >>> positive due to multiarch: lib3

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

On 10/11/14 02:59, Christian Hofstaedtler wrote: > I vaguely remember PolicyKit being involved in the daemon situation, > when mpd tries to talk to a pulseaudio server which magically gets > spawned PolicyKit is typically (only?) used when a less-privileged process, typically a user interface, com

Re: free choice in installer?

On 10/11/14 10:15, Michael Ole Olsen wrote: > If there was a choice in the installer for Init system > and boot loader there would be nobody complaining. If I had to choose an init system and a boot loader during the normal installation flow, I'd complain. Options have a cost, forcing a user to an

Re: Removing duplication: Word lists of common words in languages

On 10/11/14 23:16, Ben Finney wrote: > To avoid duplicating these “the N most common words, ranked by > frequency, for language FOO” For a password generator you ideally want the word-list to be sorted alphabetically, so that it's trivial to verify "by eye" that there are no duplicates. Duplicate

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

On 11/11/14 13:04, Felipe Sateler wrote: > I'm not sure if it is PolicyKit or a related service (old documentation > suggests it was ConsoleKit, nowadays it should be logind?), but /dev/snd/ > * get ACLs added for the currently logged in users Yes, that's exactly what I said a couple of mails ago

Re: r-base-core upload to unstable does not respect freeze policy

On 11/11/14 15:55, Ian Jackson wrote: > perhaps we should in general make more use of testing chroots for RC > bugfixes to testing during the freeze. For build-time dependencies, I'm not sure that actually helps very much: the buildds for unstable take build-dependencies from unstable. If you int

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

On 12/11/14 05:54, Mathieu Parent wrote: > Also, the vendor/* branches heads should be at a descendent commit of > the corresponding upstream branch, diffing only by the debian dir. This is only true for workflows similar to the one normally used with gbp-pq, in which desired patches are serialize

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

On 12/11/14 13:38, Matthias Urlichs wrote: > IMHO there are two basic approaches which are mostly at odds with > each other. I think there are at least three. > Two: Treat Upstream tarballs as Source Code; if Upstream generates > them from git-or-whatever, that's not our problem. Use a script to

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

On 12/11/14 14:12, Ian Jackson wrote: > Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging > repositories"): >> In the gbp-pq world, after "git checkout debian/sid", hello.c would >> contain "hello, world", but there wou

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

On 12/11/14 22:07, Ron wrote: > I am also interested to hear more > about whatever the confusion was you had with this was when you > started working with Tollef's systemd repo that you mentioned > in the previous thread. Having played with gitpkg some more, I'm reminded that the answer to this is

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

On 13/11/14 14:04, Ron wrote: > I really do think that the names of the branches are actually going to > be the least of your worries here, unfortunately. Even with a naming > scheme that's widely adopted, things just aren't going to be that sort > of uniform outside of (a fairly large number of)

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

On 17/11/14 16:24, Ian Jackson wrote: > I don't think this problem, of a mass of different branch structures, > is going to go away any time soon. Simply because people don't seem > able to agree. > > My answer is to create a parallel universe in which the branch > structure is known. As far as

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

On 18/11/14 07:20, Guido Günther wrote: > Note that nothing withing gbp forces you to use gbp-pq. I know; but the gbp-pq-like repository structure, as produced by git import-dsc with no special options, is a popular one (pkg-perl and their > 3000 packages, as well as smaller teams like -telepathy,

Re: Pre-Depends: init-system-helpers

On 18/11/14 02:02, Bob Proulx wrote: > Here it is said update-rc.d does not respect policy-rc.d but I think > maybe that should have been invoke-rc.d since update-rc.d just sets > things up to start while it is invoke-rc.d that actually does it. invoke-rc.d is the only thing that *does* respect po

Re: init system policy

On 18/11/14 18:27, Henrique de Moraes Holschuh wrote: > Failing to address this would be a severe regression, of the kind that > introduces a security hole. I can see the functional regression ("minidlna is running as a totally unprivileged user now, and can't read my music any more!") but not the

Re: init system policy

On 18/11/14 19:21, Eric Valette wrote: > I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO being > defined in an default/package file parsed by EnvironmentFile= does not > seem to work as documented in man pages To be clear, the environment variable substitution in systemd units'

Re: policy regarding redistributable binary files in upstream tarballs

On 19/11/14 19:19, Salvo Tomaselli wrote: > Generic question. In my experience some upstream include some redistributable > binary files. For example some binary stuff to create a .app on osX, minified > javascript, and whatever. ... > - these files are redistributable, so there is no legal probl

Re: Pre-Depends: init-system-helpers

On 19/11/14 19:41, Jonas Smedegaard wrote: > Example: if a logrotate snippet uses "update-rc.d force-restart ..." > then suppressing that deamon with policy-rc.d will be circumvented when > cron triggers log rotation. If it uses "update-rc.d force-restart" then it will fail, because that isn't a

Re: [pkg-lighttpd] Changing the default document root for HTTP server

On 17/04/12 03:46, Paul Wise wrote: > What if the sysadmin chose to use > /srv/http/east-coast/foo.bar.org.vhost/ for the foo.bar.org vhost? Can > they still use suexec? Not the normal version, no, because suexec hard-codes the top directory /var/www as a security measure (you can never use it to

Re: Intend to transition openjpeg 1.5

On 18/04/12 12:51, Mathieu Malaterre wrote: >> Intention to do what? > > Move the package from experimental once buildd are ok to unstable and > then testing... This is a transition. Before starting a transition, open a release.debian.org bug asking the release team to schedule it, and wait for a

Re: wine-unstable in Debian

On 15/04/12 15:04, Ben Hutchings wrote: > On Sun, 2012-04-15 at 19:32 +0600, Andrey Rahmatullin wrote: >> On Sun, Apr 15, 2012 at 01:18:28PM +0200, Petr Baudis wrote: >>> I am rather dazzled that while there is working source package >>> of wine-1.5 ready, other people are working on gradually >>>

Re: Bug#669647: ITP: hurd-cvsfs -- CVS virtual filesystem for the GNU Hurd

On 23/04/12 10:20, Samuel Thibault wrote: > [Hurd has] an incomplete procfs already. It doesn't have /proc/mounts, > because it's not a trivial thing to implement: since mounts are > distributed, there is no central place where filesystems are to be > recorded. For what it's worth, the same is tr

Re: wine-unstable in Debian

On 27/04/12 09:38, Goswin von Brederlow wrote: > Steve Langasek filed patches > for all the packages Ubuntu needed as multiarch. Look for the patches in: > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=multiarch-de...@lists.alioth.debian.org;tag=multiarch It seems that the multiarch tag ha

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

On 30/04/12 15:21, Goswin von Brederlow wrote: > With libfoo being in /usr/lib// any endian dependent data > should be in /usr/lib/// or /usr/lib/ tuple>// (sorry, did we pick one of them as standard yet?), > which is usualy a configure option. I think you mean /usr/lib// for the second option? I

Re: Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)

On 04/05/12 21:45, Andres Mejia wrote: > On May 4, 2012 4:43 PM, "Fabian Greffrath" > wrote: >> >> > libav -> x264 -> libav >> >> AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared >> library. So theortically (!) this issue could be solved by two

Re: [Pkg-javascript-devel] Node.js and it's future in debian

On 07/05/12 19:41, Philip Hands wrote: > The -legacy was meant > to be an attention grabber, and perhaps to reflect a hope that at some > point in the future one or both upstreams might switch to a better name. I think "legacy" is rather misleading, since its upstream (unfortunately) doesn't think

Re: Licenses not in /usr/share/common-licenses

On 08/05/12 16:23, Russ Allbery wrote: > I think the core question is: why is base-files special? Yes, it's > essential and all, but that doesn't address the case of packages being > downloaded separate from Debian, or unpacked by hand, in which case we > don't include a license. Binary packages

Re: upstream shared library major versions

On 10/05/12 01:04, Brian May wrote: > Should I be changing > the library name from libdar64-5 to libdar64-5000? Or does this change > reflect some sort of misunderstanding in how library versions work? Given that he doesn't understand "why libtool sets the first digit to current-age (5000 instead

Re: amd64 as default architecture

On 22/05/12 19:24, Sven Joachim wrote: >> On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote: >>> We have still some software that doesn't work with 64-bit kernel, >>> and (worse!) some maintainers claiming it's not a bug. > The most prominent example is probably virtualbox (#456391) That

Re: this bug .. bugs me

On 05/06/12 16:52, Joey Hess wrote: > This bug is a textbook example of making the perfect the enemy of > the good. Yes, pretty much. On the bright side, multiarch and a modern Wine version have both arrived (Wine 1.4 is admittedly only in experimental right now, but I hope it'll reach testing bef

DUCK -the Debian Url Checker

and the results are displayed. Maybe this is of some use for some maintainers and/or developers. One can also search for specific maintainers. Please tell me what you think about it - I have already some more features planned. Regards, Simon signature.asc Description: OpenPGP digital signature

Bug#676859: general: Switch from ethernet to wifi connection problem

Package: general Severity: important Tags: upstream Initial situation : I am connected to the internet by using an ethernet connexion. I use IPV4. When I switch to a wifi connection (by using nm-applet) : - I have a correct IP - I can't resolve domains - As root, when I ping a domain : "ping send

Re: Lets (eventually) find a good solution for /tmp

On 11/06/12 15:01, Aneurin Price wrote: > as far as I am aware a swap file is the better > choice in virtually all situations Assuming is still current: If you want to use hibernation (suspend-to-disk), you need roughly[0] as m

Re: DUCK -the Debian Url Checker

On 06/11/12 21:08, Axel Beckert wrote: > Hi Simon, Hi Axel, > > Simon Kainz wrote: >> as I had some problems in the past finding upstream sources and >> homepages, I hacked up some scripts to monitor and display the results >> of the Upstream Homepage entries i

Re: Is it me or virtualbox memory management crap?

On 13/06/12 13:46, Thomas Goirand wrote: > Writing to my disk is normally quite > fast, but I've noticed indeed that when it's VB that does it, it's slow. > If I don't find a way, I guess I'll switch back to Xen with NAT... No opinion on VirtualBox, Xen or performance thereof, but kvm is also an o

Bug#677522: ITP: alot -- Text mode MUA using notmuch mail

Package: wnpp Severity: wishlist Owner: Simon Chopin * Package name: alot Version : 0.3.1 Upstream Author : Patrick Totzke * URL : http://github.com/pazz/alot/ * License : GPL-3 Programming Lang: Python Description : Text mode MUA using notmuch mail

Re: Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze

On 25/06/12 06:07, YunQiang Su wrote: > 1. upload 2.0 to experimental, and unstable users should install it manually. This is usually the right answer: if version 1.0 is intended to go in the next Debian release, it should get as much testing as possible, which means it should be the default for u

Re: File naming of scripts in /etc/init.d

On 25/06/12 14:47, Roger Leigh wrote: > On Mon, Jun 25, 2012 at 01:51:36PM +0200, Steve R. Petruzzello wrote: >> PS: Is there a way to list all packages putting a file in /etc/init.d/? > > dpkg -S $(ls -1 /etc/init.d/*) Or if you want the complete set, not just those you have installed, install

Re: cross-build-essential

On 28/06/12 10:17, Goswin von Brederlow wrote: > Say I want to have the build-essential for i386 installed on amd64. > I could install build-essential:i386, replacing gcc/g++:amd64 with > gcc/g++:i386. Wouldn't that give me everything needed to cross-compile > for i386? For evolutions of the same

Re: cross-build-essential

On 28/06/12 10:43, Svante Signell wrote: > The situation is even more complicated if compiling for different OSes: > Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or > Hurd:i386. Any plans to support such combinations with > cross-build-essential? It shouldn't differ from compi

locking system users on package removal

On 30/06/12 13:24, Stephan Springl wrote (on Bug #679642): > quake-server does neither install nor purge properly on systems > without shadow password because usermod gives an error for its > e option in this case. I took this use of usermod from the discussion on debian-devel regarding Policy bug

Re: Bug#679853: general: Too much downtime during a big dist-upgrade - avoidable with snapshots

On 02/07/12 15:27, Alexander E. Patrakov wrote: > The quoted solution is easier and it > seems to work well enough. But for some reason, freedesktop folks > invented this for desktop systems: > http://fedoraproject.org/wiki/Features/OfflineSystemUpdates . I think you mean "Fedora folks". freedeskt

Re: bits from the DPL: June 2012

On 04/07/12 16:17, Jakub Wilk wrote: > * Stefano Zacchiroli , 2012-07-03, 21:24: >> Since [OIN][19] was seeking comments on their [Linux System >> definition][12] [...] > Why do we care? What's the point of such definition? "Patents owned by Open Invention Network® are available royalty-free to an

Re: Moving changelog and copyright files to control tarball, or merging control and data tarballs ?

On 14/07/12 01:48, Charles Plessy wrote: > This would not prevent dpkg to store the metadata somewhere else than > /var/lib/dpkg later, as it would be easy to intercept the files and treat them > appropriately, similar to what is being done with files in usr/share/doc with > multi-arch packages. /

Re: Multilicense `debian/copyright` file

On 14/07/12 07:25, Craig Small wrote: > Have a look at src/dataset/unsigned.Set.cc: > > [...] you can redistribute it and/or modify it under the terms of > the GNU Library General Public License [...] > > I have no idea why they have parts of the C library in the source code. The extra permissio

Re: CD sizes again (and BoF reminder!)

with --force-unsafe-io during installation; syncing is unnecessary in this context and can slow things down quite a bit (closes: #605384). -- Simon Paillard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120721224210.gj5...@glenfiddich.mraw.org

Re: Low acceptance of Elektra

cannot find any projects making use of it. Is there any effort in patching some of the major services to make use of libelektra? As far as I know Tizen is using elektra in it's 1.0 version (which includes debian packages for it in their repositories as well). regards, Simon -- Simon B

Re: node-like file conflicts

Ian Jackson wrote: > So, Simon, if these puzzle names should be qualified to make them more > unique on the PATH, what formulaic change should be made ? My > recommendation would be "sgt-*" on the grounds that that's unlikely to > conflict, although it might of cours

Re: Minified javascript files

e seems rather common. Maybe a lintian check could alarm packagers of this? See below for a list of *.dll files in packages starting with 'a' only. Overall, I found *.dll files in around 131 packages (of course not all of those represent a problem). /Simon ./abe_1.1.orig.tar.gz:ab

Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?

On 17/08/12 10:07, Ivan Shmakov wrote: > Unsurprisingly, all of them were able to install and run, but > while openteacher is seemingly unaffected by the absence of the > data in question, the rest have had obvious issues: almost all > of the icons were absent, resulting in

Re: Minified javascript files

bian Wheezy a reliable minifier. That seems problematic -- so even if the source is shipped, there is no way to re-build the minified file? /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boi64ut2@latte.josefsson.org

Re: Minified javascript files

Pau Garcia i Quiles writes: > On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson wrote: > >>> As for >>> verification, having the source next to the minified version does not >>> guarantee anything about the minified version, all the more that we >>&g

Re: Enabling uscan to simply remove files from upstream source

emove empty directories over using the find-approach above, if my proposal is not adopted. Thanks for doing this, I believe that having an easy way to remove files from upstream packages will save Debian package maintainers time and frustration. /Simon -- To UNSUBSCRIBE, email to debian-dev

Re: Enabling uscan to simply remove files from upstream source

Andreas Tille writes: > On Tue, Aug 21, 2012 at 01:25:26PM +0200, Simon Josefsson wrote: >> How about resolving the empty directory problem by permitting the >> Files-Excluded to match directories? Thus, if you want to remove the >> docs/source/fonts/ hierarchy, yo

Re: Minified javascript files

s attention (even from Yahoo for YUI). What is upstream jQuery using? Is it free software? /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d32jay22@latte.josefsson.org

Re: Proposal: Making Debian compiler agnostic

On 28/08/12 16:54, Mathieu Malaterre wrote: > On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre wrote: >> At least from cmake point of view, a user need to provide an env var >> 'FC' for the fortran compiler and sets 'FLAGS'. > > Missing one 'F', it should read 'FFLAGS' Unfortunately, this isn'

Re: uscan enhancement take 3: script hook

On 29/08/12 07:55, Andreas Tille wrote: > When trying to get rid of some get-orig-source > scripts I noticed that besided some file removals I need to execute > some extra code. This is basically fetching some extra files like > sources for documentation, uncompressed JS files etc from external >

Re: Proposal: Making Debian compiler agnostic

On 29/08/12 09:22, Sylvestre Ledru wrote: > Le 29/08/2012 10:00, Simon McVittie a écrit : >> Autoconf 2.69 in sid documents support for: >> [some languages] > > Great list. You constructed yourself or it is part of the autoconf > documentation ? Both. :-) It's

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On 31/08/12 04:39, Serge wrote: > thus it reduces flexibility, breaking use cases, that were working before. Please name them. "The ability to mount my /usr requires user interaction via a UI in /usr" doesn't count, because it has never worked, and is logically impossible. > For example if filesy

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

On 08/09/12 08:08, Dmitry Smirnov wrote: > Often some development libraries are not available on all architectures > in which case maintainer should know beforehand which architectures may > satisfy this dependency and maintain an up-to-date list of architectures > for such packages, like in the fo

Bug#687258: ITP: mpdris2 -- media player interface (MPRIS2) bridge for MPD

Package: wnpp Severity: wishlist Owner: Simon McVittie * Package name: mpdris2 Version : 0.2+git2012.08.14 Upstream Author : Jean-Philippe Braun, Mantas Mikulėnas * URL : https://github.com/eonpatapon/mpDris2 * License : GPL-3+ Programming Lang: Python

Re: "X-" Prefixes deprecated by RFC 6648.

> standards track? What RFCs are you thinking of? The "X-" stuff was removed from e-mail standards long time ago, IIRC. /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.

Re: "X-" Prefixes deprecated by RFC 6648.

Christoph Anton Mitterer writes: > On Thu, 2012-09-13 at 10:18 +0200, Simon Josefsson wrote: >> What RFCs are you thinking of? The "X-" stuff was removed from e-mail >> standards long time ago, IIRC. > Well I don't have all RFCs in mind,... but weren'

Re: Bug#687624: ITP: libdvdcss-pkg -- automated installer for libdvdcss

On 14/09/12 13:09, Thomas Koch wrote: > From my head I know these similar packages: flash-installer-nonfree, some > microsoft fonts downloader, java-package (for sun's java), ...? game-data-packager, although that one is a bit different: it supports a relatively large number of game-data packages

Re: ${HOME} vs. g_get_home_dir ()

On 26/09/12 17:12, Ivan Shmakov wrote: > (Want to use the > all-defaults configuration for a program? Just start it like: > $ HOME="$(mktemp -dt -- foo.)" foo) Debian's GLib has been patched, and actually has this precedence: G_HOME > getpwent > HOME. This was originally inten

Re: ${HOME} vs. g_get_home_dir ()

On 26/09/12 18:15, Ivan Shmakov wrote: >>>>>> Simon McVittie writes: > > Please research previous discussion to check that you're not missing > > arguments that have happened in the past, > > Any particular pointers? Following the git hist

Re: jessie release goals

On 13/05/13 18:26, Stephen Kitt wrote: > Yes, but that's not the problem. Take the premise that the target > directory structure is as described above, so most library > development packages ship as many headers as possible in > /usr/include. For now we'll assume all mingw-w64-...-dev headers > are

Re: Web ID as passwordless authentication for debian web services

On 16/05/13 16:42, Russ Allbery wrote: > In essence, [WebID] > moves the authentication problem from user authentication to > URI endpoint authentication, under the theory that we already know how to > validate URI endpoints and that such validation is an easier problem. ... or to look at it anoth

Re: Do opaque struct changes break C library ABIs

On 17/05/13 10:43, Chow Loong Jin wrote: > On 17/05/2013 13:17, Guillem Jover wrote: >> I agree dlopen()ing shared libraries in general should not be >> supported (I'd even go further and say this should be outright >> banned, given the pain it causes, and optional library support >> should always

Re: WebID as passwordless authentication for debian web services

On 17/05/13 17:36, Olivier Berger wrote: >> The only way to prevent this attack in WebID that I see is to either do >> leap-of-faith permanent caching [...] or >> to secure the connection to my identity URI. > > I wonder how OpenID, for instance, is supposed to resist to such > attacks, in compari

Re: simplifying running piuparts

On 21/05/13 10:48, Andreas Beckmann wrote: > @all maintainers: How would you like to run piuparts s.t. it easily > integrates into your workflow and allows improving Debian's quality? Ideally, I would like a guide to setting up piuparts in a simple, recommended way, which doesn't assume I already

Re: using upstart in Debian [was, Re: Debian systemd survey]

On 24/05/13 11:29, Dmitrijs Ledkovs wrote: > As far as I understand (correct me if I am wrong), systemd instead of > counting/tracking forks uses cgroups to keep track of the started > processes. systemd uses cgroups to track "which processes are part of this service?", which means the services ma

Re: default MTA

On 28/05/13 12:25, Redalert Commander wrote: > 2013/5/28 Josselin Mouette : >> And on desktop systems, nobody reads local email. We might want to think >> of a better notification system, but email is definitely not fit for >> that anymore. > > I don't think that is true at all. Personally, I use

<    2   3   4   5   6   7   8   9   10   11   >