Re: Cross compiler ITP (armel)

On Tue, 22 Mar 2011 at 11:54:47 +, Mark Hymers wrote: > the main people [Built-Using] should be used by, as far as I know are > cross-compiler builders and the d-i and kernel-wedge people Also the ia32-libs family of packages, until they get superseded by multiarch? S -- To UNSUBSCRIBE

Bug#534750: ITP: telepathy-mission-control-5 -- management daemon for Telepathy real-time communication framework

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist Owner: Simon McVittie * Package name: telepathy-mission-control-5 Version : 5.1.2 Upstream Author : the Telepathy project (© Nokia Corporation, Collabora Ltd.) * URL : http://mission

Re: HTTPS everywhere!

On 12/06/14 19:16, Tollef Fog Heen wrote: > ]] Christoph Anton Mitterer > >> Supplying the Debian Root CA to people not using Debian could have been >> easily done by a *single* site that uses a cert available in all >> browsers... which offers the Debian Root CA for secure and "trusted" >> downl

Re: New project goal: Get rid of Berkeley DB (post jessie)

On 20/06/14 08:47, Thomas Goirand wrote: > Respectfully, this is only your own opinion. Maybe I'm wrong, but I > myself fail to see why the AGPLv3 is a problem. And I don't understand > why you wrote that "the AGPLv3 is not very friendly to downstream > projects". IMO it is only unfriendly with pro

Re: SV: MATE 1.8 has now fully arrived in Debian

On 25/06/14 15:43, Svante Signell wrote: > Regarding mate desktop policykit-1 build-depends on libsystemd-login-dev > only for linux-any. What functionality is missing for other > architectures? The interesting dependency chain is: policykit-1 Depends libpam-systemd [linux-any] (degraded function

Re: SV: MATE 1.8 has now fully arrived in Debian

On 25/06/14 19:51, Svante Signell wrote: > Looks like consolekit is the package fork if such a thing ever happens. > There are still patches, mainly for kFreeBSD, from 2013-2014 in the > freedesktop BTS since the last release. When was the Debian switch from > consolekit to policykit-1 made? Conso

Re: SV: MATE 1.8 has now fully arrived in Debian

On 25/06/14 20:03, Svante Signell wrote: > On Wed, 2014-06-25 at 17:38 +0100, Simon McVittie wrote: >> Upstream developers in various projects increasingly oppose group-based >> access, because membership of many "desktop stuff" groups essentially >> means "can

Re: MATE 1.8 has now fully arrived in Debian

On 26/06/14 13:33, Svante Signell wrote: > Of course with the additional check that the students are logged in to > that box locally, did I forget to mention that? Apparently yes. So you'll still need some solution to "is this user local?" - either an implementation of the systemd-logind API (pref

Re: MATE 1.8 has now fully arrived in Debian

On 27/06/14 10:53, Svante Signell wrote: > Before this part of the thread dies out, can anybody comment on this, > Simon, Ansgar, Jean-Christophe, ...? > > On Thu, 2014-06-26 at 16:32 +0200, Svante Signell wrote: >> Maybe I'm naive but doesn't utmp(5) solve this problem? >> >> who(1) tells me in c

Re: multiarch: arch dependent header file path choice

On 28/06/14 18:44, Osamu Aoki wrote: > The path for the arch dependent header file seems to have several options. > > 1) /usr/include//*.h > 2) /usr/include///*.h > 3) /usr/lib///include/*.h The correct answer depends: (a) what users are meant to #include (e.g. vs. ) (b) whether users are m

Re: say goodbye to network-manager-strongswan?

On 16/07/14 11:17, Harald Dunkel wrote: > how comes that network-manager-strongswan has been dropped > from testing? https://packages.qa.debian.org/n/network-manager-strongswan.html says: network-manager-strongswan (source, i386, amd64, armel, armhf, mips, mipsel, powerpc, s390x) has new bugs! Up

Re: Bug#755676: general: Intermittent failure to mount partition [after hibernate?] with message "Transport endpoint is not connected"

On 22/07/14 10:58, Paul G Taylor wrote: > The /dev/sda2, NTSF formatted partition, is shared between RoboLinux, Windows > XP and Windows XP virtualised in VirtualBox. Not necessarily related to the error you reported (which I have no idea about) but you should never allow VirtualBox to have raw f

