Package: wnpp
Severity: wishlist
Owner: "Andrew Lee (李健秋)"
* Package name: ruby-rubinius
Version : 2.0.1-1
Upstream Author : Brian Shirai
* URL : http://rubini.us
* License : BSD
Programming Lang: Ruby
Description : A meta-gem for all the Rubinius comp
Package: wnpp
Severity: wishlist
Owner: "Andrew Lee (李健秋)"
* Package name: ruby-rubinius-profiler
Version : 2.0.2-1
Upstream Author : Brian Shirai
* URL : https://github.com/rubinius/rubinius-profiler
* License : BSD
Programming Lang: Ruby
Description
Package: wnpp
Severity: wishlist
Owner: "Andrew Lee (李健秋)"
* Package name: ruby-rubinius-coverage
Version : 2.0.3-1
Upstream Author : Brian Shirai
* URL : https://github.com/rubinius/rubinius-coverage
* License : BSD
Programming Lang: Ruby
Description
Package: wnpp
Severity: wishlist
Owner: "Andrew Lee (李健秋)"
* Package name: ruby-rubinius-debugger
Version : 2.2.1-1
Upstream Author : Brian Shirai
* URL : https://github.com/rubinius/rubinius-debugger
* License : BSD
Programming Lang: Ruby
Description
On Fri, 2016-01-01 at 20:55 +0800, Paul Wise wrote:
> On Fri, Jan 1, 2016 at 7:17 PM, Ansgar Burchardt wrote:
>
> > Moving /bin, /sbin, /lib to /usr has some advantages like being able to
> > mount /usr read-only while keeping /etc read-write. Or sharing /usr
> > between multiple containers and h
On Jan 01, Bastien ROUCARIES wrote:
> > My maintscripts are a total of four commands and they have used for at
> > least 9 months in packages with priority important (nano) and required
> > (debianutils), with no problems reported.
> > If you believe that they are unsuitable then I think that at
On Jan 01, Ian Jackson wrote:
> Someone has already mentioned mounting /usr ro. But one generally has
> to keep /etc rw. I don't think that the right way to address this is
> to make /etc a mount point.
I am not aware of any plan to make /etc a mount point, which indeed
would pointless.
On a m
Ian Jackson writes:
> Ansgar Burchardt writes ("Re: support for merged /usr in Debian"):
>> m...@linux.it (Marco d'Itri) writes:
>> > Thanks to my conversion program in usrmerge there is no need for a flag
>> > day, archive rebuilds or similar complexity and we can even continue to
>> > support un
Hi,
On 01.01.2016 14:28, Vincent Bernat wrote:
>> Booting without an initrd, which is important for resource-constrained
>> embedded systems.
> Do you also require a separate /usr for those systems?
My current system doesn't, but I might need it in the future because
mounting /usr takes an awfu
Ansgar Burchardt writes ("Re: support for merged /usr in Debian"):
> m...@linux.it (Marco d'Itri) writes:
> > Thanks to my conversion program in usrmerge there is no need for a flag
> > day, archive rebuilds or similar complexity and we can even continue to
> > support unmerged systems.
>
> Is the
On Fri, Jan 1, 2016 at 2:22 PM, Bastien ROUCARIES
wrote:
> On Fri, Jan 1, 2016 at 10:46 AM, Marco d'Itri wrote:
>> On Dec 31, Bastien ROUCARIES wrote:
>>
>>> It is not only about lintian it is about the quality of your maintscript.
>> My maintscripts are a total of four commands and they have us
On Fri, Jan 1, 2016 at 10:46 AM, Marco d'Itri wrote:
> On Dec 31, Bastien ROUCARIES wrote:
>
>> It is not only about lintian it is about the quality of your maintscript.
> My maintscripts are a total of four commands and they have used for at
> least 9 months in packages with priority important (
On Fri, Jan 01, 2016 at 01:29:09PM +0100, Simon Richter wrote:
> On 01.01.2016 12:23, Ansgar Burchardt wrote:
>
> > Is there any use case that requires supporting unmerged systems?
>
> Booting without an initrd, which is important for resource-constrained
> embedded systems.
>
> [reasons for !ini
❦ 1 janvier 2016 13:29 +0100, Simon Richter :
>> Is there any use case that requires supporting unmerged systems?
>
> Booting without an initrd, which is important for resource-constrained
> embedded systems.
Do you also require a separate /usr for those systems?
--
The human race has one rea
On Fri, Jan 1, 2016 at 4:54 AM, Hideki Yamane wrote:
> On Mon, 28 Dec 2015 13:55:48 +0100
> Bastien ROUCARIES wrote:
>>If it is GPL-2+ it is not a problem but a few fonts file are released
>>under GPL-2 only... It is quite a mess.
>
> Yes... The best way to solve it is re-license those snippets
On Fri, Jan 1, 2016 at 8:39 PM, Adam Borowski wrote:
> I don't think so. You already need the / filesystem, and with today storage
> sizes, if you can hold that, you can hold the whole system, period. Even on
> any embedded that can run Debian.
I'm reminded of the posts by Joey Hess in 2007:
h
On 2016-01-01 13:39:35, Adam Borowski wrote:
> On Fri, Jan 01, 2016 at 12:23:20PM +0100, Ansgar Burchardt wrote:
> > m...@linux.it (Marco d'Itri) writes:
> > > Thanks to my conversion program in usrmerge there is no need for a flag
> > > day, archive rebuilds or similar complexity and we can even c
On Fri, Jan 1, 2016 at 7:17 PM, Ansgar Burchardt wrote:
> Moving /bin, /sbin, /lib to /usr has some advantages like being able to
> mount /usr read-only while keeping /etc read-write. Or sharing /usr
> between multiple containers and having them only use a different / with
> different /etc and /v
On Fri, Jan 01, 2016 at 12:23:20PM +0100, Ansgar Burchardt wrote:
> m...@linux.it (Marco d'Itri) writes:
> > Thanks to my conversion program in usrmerge there is no need for a flag
> > day, archive rebuilds or similar complexity and we can even continue to
> > support unmerged systems.
>
> Is ther
Hi,
On 01.01.2016 12:23, Ansgar Burchardt wrote:
> Is there any use case that requires supporting unmerged systems?
Booting without an initrd, which is important for resource-constrained
embedded systems.
I have a system that boots in three seconds, which is fairly long
already. Adding an initr
m...@linux.it (Marco d'Itri) writes:
> Thanks to my conversion program in usrmerge there is no need for a flag
> day, archive rebuilds or similar complexity and we can even continue to
> support unmerged systems.
Is there any use case that requires supporting unmerged systems?
It's simpler to sup
Paul Wise writes:
> On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
>> https://wiki.debian.org/UsrMerge
>
> Now that we have union mounts in Linux, should we instead do what Ken
> Thompson and Dennis Ritchie should have done; install things in /
> instead of /usr and use union mounts when the
On Fri, Jan 01, 2016 at 06:20:42PM +0800, Paul Wise wrote:
> On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
>
> > https://wiki.debian.org/UsrMerge
>
> Now that we have union mounts in Linux, should we instead do what Ken
> Thompson and Dennis Ritchie should have done; install things in /
>
On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
> https://wiki.debian.org/UsrMerge
Now that we have union mounts in Linux, should we instead do what Ken
Thompson and Dennis Ritchie should have done; install things in /
instead of /usr and use union mounts when there is one small disk
contain
On Dec 31, Bastien ROUCARIES wrote:
> It is not only about lintian it is about the quality of your maintscript.
My maintscripts are a total of four commands and they have used for at
least 9 months in packages with priority important (nano) and required
(debianutils), with no problems reported.
25 matches
Mail list logo
