Re: /export (was Re: jessie release goals)

2013/5/8 Peter Samuelson : > Wrong list, please bring this up instead on fhs-discuss. (If that > still exists - it looks a bit stale - but anyway, debian-devel is not > for FHS discussion.) I'd like to have an open discussion. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org

Re: /srv (was /export)

2013/5/8 Thorsten Glaser : > Игорь Пашев gmail.com> writes: > >> What about moving default location for applications to /export ? > > *NO*! Maybe not /export, but /srv, which already exists, the idea is separating system data and application data. (Actually, I do not like /export, because of /etc

Re: Current and upcoming toolchain changes for jessie

* Roger Leigh: > On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: >> The decision when to make GCC 4.8 the default for other architectures >> is left to the Debian port maintainers. > > This makes using C++11 and other features only in 4.8 rather difficult. C++11 hasn't got a stabl

Re: Current and upcoming toolchain changes for jessie

* Matthias Klose: > glibc's version bump to 2.17 should be mostly uneventful, with the > exception of a few more compiler warnings and errors, and the long > overdue removal of gets() from the API. FTBFS bugs for the above > have already been filed, and patches submitted for many of the new > bui

Re: epoch fix?

On Wed, May 08, 2013 at 05:27:01AM +0200, Adam Borowski wrote: > On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote: > > What I think should be fixed is the fact that it doesn't > > appear in the filename. I never understood why they > > don't. Did I miss something? > > Having a colon

Re: epoch fix?

Matt Zagrabelny wrote : > is there a consensus or quorum that believes that unnecessary epochs is > undesirable? I don't think so. Package maintainers may have different views of the meaning of "unnecessary" in this context. > could we add a field to debian/control such as "Supersede-Epoch". Af

Re: Current and upcoming toolchain changes for jessie

On Wed, 2013-05-08 at 05:15 +0200, Adam Borowski wrote: > On Wed, May 08, 2013 at 01:59:38AM +0200, Aurelien Jarno wrote: > > (b) It's completely useless on a Debian system, as the kernel doesn't > > support x32 binaries. > > Is there a big reason to not enable CONFIG_X86_X32 in default kernel

Re: epoch fix?

On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote: > What I think should be fixed is the fact that it doesn't > appear in the filename. I never understood why they > don't. Did I miss something? Having a colon in CD/DVD images is likely to cause problems, with the chance of breakage r

Re: Current and upcoming toolchain changes for jessie

On Wed, May 08, 2013 at 01:59:38AM +0200, Aurelien Jarno wrote: > (b) It's completely useless on a Debian system, as the kernel doesn't > support x32 binaries. Is there a big reason to not enable CONFIG_X86_X32 in default kernels? It doesn't seem to have more downsides than your average kerne

Re: jessie release goals

+++ Wookey [2013-05-07 22:31 +0100]: [right. 3rd attempt at getting this email to make sense. reposting the whole thing this time, hopefully with no remaining howlers] +++ Stephen Kitt [2013-05-07 14:38 +0200]: > Hi Wookey, > > On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote: > > (just a decisi

Re: jessie release goals

+++ Wookey [2013-05-07 22:31 +0100]: > The tradeoff is: > 1) (Move _all_ headers to /usr/include/triplet) > * Much duplication of installed headers > * Only one system include dir, which fits current build-system > expectations > > 2) (Move only arch-dependent headers to /usr/include/tri

Re: epoch fix?

On 05/08/2013 05:55 AM, Matt Zagrabelny wrote: > Hello world, > > I've grepped the d-d list, but didn't find any threads regarding > fixing epochs in package versions. > > First, is there a consensus or quorum that believes that unnecessary > epochs is undesirable? I think they are necessary and de

Re: Current and upcoming toolchain changes for jessie

On Wed, 2013-05-08 at 01:39 +0200, Matthias Klose wrote: [...] > - I didn't upload linux-libc-dev myself, but until today I didn't >see any announcement or a test rebuild done by the Debian kernel >maintainers, so I did add the note about what I did see in multiple >packages when doing

Re: re-thinking architecture qualification for jessie

Am 08.05.2013 02:31, schrieb Matthias Klose: > gabrielli as the porter box is now up again, but I don't see any real support > for mips, mipsel, s390, sparc, and maybe powerpc within Debian. Please > consider > toolchain maintenance when starting the architecture qualification for jessie. forgot

Re: epoch fix?

But either way, the problem is that .dsc and .deb version numbers are not used only by dpkg. Lots of tools use them, inside and outside of Debian packages, inside and outside of Debian infrastructure. We cannot be sure that they all use dpkg's own interfaces to do so (e.g. dpkg --compare-versio

Re: epoch fix?

On May 07, Matt Zagrabelny wrote: > First, is there a consensus or quorum that believes that unnecessary > epochs is undesirable? Among reasonable people, I'd say yes. Epochs are like herpes: once you have one on your package it's going to be around forever. So try to avoid them if possible. --

Re: Current and upcoming toolchain changes for jessie

On Tue, May 07, 2013 at 06:35:16PM -0600, Adam Conrad wrote: > On Wed, May 08, 2013 at 01:59:38AM +0200, Aurelien Jarno wrote: > > > > They weren't coordinated within the team. Furthermore I don't consider > > that eglibc was ready to go to unstable, as it was known that two > > architectures were

Re: Current and upcoming toolchain changes for jessie

On Wed, May 08, 2013 at 01:59:38AM +0200, Aurelien Jarno wrote: > > They weren't coordinated within the team. Furthermore I don't consider > that eglibc was ready to go to unstable, as it was known that two > architectures were going to FTBFS, without a real try to get that fixed > (for example by

re-thinking architecture qualification for jessie

I'm not happy how the architecture qualification for wheezy did go (as communicated in the session about the status of the release at DebConf 2012). I did criticize the attitude of the release team as overly optimistic ("green light attitude"), and I do see that at least GCC and binutils don't hav

Re: Current and upcoming toolchain changes for jessie

Hi, On 07/05/13 14:25, Matthias Klose wrote: > == (e)glibc 2.17 == > > We had hoped that leaving > it FTBFS in experimental for several months and gently pinging [...] That was a bit unexpected, and I haven't seen it brought up on debian-bsd@ until now. > == GCC 4.8 == > > It is planned to onl

Re: Bug#705168: Any multi VGA controller systems failing to boot?

On Tue, 2013-05-07 at 15:03 -0400, Barry Fishman wrote: > On 2013-05-07 13:20:02 EDT, Ben Hutchings wrote: > > On Tue, May 07, 2013 at 11:14:23AM -0400, Barry Fishman wrote: > >> 1) This bug is a month old and due to a Debian patch which was rejected > >>by the upstream kernel team. > > > > Per

Re: Current and upcoming toolchain changes for jessie

On Wed, May 08, 2013 at 01:39:25AM +0200, Matthias Klose wrote: > Am 07.05.2013 17:48, schrieb Aurelien Jarno: > > On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: > >> Up to today jessie did see updates for the kernel headers, eglibc, and > >> GCC. > > > > What a wonderful coordina

Re: Current and upcoming toolchain changes for jessie

Am 07.05.2013 17:48, schrieb Aurelien Jarno: > On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: >> Up to today jessie did see updates for the kernel headers, eglibc, and >> GCC. > > What a wonderful coordination with the release team. Quoting the last > mail from them on the mailing

Re: epoch fix?

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

Re: Merging / and /usr (was: jessie release goals)

On May 07, Marc Haber wrote: > >What about merging / and /usr ? > So we really want to explicitly not offer an upgade path from wheezy > to jessie? This causes no major issues on upgrades, Fedora did it. The hard part is replacing with a symlink to the other one of every pair of binaries which a

Re: jessie release goals

* Wookey [130507 23:31]: > The tradeoff is: > 1) (Move _all_ headers to /usr/include/triplet) > * Much duplication of installed headers > * Only one system include dir, which fits current build-system > expectations Which would also punish the libraries getting headers correct while making