Re: libsystemd-dummy available in unstable

On 24/07/14 12:16, Marco d'Itri wrote: > This package provides a dummy libsystemd-daemon-dev binary package on > kfreebsd-* and hurd-* systems. > > The purpose of this package is to allow other packages to > unconditionally build-depend depend on libsystemd-daemon-dev, removing the > need for if

Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution

On 02/08/14 08:03, Charles Plessy wrote: > A straightforward way is exemplified by the case of SSH, where the server keys > are regenerated if they are absent. It then only takes to delete the keys > when > preparing images to avoid the problem of duplicated IDs or privacy leaks. D-Bus (/var/lib

Re: more files in /usr/share/doc could possibly be symlinked

On 02/08/14 10:01, 積丹尼 Dan Jacobson wrote: > Perhaps more duplicate files in /usr/share/doc could be symlinked to > save space in some cases Yes, I'm sure some of them could; but whenever the infrastructure to do this goes slightly wrong, it ends up as failure to install (or a missing file that is

Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution

On 02/08/14 19:16, Luca Capello wrote: > On Sat, 02 Aug 2014 14:35:33 +0100, Simon McVittie wrote: >> D-Bus (/var/lib/dbus/machine-id) also regenerates its machine ID during >> boot if required, although systemd (/etc/machine-id) > > BTW, /me wonders why two different files..

Re: Bug#753589: systemd: missing pre-dependencies for runlevel(8) etc.

Policy says new Pre-Depends should be discussed on debian-devel so let's try that. (Please do not derail this thread into discussing whether systemd is a good thing or not, everyone is tired of that.) Quick summary of #753589 for debian-devel readers: Essential:yes packages are expected to provide

Re: Bug#753589: systemd: missing pre-dependencies for runlevel(8) etc.

On 04/08/14 09:32, Simon McVittie wrote: > Quick summary of #753589 for debian-devel readers: Essential:yes packages are > expected to provide their functionality while merely unpacked, even when > not yet configured. The new init package is Essential:yes, and the > functionality i

Re: Reverting to GNOME for jessie's default desktop

On 08/08/14 05:41, Joey Hess wrote: > (Also, perhaps worth noting > that 3.12 is quite a few versions ahead of the gnome currently in > unstable..) The metapackages in src:meta-gnome3 are still at version 3.8, but the actual upstream packages making up GNOME 3.12 are nearly all in testing already.

Re: Reverting to GNOME for jessie's default desktop

On 13/08/14 23:08, Matthias Klumpp wrote: > the common reaction I get from new Linux users [...] > I would also recommend to go for > this user group when selecting a default, since any more experienced > user can absolutely be expected to pick the right image with their > favourite flavour of Debi

Re: Uploading python-xstatic-* packages in Debian

On 14/08/14 15:44, Thomas Goirand wrote: > On 08/14/2014 07:02 PM, Brian May wrote: >> In what way will python-xstatic-jquery be better than libjs-jquery? > > It's not in any way better, it just adds the Python wrapper layer, so > upstream code can easily find out that jquery is located in > /usr/

Re: Standardizing the layout of git packaging repositories

On 15/08/14 15:16, Raphael Hertzog wrote: > Some initial questions and possible answers: I've been hesitating on whether to ask this because it gets into questions of workflow and repo structure that are very much a matter of taste and don't have a single widely-declared-to-be-good answer, but I t

Re: Standardizing the layout of git packaging repositories

On 16/08/14 17:09, Raphael Hertzog wrote: > On Fri, 15 Aug 2014, Simon McVittie wrote: >> It is possible to use git-buildpackage with --git-export (either >> explicitly, or configured in debian/gbp.conf) for packages that only >> keep debian/ in git. > > Are you su

Re: systemd service and /etc/default/

On 17/08/14 10:38, Thomas Goirand wrote: > I had the same problem as you describe above, even a bit more > complicated because, in what we did, /etc/default/ sometimes > doesn't exist (it's not mandatory in what we did). EnvironmentFile takes precedence over Environment, and EnvironmentFile starti

Re: systemd service and /etc/default/

