Bug#729282: ITP: htslib -- C library for high-throughput sequencing data formats
Package: wnpp
Severity: wishlist
Owner: Charles Plessy
Hello everybody,
I intend to package the HTSlib, that some existing packages (samtools,
tabix) will need later.
Cheers,
-- Charles Plessy, Tsurumi, Kanagawa, Japan
Package name: htslib
Version : 0.2
Upstream Author : See below
URL : https://github.com/samtools/htslib/tree/develop
License : Mostly MIT, see below
Programming Lang: C
Description : C library for high-throughput sequencing data formats
Package: libhts0
Architecture: any
Multi-Arch: same
Depends: ${shlibs:Depends},
${misc:Depends}
Description: C library for high-throughput sequencing data formats
HTSlib is a unified C library for accessing common file formats, such as SAM
(Sequence Alignment/Map) and VCF (Variant Call Format), used for nucleic acid
sequence data obtained by high-throughput sequencing.
.
HTSlib implements a generalized BAM (binary SAM) index. The HTSlib file
reader first looks for the new index and then for the old if the new index is
absent.
.
HTSlib is still experimental. It has not been tested on large-scale real
data. Some
useful APIs are missing.
Package: libhts-dev
Architecture: any
Multi-Arch: same
Section: libdevel
Depends: ${shlibs:Depends},
${misc:Depends}
Description: Development files for the HTSlib
HTSlib is a unified C library for accessing common file formats, such as SAM
(Sequence Alignment/Map) and VCF (Variant Call Format), used for nucleic acid
sequence data obtained by high-throughput sequencing.
.
This package contains development files: headers, static library, manual pages,
etc.
Package: htslib-test
Architecture: all
Depends: ${misc:Depends}
Description: Test data for HTSlib
HTSlib is a unified C library for accessing common file formats, such as SAM
(Sequence Alignment/Map) and VCF (Variant Call Format), used for nucleic acid
sequence data obtained by high-throughput sequencing.
.
This package contains test files and scripts for the HTSlib.
Files: *
Copyright: (C) 2012-2013 Genome Research Ltd.
(c) 2008 Broad Institute / Massachusetts Institute of Technology
The Wellcome Trust Sanger Institute
(c) 2008, 2009, 2011 by Attractive Chaos
License: MIT
Files: cram/*
Copyright: (c) 2012-2013 Genome Research Ltd.
(c) 1995-1996 MEDICAL RESEARCH COUNCIL
License: Various_BSD-3-Clause
Files: cram/md5.?
Copyright: No copyright is claimed
License: solar-MD5
This is an OpenSSL-compatible implementation of the RSA Data Security, Inc.
MD5 Message-Digest Algorithm (RFC 1321).
.
Homepage:
http://openwall.info/wiki/people/solar/software/public-domain-source-code/md5
.
Author:
Alexander Peslyak, better known as Solar Designer
.
This software was written by Alexander Peslyak in 2001. No copyright is
claimed, and the software is hereby placed in the public domain.
In case this attempt to disclaim copyright and place the software in the
public domain is deemed null and void, then the software is
Copyright (c) 2001 Alexander Peslyak and it is hereby released to the
general public under the following terms:
.
Redistribution and use in source and binary forms, with or without
modification, are permitted.
.
There's ABSOLUTELY NO WARRANTY, express or implied.
Files: htslib/razf.?
Copyright: 2008, Jue Ruan , Heng Li
License: BSD-2-clause~with-minor-differences-in-the-disclaimer
--
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/2013081332.32731.99702.reportbug@localhost.localdomain
issue with svn repo?
Hi, are you experimenting issues with svn access to debian repo (svn and anonsvn) ? I can't connect anymore and when trying to browse the code, I have access errors http://anonscm.debian.org/viewvc/debian-med/trunk Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: issue with svn repo?
On Mon, 11 Nov 2013 10:40:29 +0100, olivier sallou wrote: > are you experimenting issues with svn access to debian repo (svn and > anonsvn) ? Subject: Alioth is down http://lists.debian.org/debian-infrastructure-announce/2013/11/msg1.html Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #101: Collapsed Backbone -- 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/2013094410.gk32...@colleen.colgarra.priv.at
Re: gfortran: binNMU needed?
Hi, I came across a similar problem. But I still don't know how to solve it.Please help me and give more detail explanation. The following words are my question: readwind_gfs.f90:63 use grib_api 1 Fatal Error: File 'grib_api.mod' opened at (1) is not a GFORTRAN module file make: *** [readwind_gfs.o] error 1 Thank you! -- View this message in context: http://debian.2.n7.nabble.com/gfortran-binNMU-needed-tp2997933p3102487.html Sent from the Debian Devel mailing list archive at Nabble.com. -- 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/1384175866426-3102487.p...@n7.nabble.com
Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
Hi, I really didn't want to write again in this thread (we did write too much already, and the wiki should be the only medium to write about this now...), though I can't just let John Paul Adrian Glaubitz write false statements this way, and the wiki isn't a good medium for debunking things that can be read below (I tried, it just doesn't fit). On 11/08/2013 11:30 PM, John Paul Adrian Glaubitz wrote: >> * If OpenRC's development continues in good direction, Debian could >> switch to OpenRC > > The word here is "if". It's not going to happen. It's already happening. OpenRC development very is active. Join #openrc on Freenode and chat with upstream, then you'll see that they are actively working on it, and well. The constant point release is another proof. The git repo as well. I've also worked on it on the Debian side, and upstream has been very responsive. Please don't write this kind of things: you clearly don't know what you are talking about here. Or probably this was about "good direction" and related to Gentoo bug #391945? Well, in this case, see below... > OpenRC has fundamental > issues which haven't been resolved for years now: > >> https://bugs.gentoo.org/show_bug.cgi?id=391945 > > I don't think this is a viable alternative to anything. The bug which you are referring to only happens in very few edge cases. A lot of efforts has been put into this problem, and I don't think it can be held as an argument against OpenRC anymore. > We can't work with vaporware, we need software that actually works. Please quit using this kind of wording. Here's the wikipedia definition: "Vaporware is a term in the computer industry that describes a product, typically computer hardware or software, that is announced to the general public but is never actually released nor officially cancelled." OpenRC is *not* a vaporware, it is available upstream from Gentoo, and released often. And from the Git on Alioth, and it works rather well. Because it failed to pass the NEW queue once (for a valid reason) doesn't mean it's vaporware. >> * If our shell scripts are a mess, then we should clean up the mess, >> not trying to escape it by changing whole init system; more precisely, >> we should correct mistakes we made in past, such as not enough >> abstraction > > And who is going to do it? Are you? If you believe that people are going to switch to systemd and write stuff for it if we choose it, why do you think the same thing will not happen with OpenRC if that's the choice? This makes absolutely no sense. > People constantly stating that systems like OpenRC and sysvinit > are actually viable alternatives if someone improved them without > actually stepping forward themselves leaves me up to the impression > that those people actually don't have interests in pushing sysvinit > or OpenRC but just blocking the adoption of systemd or upstart. Well, there's not only this kind of people, some did stepping forward, while some just did nothing. The same thing could be said by replacing OpenRC with systemd and systemd with OpenRC, and in fact, with any kind of software the same could be truth. This is not a valid argumentation. Furthermore, what you wrote above shows that you haven't investigated much about OpenRC when writing these words. By the way, I don't think people are pushing an agenda just for "blocking the adoption of systemd or upstart". What's blocking it, IMO, is that none support our ports. If they were, there wouldn't be such a controversy. And in some ways, upstream for systemd is hurting its adoption even more than anyone by stating that no ports patch will be accepted upstream. If there was any kind of ongoing effort for porting upstart or systemd to our ports, I wouldn't do anything on OpenRC for Debian myself. >> If sysvinit is in accord with UNIX philosophy, and as they say it is, >> than I don't see why (1) and (2) would not be possible, too, and with >> not to much effort. > > No one cares about the "Unix philosophy" (TM) A lot of people don't like that systemd is doing too many things and that its components are depending on each other (that's not *my* biggest critic though, but it seems it is for some). What's being argued here is that systemd contains unnecessarily complexity in its current design (and that features could be implemented without this complexity). This is what the "Unix philosophy" (TM) is about... Also, please don't talk for everyone using "no one cares". You are *not* everyone. You did this in the past, and that's a very annoying kind of wording habit that you have here, and which IMO you should quit. Thomas -- 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/5280f2bc.3040...@debian.org
Re: Fixing /sbin/rc in OpenRC (was: Proposal: let’s have a GR about the init system)
On 11/11/2013 03:55 PM, Jonathan Dowland wrote: > On Tue, Oct 29, 2013 at 02:06:45AM +0800, Thomas Goirand wrote: >> On 10/28/2013 06:28 PM, Jakub Wilk wrote: >>> Please rename /sbin/rc to something else. We've had (unrelated) >>> /usr/bin/rc in Debian for at least 18 years. >> >> Outch! This bites hard. Maybe you being the maintainer of the "rc" >> package is why you saw this immediately! :) >> >> Though that's annoying, because upstream must extensively uses "rc". All >> OpenRC commands are in fact using /sbin/rc. For example, /bin/rc-status >> (which shows what is a symlink to /bin/rc, and then /sbin/rc finds out >> that it has been called by using /bin/rc-status, so it prints the status. > > Is there much chance of convincing upstream to consider a migration to > another binary name, perhaps "openrc"? This is what is going to happen, yes. > If it's a difficult and complex > change it would be best if it was performed upstream I think. Upstream says it will just "break expectation". In other words, it's documented to be /sbin/rc, so renaming it will just be annoying for upstream Gentoo users. Probably they can keep a symlink in /sbin/rc for them for a while... > Although it took Debian to notice the clash, the clash may be a problem for > others as well. Sure! Thomas -- 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/5280f393.2090...@debian.org
Re: porting OpenRC on kFreeBSD and Hurd
On 11/11/2013 11:18 AM, Thomas Goirand wrote: > On 11/09/2013 10:38 PM, Colin Watson wrote: >> On Wed, Oct 30, 2013 at 02:45:31AM +0800, Thomas Goirand wrote: >>> Note also that there's a *new* dependency problem (it wasn't there a >>> month ago...), with ifupdown, openssh-server plus another one (I can't >>> remember which one) which insist on having sysv-rc installed. >> >> This is because dh_installinit generates a versioned dependency on >> sysv-rc if a package contains an Upstart job, because that relies on a >> patch to invoke-rc.d so that sysvinit compatibility works properly. If >> OpenRC ships a version of invoke-rc.d, it'll probably need a similar >> patch and to have debhelper adjusted. I already did this for file-rc, >> so perhaps you want to clone-and-hack my patches for OpenRC: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709481 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709482 > > Hi Colin and Joey, > > Following up what Colin wrote, I opened #729248. Then Joey closed the > same day, writing: > > "Something is certianly wrong if every new init system requires packages > that have a versioned ored dependency on every other init system be > rebuilt. > > Someone else is going to have to figure this out, I am not interested in > upstart." > > Well, I'm trying to fix the OpenRC problem, not Upstart. And I'm really > confused, not knowing what's the way forward here... :( > > Any advice here? > > Cheers, > > Thomas Sorry for the confusion, it seems that it's been fixed with the latest debhelper version. Cheers, Thomas -- 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/5280f742.5030...@debian.org
MIPS64EL rootfs available for use and test
Hi, folks, In the recent days, I figure out the mips64el rootfs and test it on Loongson 3A platform. It works well in general, it's time to release it. It can be download from: http://mips64el.debian.net/debian/rootfs/ To install it, what you need to do is just unpack it to a partition and configure kernel/bootloader/fstab by yourself. This is a more detailed instruction for Loongson 3A users: http://mips64el.debian.net/debian/rootfs/README Know issues: 1. MIPS64r2 ISA is required, while we have made a agree to downgrade the requirement to mips3 in future. 2. The permission is of /usr/bin/crontab is not correct, so you need to: apt-get install cron --reinstall 3. some files in /var/cache/man are not correct, you need to: rm -rf /var/cache/man/* ; mandb PS: we have 8500+ packages built now. Happy hacking, and I am wishing your feedback. -- YunQiang Su -- 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/CAKcpw6VFdSj2P5104OvMhZjMeq7UOhf_weW1ZByg=-qpx58...@mail.gmail.com
BTS tags/pseudopackages for ports [Was: Re: Potential issues for most ports]
On Tue, 05 Nov 2013, Don Armstrong wrote: > In any event, if a few active porters wouldn't mind creating a wishlist > bug against bugs.debian.org for this with a suggested course of action, > I'd appreciate it. Assuming there is no significant disagreement about > that course of action, I'd like to implement it within a week or so. If someone has filed a wishlist bug, I've missed it. -- Don Armstrong http://www.donarmstrong.com I really wanted to talk to her. I just couldn't find an algorithm that fit. -- Peter Watts _Blindsight_ p294 -- 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/2013181711.gv9...@rzlab.ucr.edu
Re: [loongson-dev] MIPS64EL rootfs available for use and test
On Tue, 12 Nov 2013 01:57:59 +0800 YunQiang Su wrote: > Hi, folks, > > In the recent days, I figure out the mips64el rootfs and test it on > Loongson 3A platform. > It works well in general, it's time to release it. > > It can be download from: > http://mips64el.debian.net/debian/rootfs/ > > To install it, what you need to do is just unpack it to a partition > and configure kernel/bootloader/fstab by yourself. > > This is a more detailed instruction for Loongson 3A users: > http://mips64el.debian.net/debian/rootfs/README > > Know issues: > 1. MIPS64r2 ISA is required, > while we have made a agree to downgrade the requirement to > mips3 in future. Hello, Thank you very much for your work, it is nice to see Loongson is not forgotten. :) I wonder will this work on Loongson 2F? It is MIPS64 too, but is it "r2"? -- With respect, Roman signature.asc Description: PGP signature
Re: [loongson-dev] MIPS64EL rootfs available for use and test
On Tue, Nov 12, 2013 at 2:52 AM, Roman Mamedov wrote: > On Tue, 12 Nov 2013 01:57:59 +0800 > YunQiang Su wrote: > >> Hi, folks, >> >> In the recent days, I figure out the mips64el rootfs and test it on >> Loongson 3A platform. >> It works well in general, it's time to release it. >> >> It can be download from: >> http://mips64el.debian.net/debian/rootfs/ >> >> To install it, what you need to do is just unpack it to a partition >> and configure kernel/bootloader/fstab by yourself. >> >> This is a more detailed instruction for Loongson 3A users: >> http://mips64el.debian.net/debian/rootfs/README >> >> Know issues: >> 1. MIPS64r2 ISA is required, >> while we have made a agree to downgrade the requirement to >> mips3 in future. > > Hello, > > Thank you very much for your work, it is nice to see Loongson is not > forgotten. :) > > I wonder will this work on Loongson 2F? It is MIPS64 too, but is it "r2"? > It does not work on Loongson 2F, because Loogson 2F is 64-bit capable but supports MIPS-III only. You'll need 2G, 3A ,or 3B to use this work if you'd like to choose from Loongson family. Original mail also metioned that it will downgrade to use MIPS3 in the future, that means rebuilding the whole archive and creating a new rootfs, which is able to work on Loongson 2E/2F. -- Regards, Aron Xu -- 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/CAMr=8w5gw+aftfz4pwdjezohhryk1i5ch_ivnybj0ssh7sk...@mail.gmail.com
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, Nov 05, 2013 at 08:53:05AM +0100, Niels Thykier wrote: > [1] I certainly wouldn't have space for something like this: > > http://en.wikipedia.org/wiki/File:Z800_2066_JKU.jpeg > > (and much less the money. Yeah I know that is technically not an s390, > but as I understand it, an s390 should be "around that size") I'm not sure where the "it's not technically a s390" is coming from (because current Debian doesn't run on it anymore?), but it's pretty accurate. You get them in chunks of one or two racks, plus commonly one or more racks of storage. ;-) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Matthias Urlichs dixit: >A systemd service file is five lines. Someone has shown that this works with sysvinit as well, if you use #!/path/to/some-helper as shebang. >Want more features in your init script? Like, say, a reliable way to >figure out if any parts of your server are still running after it >crashed? Ugh, bad server design. >Or a way to determine that it has started up correctly? An initscript is supposed to not return before it did that. >determined environment without stupid surprises like a LOCALE That’d be the domain of the aforementioned helper. >Or a private tmp? I shudder at the mere thought of allowing a dæmon to unshare its /tmp from the rest of the system, because of the maintenance nightmare this creates, from a Unix PoV (maybe it’s “cool” to you and “usual” to Plan 9 guys, but things like this, or POSIX ACLs, or SELinux, massively make the system opaque to Unix admins). >Or any other of the cool features systemd offers? Newsflash: “cool” isn’t always “better”. >SysV init scripts do not even *have* a reliable dependency system. Sequential booting worked fine for ages, and mostly still does (with file-rc, although insserv certainly introduced trouble). >The SysV manager can tell that the thing started and didn't exit >nonzero, but that's not always the same thing as "running". The initscript is supposed to exit nonzero if the dæmon does not run. Sure, not too many initscripts do that, but still. (If you want a good example, look at postgresql’s, except it doesn’t wait long enough on some slow systems.) >This is about features. Many of the features systemd provides (and which >I refuse to live without, having become accustomed to them over the last >year or so) are, by basic Unix design, not available to something that is >not PID 1. But not everyone needs or wants those features. And, as pointed out on the unshared /tmp example above, some of them may be positively harmful to maintenance of the system in question. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”) -- 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/pine.bsm.4.64l.132015440.23...@herc.mirbsd.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Nov 11, 2013 at 08:20:58PM +, Thorsten Glaser wrote: > Matthias Urlichs dixit: > > >A systemd service file is five lines. > > Someone has shown that this works with sysvinit as well, > if you use #!/path/to/some-helper as shebang. Nice theory, but in practice it is a mess. That people could clean stuff up has been raised and dismissed various times because nobody cleans it up. > >Want more features in your init script? Like, say, a reliable way to > >figure out if any parts of your server are still running after it > >crashed? > > Ugh, bad server design. Why? > >Or a way to determine that it has started up correctly? > > An initscript is supposed to not return before it did that. Why? Also, loads of scripts have sleeps in them. > >determined environment without stupid surprises like a LOCALE > > That’d be the domain of the aforementioned helper. Theory vs practice again. > >Or a private tmp? > > I shudder at the mere thought of allowing a dæmon to unshare > its /tmp from the rest of the system, because of the maintenance > nightmare this creates, from a Unix PoV (maybe it’s “cool” to > you and “usual” to Plan 9 guys, but things like this, or POSIX > ACLs, or SELinux, massively make the system opaque to Unix admins). > > >Or any other of the cool features systemd offers? > > Newsflash: “cool” isn’t always “better”. Instead of such easy replies, try with: s/cool/nice/ Every reply from you reads as - I don't see the need - I don't like it - Could theoretically be done in another way while systemd provides an easy consistent way for *every* service. No rewriting needed. You can easily change some options. > >SysV init scripts do not even *have* a reliable dependency system. > > Sequential booting worked fine for ages, and mostly still does > (with file-rc, although insserv certainly introduced trouble). It may have worked fine, but doesn't dismiss the argument that the other design is better / improved vs the old one. > >The SysV manager can tell that the thing started and didn't exit > >nonzero, but that's not always the same thing as "running". > > The initscript is supposed to exit nonzero if the dæmon does not > run. Sure, not too many initscripts do that, but still. (If you > want a good example, look at postgresql’s, except it doesn’t wait > long enough on some slow systems.) "doesn't wait long enough" is enough IMO You also raise the "supposed to", which is again theory vs practice. With systemd you have various things which you can rely on. No need to hope that the init script was properly written. If you want to change an option you can. This without totally changing the init script to change it in the way it was "supposed to" be written. > >This is about features. Many of the features systemd provides (and which > >I refuse to live without, having become accustomed to them over the last > >year or so) are, by basic Unix design, not available to something that is > >not PID 1. > > But not everyone needs or wants those features. And, as pointed > out on the unshared /tmp example above, some of them may be > positively harmful to maintenance of the system in question. You didn't point it out, you said it makes it complicated without stating why. -- Regards, Olav -- 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/2013212436.ga17...@bkor.dhs.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Nov 11, 2013 at 10:24:36PM +0100, Olav Vitters wrote: > On Mon, Nov 11, 2013 at 08:20:58PM +, Thorsten Glaser wrote: > > >Or a private tmp? > > > > I shudder at the mere thought of allowing a dæmon to unshare > > its /tmp from the rest of the system, because of the maintenance > > nightmare this creates, from a Unix PoV (maybe it’s “cool” to > > you and “usual” to Plan 9 guys, but things like this, or POSIX > > ACLs, or SELinux, massively make the system opaque to Unix admins). Olav answered other points, I'll just answer this one. PrivateTmp directiories are accessible from the outside, given suitable priviledges. If you look into /tmp/systemd-.service-XXX/tmp and /var/tmp/systemd-.service-XXX/tmp, you'll find the contents of the /tmp and /var/tmp directories of .service. In fact, we make use of this functionality: the systemd-tmpfiles cleaner also removes old stuff from PrivateTmp directories, just like from normal /tmp and /var/tmp. (Until relatively recently, the service name wasn't used in the directory name, so all dirs were called /tmp/systemd-private-XXX, where XX is some random string, but now the service is included, so finding the right dir is rather simple.) Zbyszek -- 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/2013224230.gu28...@in.waw.pl
Re: MIPS64EL rootfs available for use and test
On Tue, Nov 12, 2013 at 1:57 AM, YunQiang Su wrote: > It can be download from: > http://mips64el.debian.net/debian/rootfs/ This rootfs contains things that should not be shared between multiple machines (like the dbus machine-id), luckily you didn't install openssh-server or this would result in security issues. Debian doesn't yet have a safe way to generate generic rootfses or pre-installed images. For now please choose one of these: Point users at debootstrap or d-i instead of the rootfs (best option). Use the debian-live tools to generate a live image, this strips out all the things that should differ between machines. Don't ship a rootfs at all. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6hfrmuk37vbanav17oxwgttujna1k4raqdhtu0-bca...@mail.gmail.com
Re: MIPS64EL rootfs available for use and test
On Tue, Nov 12, 2013 at 12:15 PM, Paul Wise wrote: > On Tue, Nov 12, 2013 at 1:57 AM, YunQiang Su wrote: > >> It can be download from: >> http://mips64el.debian.net/debian/rootfs/ > > This rootfs contains things that should not be shared between multiple > machines (like the dbus machine-id), luckily you didn't install Maybe I should remove it and ask user to remove it. > openssh-server or this would result in security issues. Debian doesn't Yes, I did it on purpose. > yet have a safe way to generate generic rootfses or pre-installed > images. For now please choose one of these: > > Point users at debootstrap or d-i instead of the rootfs (best option). I agree, while we have no generic kernel image for mips64el, the kernel patch for Loongson 3 have not been in mainline even. > > Use the debian-live tools to generate a live image, this strips out > all the things that should differ between machines. It is also stopped by the current situation of kernel, very unluck. > > Don't ship a rootfs at all. I hate rootfs also, very hate, while I have to give user a way to test this port. > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > > -- > To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/caktje6hfrmuk37vbanav17oxwgttujna1k4raqdhtu0-bca...@mail.gmail.com > -- YunQiang Su -- 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/CAKcpw6XagrOu_BZyE58D4TUf90wr-iszznKQvm5u=lzwzme...@mail.gmail.com
Re: MIPS64EL rootfs available for use and test
On Tue, Nov 12, 2013 at 1:19 PM, YunQiang Su wrote: > On Tue, Nov 12, 2013 at 12:15 PM, Paul Wise wrote: >> On Tue, Nov 12, 2013 at 1:57 AM, YunQiang Su wrote: >> >>> It can be download from: >>> http://mips64el.debian.net/debian/rootfs/ >> >> This rootfs contains things that should not be shared between multiple >> machines (like the dbus machine-id), luckily you didn't install > Maybe I should remove it and ask user to remove it. >> openssh-server or this would result in security issues. Debian doesn't > Yes, I did it on purpose. >> yet have a safe way to generate generic rootfses or pre-installed >> images. For now please choose one of these: >> >> Point users at debootstrap or d-i instead of the rootfs (best option). > I agree, while we have no generic kernel image for mips64el, > the kernel patch for Loongson 3 have not been in mainline even. >> >> Use the debian-live tools to generate a live image, this strips out >> all the things that should differ between machines. > It is also stopped by the current situation of kernel, very unluck. >> >> Don't ship a rootfs at all. > I hate rootfs also, very hate, while I have to give user a way to test > this port. >> >> -- >> bye, >> pabs >> >> http://wiki.debian.org/PaulWise >> >> >> -- >> To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org >> Archive: >> http://lists.debian.org/caktje6hfrmuk37vbanav17oxwgttujna1k4raqdhtu0-bca...@mail.gmail.com >> > > > > -- > YunQiang Su > > > -- > 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/CAKcpw6XagrOu_BZyE58D4TUf90wr-iszznKQvm5u=lzwzme...@mail.gmail.com > -- bye, pabs http://wiki.debian.org/PaulWise http://bonedaddy.net/pabs3/ -- 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/caktje6e1rafh5ptt_x5nqogz4pxz9-bwpznb2-b007wuqhw...@mail.gmail.com
Re: MIPS64EL rootfs available for use and test
Woops, sorry for the blank mail. On Tue, Nov 12, 2013 at 1:19 PM, YunQiang Su wrote: > On Tue, Nov 12, 2013 at 12:15 PM, Paul Wise wrote: >> Point users at debootstrap or d-i instead of the rootfs (best option). > I agree, while we have no generic kernel image for mips64el, > the kernel patch for Loongson 3 have not been in mainline even. There is multistrap for situations where you need to install from two repositories at once. I assume you have a mips64el version of Linux for Loongson 3 in another repository somewhere. PS: why is longsoon-dev a private list? I keep getting bounces when I CC it. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6E5nFsshLs75mj1=_lc4sk6o9byyrk1cmbeevgzfvn...@mail.gmail.com
Re: MIPS64EL rootfs available for use and test
On Tue, Nov 12, 2013 at 2:28 PM, Paul Wise wrote: > Woops, sorry for the blank mail. > > On Tue, Nov 12, 2013 at 1:19 PM, YunQiang Su wrote: >> On Tue, Nov 12, 2013 at 12:15 PM, Paul Wise wrote: >>> Point users at debootstrap or d-i instead of the rootfs (best option). >> I agree, while we have no generic kernel image for mips64el, >> the kernel patch for Loongson 3 have not been in mainline even. > > There is multistrap for situations where you need to install from two > repositories at once. I assume you have a mips64el version of Linux > for Loongson 3 in another repository somewhere. No, I have not another repo, the kernel I am using is from loongson, they build it manually. I failed to build the Debian kernel with the patches from loongson. > > PS: why is longsoon-dev a private list? I keep getting bounces when I CC it. No idea, maybe due to the default configuration of google groups? > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > > -- > To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/CAKTje6E5nFsshLs75mj1=_lc4sk6o9byyrk1cmbeevgzfvn...@mail.gmail.com > -- YunQiang Su -- 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/CAKcpw6XZSsg5=bsoggn18-mludc4atjogf2-acm5wbmgtkq...@mail.gmail.com