Re: /export (was Re: jessie release goals)

On Tue, May 07, 2013 at 10:18:25PM +, Thorsten Glaser wrote: > Игорь Пашев gmail.com> writes: > > > What about moving default location for applications to /export ? > > /run is a catastrophe, although an understandable one. Is there anything specific that's wrong with it? Is there anything

Re: /bin/sh (was Re: jessie release goals)

On Tue, 07 May 2013 19:46:43 +0200 Marc Haber wrote: > On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote: > >On May 07, Thorsten Glaser wrote: > >> My stated goal here is, indeed, to be able to run at least some useful > >> configurations of a Debian installation without *bot

Bug#707178: ITP: breakin -- stress-test and hardware diagnostics tool

Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: breakin Version : 3.20 Upstream Author : Jason D. Clinton , Kyle Sheumaker * URL : http://www.advancedclustering.com/software/breakin.html * License : GPL2 Programming Lang: C Descr

Re: Current and upcoming toolchain changes for jessie

Am 07.05.2013 17:46, schrieb Julian Taylor: > On 05/07/2013 03:25 PM, Matthias Klose wrote: >> ... >> >> == binutils == >> >> binutils 2.23.2 will be uploaded to unstable after GCC 4.8 as the >> default on x86 reaches testing. Later updates will introduce binutils >> trunk leading to 2.24, later