On 17/08/14 12:48, Marco d'Itri wrote: > On Aug 17, Marc Haber wrote: >> It is not >> always possible to come with a working default configuration or to >> build one in postinst. > > If unconfigured software really cannot fail cleanly then the package can > install it without enabling the service

Re: daemon user naming scheme

On 25/08/14 14:01, Jerome BENOIT wrote: > is there for Debian a daemon user naming scheme or custom ? Several :-( The ones I've seen suggested are (assuming a package, daemon or user whose simple name is "foo"): * _foo * foo * debian-foo * Debian-foo * Dfoo

Re: daemon user naming scheme

On 25/08/14 18:30, Jerome BENOIT wrote: >> On 25/08/14 16:53, Simon McVittie wrote: >>> I think I slightly prefer _foo, which originated in *BSD. > > Moreover, _foo is not accepted by adduser, the option --force-badname must be > used. Correct. Debian-foo has the same p

Re: Standardizing the layout of git packaging repositories

On 26/08/14 07:01, Brian May wrote: > In gbp-pq [...] There is no history kept of > the patch-queue branch. Possibly the patch-queue branch shouldn't be > pushed to remote repositories, because rebasing is expected. You are correct in thinking that it is conventional to avoid pushing the patch-que

Re: Base binary packages using xz instead of gzip

On 01/09/14 12:33, Guillem Jover wrote: > It seems there's quite many binary packages in the base system using > xz as compressor instead of gzip, since the switch to xz as default, > which might make debootstrapping from non-Debian systems harder. According to your report, 145 out of 166 base pac

Re: Base binary packages using xz instead of gzip

On 01/09/14 16:58, The Wanderer wrote: > Unless debootstrap relies on the outside source to perform that > decompression, of course, but in that case I'm not sure what it would > even mean to say that debootstrap "supports" xz in the first place. In this case "debootstrap supports xz" means "deboo

Re: calling maintainer scripts with a clean environment?

On 02/09/14 20:09, Evgeni Golov wrote: > after reading #759590, I think it is time to consider calling maintainer > scripts in a (slightly) cleaned environment. Another possibility would be to guarantee that init scripts will be called in a cleaned environment. This seems like it will break fewer

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

On 02/09/14 21:17, Changwoo Ryu wrote: > For fonts-nanum, the default is ~300 KiB 3.5% larger than -9e. And -9e > is not better than -8e. I don't think anyone is arguing that higher compression settings don't produce better compression ratios. However: Preset DictSize Com

Re: Jessie without systemd as PID 1?

I'm sure we've been over this many times already. On 03/09/14 13:24, Martinx - ジェームズ wrote: > If so, can I just run: `apt-get install sysvinit-core` to get rid of > systemd as my INIT? Yes. > If yes, will this be support until... Let's say, Debian kFreeBSD still > remains around...? That's up

Re: daemon user naming scheme

On 05/09/14 16:03, Ian Jackson wrote: > Simon McVittie writes ("Re: daemon user naming scheme"): >> It is reasonable to use /var/lib/foo (or /run/foo or /var/cache/foo or >> /var/games/foo) as the home directory of a system user whose name is >> _foo, debian-foo, D

Re: More tasks option in Tasksel: what tasks do you want there?

On 08/09/14 12:45, Ralf Jung wrote: > I tried to find out what tools are pulled > in by "standard system utilities", but couldn't find the package in > aptitute. The other tasks are packages (e.g. task-gnome-desktop), but task-standard is special and does not exist as a package. Instead, it contai

Re: systemd, again (Re: Cinnamon environment now available in testing)

On 08/09/14 14:44, Noel Torres wrote: > Example: having EMC Networker server softare for backups in a sysvinit > machine > is (relatively) easy, because the scripts for starting and stopping the > services are (quite) standard (but very complicated) sysv scripts. systemd is compatible with LSB

Re: Seeking help with OpenVPN scripts and systemd

On 11/09/14 18:53, Mirosław Baran wrote: > Does NetworkManager support multiple VPN connections right now? Yes. > (Also, > what about persistent VPN setups that are independent from the desktop > session?) Yes, there's a flag for "automatically connect this VPN when you get lower-level connectiv

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

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

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

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

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. /

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