Re: epoch fix?

Am 08.05.2013 00:19, schrieb Thorsten Glaser: > Matt Zagrabelny d.umn.edu> writes: > >> Use the mechanism of "really": > > That is *much* *much* *much* *much* *much* *much* *much* *much* *much* > *much* *much* *much* *much* *much* *much* *much* more ugly than epochs > and actually a prime exampl

Re: epoch fix?

On Tuesday, May 07, 2013 10:19:18 PM Thorsten Glaser wrote: > Matt Zagrabelny d.umn.edu> writes: > > Use the mechanism of "really": > That is *much* *much* *much* *much* *much* *much* *much* *much* *much* > *much* *much* *much* *much* *much* *much* *much* more ugly than epochs > and actually a pri

Re: epoch fix?

On Tuesday, May 07, 2013 10:31:55 PM Thorsten Glaser wrote: > Matt Zagrabelny d.umn.edu> writes: > > epochs never go away - AIUI. They detract from meaningful information > > in the version string. > > So do changelogs. But it’s not that hard to mentally strip away a > leading [0-9]+: in a versio

Re: Merging / and /usr (was: jessie release goals)

Marco d'Itri Linux.IT> writes: > On May 07, Игорь Пашев gmail.com> wrote: > > > What about merging / and /usr ? Absolutely not, and I’ll support a GR against it. > I strongly support the "everything in /usr" scheme, but let's first Absolutely not, and I’ll support a GR against it. Gah! Ju

Re: epoch fix?

Matt Zagrabelny d.umn.edu> writes: > epochs never go away - AIUI. They detract from meaningful information > in the version string. So do changelogs. But it’s not that hard to mentally strip away a leading [0-9]+: in a version string. Especially when we have monstrosities like 0.12.34-20130506-g

Re: jessie release goals

Wookey wookware.org> writes: > And you can still use a sysroot and non-multiarch ways of filling it > if you prefer. I haven't really experimented with mulitarch and > sysroot at the same time but SFAIK it should work. I can confirm Multi-Arch doesn’t break traditional cross compilers as prepar

Re: epoch fix?

On Tue, May 7, 2013 at 5:19 PM, Thorsten Glaser wrote: > Matt Zagrabelny d.umn.edu> writes: > >> Use the mechanism of "really": > > That is *much* *much* *much* *much* *much* *much* *much* *much* *much* > *much* *much* *much* *much* *much* *much* *much* more ugly than epochs > and actually a prim

Re: /export (was Re: jessie release goals)

[Igor Pashev] > Currently /var/lib contains data for system utilities (dpkg, apt, > aptitute) and for user application like databases. > > What about moving default location for applications to /export ? Wrong list, please bring this up instead on fhs-discuss. (If that still exists - it looks a

Re: /export (was Re: jessie release goals)

Игорь Пашев gmail.com> writes: > What about moving default location for applications to /export ? *NO*! /sys was already bad. /run is a catastrophe, although an understandable one. I always rm -rf /media after a fresh install, where T F did that come from. As a BSD person, seeing /lib causes me

Re: epoch fix?

[Matt Zagrabelny] > I've grepped the d-d list, but didn't find any threads regarding > fixing epochs in package versions. This does come up occasionally. > If so, could we add a field to debian/control such as > "Supersede-Epoch". If set to 'yes', then dpkg considers this package > to have an ep

Re: epoch fix?

Matt Zagrabelny d.umn.edu> writes: > Use the mechanism of "really": That is *much* *much* *much* *much* *much* *much* *much* *much* *much* *much* *much* *much* *much* *much* *much* *much* more ugly than epochs and actually a prime example of why we *want* them. bye, //mirabilos -- To UNSUBSC

Re: epoch fix?

Matt Zagrabelny d.umn.edu> writes: > First, is there a consensus or quorum that believes that unnecessary > epochs is undesirable? No. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.

Re: epoch fix?

On Tue, May 7, 2013 at 5:08 PM, Noel David Torres Taño wrote: > On Martes, 7 de mayo de 2013 22:55:39 Matt Zagrabelny wrote: >> If so, could we add a field to debian/control such as >> "Supersede-Epoch". If set to 'yes', then dpkg considers this package >> to have an epoch of infinity for version

Bug#707174: ITP: node-policyfile -- Flash Socket Policy File Server for Node.js

Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: node-policyfile Version : 0.0.5 Upstream Author : Arnout Kazemier, 3rd-Eden.com * URL : https://github.com/3rd-Eden/FlashPolicyFileServer * License : MIT Programming Lang: Javascript Descr

Re: epoch fix?

On Martes, 7 de mayo de 2013 22:55:39 Matt Zagrabelny wrote: > Hello world, > > I've grepped the d-d list, but didn't find any threads regarding > fixing epochs in package versions. > > First, is there a consensus or quorum that believes that unnecessary > epochs is undesirable? > > If so, could

epoch fix?

Hello world, I've grepped the d-d list, but didn't find any threads regarding fixing epochs in package versions. First, is there a consensus or quorum that believes that unnecessary epochs is undesirable? If so, could we add a field to debian/control such as "Supersede-Epoch". If set to 'yes', t

Re: Merging / and /usr (was: jessie release goals)

On Martes, 7 de mayo de 2013 17:26:09 Simon Chopin wrote: > Quoting Jonathan Dowland (2013-05-07 18:15:46) > > > This has been discussed many times on -devel, including before you became > > a DD. > > Please don't assume that only DDs read debian-devel. I would think that > most aspiring DDs were

Bug#707171: ITP: node-base64id -- Node.js module that generates a base64 id

Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: node-base64id Version : 0.1.0 Upstream Author : Kristian Faeldt * URL : https://github.com/faeldt/base64id * License : MIT Programming Lang: Javascript Description : Node.js module th

Re: jessie release goals

+++ Stephen Kitt [2013-05-07 14:38 +0200]: > Hi Wookey, > > On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote: > > (just a decision to leave arch-independent headers in /usr/include and > > move arch-dependent headers to /usr/include/triplet). > > Doesn't this limit us to cross-compiling only acro

Bug#707166: ITP: node-socket.io -- Makes WebSockets and realtime possible in all browsers

Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: node-socket.io Version : 0.9.14 Upstream Author : Guillermo Rauch * URL : https://github.com/learnboost/socket.io * License : MIT Programming Lang: Javascript Description : Makes WebS

Re: jessie release goals

On Lunes, 6 de mayo de 2013 13:49:57 Andreas Beckmann wrote: > Hi, > > now might be the right time to start a discussion about release goals > for jessie. Here are some points that come into my mind right now (and > some were already discussed very recently): > > * multiarch compatible binNMUs >

Re: Switching packages to non-awaiting triggers

2013/5/7 Michael Biebl : > If you actually looked at the package, you would have noticed that it has > nothing to do with starting services. Maybe, "systemctl enable" does not start the service? Main question is: can triggers be activated before package is configured (namely conffiles are in plac

Switching default dpkg-deb compressor to xz

Hi! As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ [0]

Re: Switching packages to non-awaiting triggers

Am 2013-05-07 21:40, schrieb Игорь Пашев: 2013/5/7 Michael Biebl : We don't use dpkg triggers to start (systemd) services. Hm? http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/systemd.triggers;h=f6c3c0ce0da08815f366868d3b3a3f9e5907875f;hb=refs/heads/debian What is

Re: Switching packages to non-awaiting triggers

2013/5/7 Michael Biebl : > We don't use dpkg triggers to start (systemd) services. Hm? http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/systemd.triggers;h=f6c3c0ce0da08815f366868d3b3a3f9e5907875f;hb=refs/heads/debian -- To UNSUBSCRIBE, email to debian-devel-requ...@l

Re: Switching packages to non-awaiting triggers

Am 2013-05-07 21:09, schrieb Игорь Пашев: This might be a problem for systemd, but I will talk about SMF [1] and concrete example - dbus. 1. dbus package includes SMF manifest 2. for dbus service to appear, its manifest should be imported 3. importing manifests if done via triggers (AFAIK like i

Re: Bug#705168: Any multi VGA controller systems failing to boot?

On 2013-05-07 13:20:02 EDT, Ben Hutchings wrote: > On Tue, May 07, 2013 at 11:14:23AM -0400, Barry Fishman wrote: >> 1) This bug is a month old and due to a Debian patch which was rejected >>by the upstream kernel team. > > Perhaps you should tell us which that is, then. You told me. The "fb

override: xz-utils:utils/standard

Package: ftp.debian.org Severity: wishlist On Fri, 2012-08-17 at 19:23:37 -0700, Jonathan Nieder wrote: > (please direct replies to debian-devel only) > > Ever since dpkg started using liblzma directly (dpkg 1.16.4), the xz > command is no longer needed in a minimal Debian system. Based on its >

Re: Switching packages to non-awaiting triggers

Hi, I think I know one more issue related to this, correct me if it is not. This might be a problem for systemd, but I will talk about SMF [1] and concrete example - dbus. 1. dbus package includes SMF manifest 2. for dbus service to appear, its manifest should be imported 3. importing manifests i

Re: Merging / and /usr (was: jessie release goals)

On Wed, May 08, 2013 at 01:43:03AM +0800, Thomas Goirand wrote: > On 05/08/2013 12:40 AM, Steve Langasek wrote: > > On Tue, May 07, 2013 at 11:34:20AM -0400, Paul Tagliamonte wrote: > >> On Tue, May 07, 2013 at 07:31:36PM +0400, Игорь Пашев wrote: > >>> What about merging / and /usr ? > >> No pleas

Switching packages to non-awaiting triggers

Hi! To be able to fix dpkg bug #671711, we should first reduce or completely eliminate the possibilty for triggered packages needing its configured dependencies, not ending up being in triggers-awaited status awaiting on them. For packages installing triggers for things that are not necessary for

Bug#707135: ITP: moocng -- open source MOOC platform

Package: wnpp Severity: wishlist Owner: "David Martínez Moreno" * Package name: moocng Version : 1.0 Upstream Author : Rooter Analysis S.L. * URL : http://www.openmooc.org/ * License : Apache Programming Lang: Python, JS Description : open source MOOC

Re: Merging / and /usr (was: jessie release goals)

On Tue, May 07, 2013 at 06:57:12PM +0100, Jonathan Dowland wrote: > On Tue, May 07, 2013 at 07:21:26PM +0200, Stefano Zacchiroli wrote: > > I don't see why, in this context, that's a useful heuristic to have. If > > you want to debunk someone's argument, > > I'm not sure I'd characterize what I tr

Re: Merging / and /usr (was: jessie release goals)

On Tue, May 07, 2013 at 07:21:26PM +0200, Stefano Zacchiroli wrote: > I don't see why, in this context, that's a useful heuristic to have. If > you want to debunk someone's argument, I'm not sure I'd characterize what I tried to get across as debunking someone's argument. More so, questioning whet

/export (was Re: jessie release goals)

Currently /var/lib contains data for system utilities (dpkg, apt, aptitute) and for user application like databases. What about moving default location for applications to /export ? Think about "modern fs" like btrfs and zfs: One may want to create a snapshot of the entire system, user data shou

Bug#707134: ITP: node-yajsml -- Yet another (Common)JS module loader

Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: node-yajsml Version : 1.1.5 Upstream Author : Chad Weider * URL : https://github.com/cweider/yajsml * License : MIT Programming Lang: Javascript Description : Yet another (Common)JS m

Bug#707132: ITP: node-resolve -- Synchronous/Asynchronous require.resolve() algorithm

Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: node-resolve Version : 0.3.1 Upstream Author : James Halliday * URL : https://github.com/substack/node-resolve * License : MIT Programming Lang: Javascript Description : Synchronous/A

Re: Merging / and /usr (was: jessie release goals)

On Tue, 7 May 2013 19:31:36 +0400, ? ? wrote: >What about merging / and /usr ? So we really want to explicitly not offer an upgade path from wheezy to jessie? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questio

Re: /bin/sh (was Re: jessie release goals)

On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote: >On May 07, Thorsten Glaser wrote: >> My stated goal here is, indeed, to be able to run at least some useful >> configurations of a Debian installation without *both* bash and dash >> installed. >What is the point? A smaller f

Re: Merging / and /usr (was: jessie release goals)

On 05/08/2013 12:40 AM, Steve Langasek wrote: > On Tue, May 07, 2013 at 11:34:20AM -0400, Paul Tagliamonte wrote: >> On Tue, May 07, 2013 at 07:31:36PM +0400, Игорь Пашев wrote: >>> What about merging / and /usr ? >> No please. We are good about making sure they each mean something >> important, >

Re: Removal of the /selinux directory

Am 07.05.2013 17:55, schrieb Laurent Bigonville: > The directory should already be automatically removed by dpkg during > the upgrade as it was shipped by the package and not created by the > postinstall script. I'm not sure this was clear enough. This was indeed not clear to me, so thanks for the

Re: Merging / and /usr (was: jessie release goals)

On Tue, May 07, 2013 at 05:57:19PM +0100, Jonathan Dowland wrote: > > Please don't assume that only DDs read debian-devel. > > Don't worry, I haven't: I just don't know of a more accurate heuristic > for determining when somebody started to get involved. I don't see why, in this context, that's a

Re: Bug#705168: Any multi VGA controller systems failing to boot?

On Tue, May 07, 2013 at 11:14:23AM -0400, Barry Fishman wrote: > On 2013-04-22 19:40:01 EDT, Ben Hutchings wrote: > > On Mon, 2013-04-22 at 18:21 -0400, Barry Fishman wrote: > >> Is anyone else seeing a boot hangup on wheezy with the linux/3.2.41-2 > >> kernel > >> on systems with multiple display

Re: Current and upcoming toolchain changes for jessie

On May 07, Aurelien Jarno wrote: > blocked in sid until eglibc is fixed on kfreebsd. I see a simple solution to two problems here... :-) -- ciao, Marco signature.asc Description: Digital signature

Re: Merging / and /usr (was: jessie release goals)

On 7 May 2013, at 17:26, Simon Chopin wrote: > Please don't assume that only DDs read debian-devel. Don't worry, I haven't: I just don't know of a more accurate heuristic for determining when somebody started to get involved. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org wi

Re: Merging / and /usr (was: jessie release goals)

On May 07, Jonathan Dowland wrote: > > If we do this, I'd prefer to make /usr a symlink to / on new installs > I've always thought that myself, but it seems most folks who are pro > merge tend to propose going the other way. I've never understood why. I was trying to not start a new discussion ab

Re: Merging / and /usr (was: jessie release goals)

On 07/05/13 17:17, Jonathan Dowland wrote: > On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote: >> If we do this, I'd prefer to make /usr a symlink to / on new installs > > I've always thought that myself, but it seems most folks who are pro > merge tend to propose going the other way.

Re: Doubts about PPA in Debian

On 07/05/13 15:34, Paul Wise wrote: > On Tue, May 7, 2013 at 10:12 PM, Thomas Goirand wrote: >> Debian backports offers me *one* repository. I need 3 of them: >> - stable -1 (currently OpenStack Folsom) > > Ignore, is there any reason why an old version is interesting? Because Debian testing has

Re: Merging / and /usr (was: jessie release goals)

On Tue, May 07, 2013 at 11:34:20AM -0400, Paul Tagliamonte wrote: > On Tue, May 07, 2013 at 07:31:36PM +0400, Игорь Пашев wrote: > > What about merging / and /usr ? > No please. We are good about making sure they each mean something > important, No, we're actually terrible at it. And upstream is

Re: Re: Will we see MariaDB in Jessie?

On 2013-05-07 08:34, Laurent Bigonville wrote: On Mon, May 06, 2013 at 07:39:50PM +0200, Patrick Matthäi wrote: As long as _MySQL_ maintainers are able (and want) to continue MySQL (or It's my understanding a lot of them jumped ship. Meh. +1 to kill MySQL for MariaDB. It's got a much better

Re: Current and upcoming toolchain changes for jessie

On Tue, May 07, 2013 at 05:48:52PM +0200, Aurelien Jarno wrote: > > Even if I have to admit I currently don't have a lot of time, it would > have been nice to keep the other people in the team in the loop about > such an upload. You'd been fairly inactive of late, and I felt I'd take some initiat

Re: jessie release goals

On Tue, May 07, 2013 at 02:38:07PM +0200, Stephen Kitt wrote: > Hi Wookey, > On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote: > > (just a decision to leave arch-independent headers in /usr/include and > > move arch-dependent headers to /usr/include/triplet). > Doesn't this limit us to cross-comp

Re: Current and upcoming toolchain changes for jessie

On Tue, May 07, 2013 at 10:03:58AM -0600, Adam Conrad wrote: > On Tue, May 07, 2013 at 05:48:52PM +0200, Aurelien Jarno wrote: > > > > Even if I have to admit I currently don't have a lot of time, it would > > have been nice to keep the other people in the team in the loop about > > such an upload

Re: Merging / and /usr (was: jessie release goals)

Quoting Jonathan Dowland (2013-05-07 18:15:46) > This has been discussed many times on -devel, including before you became a > DD. Please don't assume that only DDs read debian-devel. I would think that most aspiring DDs were following it long before even applying in NM. signature.asc Descripti

Re: Merging / and /usr (was: jessie release goals)

On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote: > That said, I'm not in support of moving things to /usr; it's completely > backward. … > If we do this, I'd prefer to make /usr a symlink to / on new installs I've always thought that myself, but it seems most folks who are pro merge te

Re: Merging / and /usr (was: jessie release goals)

Hi Paul, This has been discussed many times on -devel, including before you became a DD. Many people, including Roger and Marco, have spent a *lot* of time thinking about this and working on proofs of concepts, etc. already. Please take some time to read up on the previous threads before insisting

Re: Merging / and /usr (was: jessie release goals)

On May 07, Paul Tagliamonte wrote: > > "everything in /usr" actually means that supporting these devices is > > much easier. > Not when you have a 500 meg internal storage that the firmware boots off > of, and using a multi-gig CF card to store the mega-awesome-app you're > using it for. It's mu

Re: Merging / and /usr (was: jessie release goals)

On Tue, May 07, 2013 at 05:35:11PM +0200, Marco d'Itri wrote: > On May 07, Игорь Пашев wrote: > > > What about merging / and /usr ? > An ambitious plan. > I strongly support the "everything in /usr" scheme, but let's first > consolidate support for "standalone /usr must be mounted by the > init

Re: Removal of the /selinux directory

On May 07, Michael Biebl wrote: > Hi Laurent, Hi Michael, > Am 07.05.2013 16:51, schrieb Laurent Bigonville: > > I'm intentionally not forcing the migration to the new mountpoint > > nor forcing the deletion of the directory on upgrade as, in my > > mind, if a Wheezy machine is still using the o

Re: jessie release goals

On 05/07/2013 04:00 AM, Vincent Lefevre wrote: > This can be fine for some daemons/servers. For instance, for a web > server, displaying a default web page is harmless. But what about a > mail server? Any default config would probably lead to loss of mail > if things like virtual alias domains are

Re: jessie release goals

On 05/07/2013 04:11 AM, Vincent Lefevre wrote: > This doesn't make any sense. What is installed is a package, not > a service. There are packages, like rsync, that provide more than > a service, e.g. a client and a daemon. What if the user wants the > client but not the corresponding service (at an

Processed: reassign 706987 to gnome-shell, forcibly merging 675345 706987

Processing commands for cont...@bugs.debian.org: > reassign 706987 gnome-shell Bug #706987 [general] general: Gnome freezes after some minutes of starting session Bug reassigned from package 'general' to 'gnome-shell'. Ignoring request to alter found versions of bug #706987 to the same values pr

Re: New version of libselinux makes libpcre3 pseudo-essential

2013/5/7 Laurent Bigonville : > Hello, > > As Guillem asked me in a bug report (#695620), I'm bringing this to > debian-devel. > > The latest version of libselinux is now using libpcre3 instead of the > regex functions from the glibc. This is improving the performances > quite substantially when re

Re: Current and upcoming toolchain changes for jessie

On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: > Up to today jessie did see updates for the kernel headers, eglibc, and > GCC. What a wonderful coordination with the release team. Quoting the last mail from them on the mailing list: | As for Squeeze, we'd ask that you co-ordinate

Re: Current and upcoming toolchain changes for jessie

On 05/07/2013 03:25 PM, Matthias Klose wrote: ... == binutils == binutils 2.23.2 will be uploaded to unstable after GCC 4.8 as the default on x86 reaches testing. Later updates will introduce binutils trunk leading to 2.24, later this year. fyi, this change will introduce a couple new FTBF

Re: Merging / and /usr (was: jessie release goals)

2013/5/7 Paul Tagliamonte : > Not when you have a 500 meg internal storage that the firmware boots off > of, and using a multi-gig CF card to store the mega-awesome-app you're > using it for. Similar to Live CDs where /usr used to be compressed on a CD? http://cgit.osdyson.org/live.git/tree/proto

Re: Merging / and /usr (was: jessie release goals)

On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote: > On May 07, Paul Tagliamonte wrote: > > > No please. We are good about making sure they each mean something > > important, and there's no good reason. > Not really nowadays: more and more things needed at boot time are in > /usr and

Re: Removal of the /selinux directory

On Tue, May 07, 2013 at 04:57:51PM +0200, Michael Biebl wrote: > Am 07.05.2013 16:51, schrieb Laurent Bigonville: > > I'm intentionally not forcing the migration to the new mountpoint nor > > forcing the deletion of the directory on upgrade as, in my mind, if a > > Wheezy machine is still using the

Re: Merging / and /usr (was: jessie release goals)

On May 07, Paul Tagliamonte wrote: > No please. We are good about making sure they each mean something > important, and there's no good reason. Not really nowadays: more and more things needed at boot time are in /usr and there are no plans to "fix" them. > We also support setups that might nee

Re: Merging / and /usr (was: jessie release goals)

On May 07, Игорь Пашев wrote: > What about merging / and /usr ? An ambitious plan. I strongly support the "everything in /usr" scheme, but let's first consolidate support for "standalone /usr must be mounted by the initramfs". -- ciao, Marco signature.asc Description: Digital signature

  1   2   >