Re: Ability to further support 32bit architectures

[YunQiang Su]

rhys  于2024年1月13日周六 11:27写道：
>
> Let me try again, following up on the previous thread, but removing most of 
> the irrelevant history.
>
> If I have a 32-bit Intel system that is currently supported on bookworm 
> (currently running bullseye, but I can upgrade it), is that of use to anyone 
> as a native build platform for 32-bit binary packages for Debian?
>
You are yet another person who is confused by the name "i386" vs "amd64".
AMD64 is just the named due to that X86 is extended to X86-64 by AMD *first*.
It means that "Intel 64" or "EM64T" is almost same with "AMD64".

So, you, the Intel CPU user,  should use "AMD64", if you don't clearly
know that your
Intel CPU is 32bit only.

For more clear, for Debian, "AMD64" is equal to X86-64.
https://en.wikipedia.org/wiki/X86-64

-- 
YunQiang Su

Re: Ability to further support 32bit architectures

[YunQiang Su]

 于2024年1月12日周五 23:59写道：
>
> Keeping in mind that I am new to this arena...
>
> I have some Intel systems - both 64-bit and 32-bit - that I might be able to 
> use as build platforms.
>

I guess all of your hardwares are 64bit. You setup different OS on them.

> What does the Debian team need from me to be able to use these systems?
>

It's not about performance of hardware. It is about some limitation of 32bit.
2 examples for it:
   1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
   https://en.wikipedia.org/wiki/Year_2038_problem
   2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
   In fact on most system the value is less than 4GiB:
  on intel32, it is 3GiB
  on mips32, it is 2GiB
   But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
   The RAM does install in your Rack, but you can NOT use it.
  https://en.wikipedia.org/wiki/3_GB_barrier

> I can't guarantee they'll be FAST, but I'll do what I can to make them 
> EFFECTIVE.
>

If you are really need 32bit system. Maybe you can say out why you
*REALLY* need it.
For most users, the suggestion is: upgrade to 64bit.

> --J
>

Re: Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup

[YunQiang Su]

Ansgar  于2023年12月31日周日 20:51写道：
>
> On Sun, 2023-12-31 at 18:49 +0800, YunQiang Su wrote:
> > * Package name: cryptsetup-2fa
> >   Version : 0.1
> >   Upstream Contact: YunQiang Su 
> > * URL : https://github.com/wzssyqa/cryptsetup-2fa/
> > * License : BSD-2
> >   Programming Lang: SHELL
> >   Description : 2FA plugin for cryptsetup
> >
> > 2 mthods are supported for 2 FA:
> >   - Yubikey Challenge
> >   - TPM2 Keypair
> > PIN-less is also supported, if the PINs are present in
> > /etc/cryptsetup/2fa.conf.
> >
> > Since I am not expert of security and encrypt:
> > CODE Review is requested here, too.
>
> Is there any reason to not just use systemd-cryptenroll?

Yes. I tried to use systemd-cryptenroll, while it cannot work with
cryptsetup-suspend.
I need a way to suspend or hibernate without disks decrypted.

> It seems to be a more featureful implementation and also doesn't
> require storing PINs in plain text in configuration files like

My script doesn't *require* storing PIN.
You can just leave the config blank, it will prompt for PIN.

> /etc/cryptsetup/2fa/2fa.conf as README instructs users to do here.
> Nor does it store plain text credentials in /var/cache.
>

This is used, if a user has multi disks/partitions, and all of them have
same PIN, to ask for PIN only one time.

The passphrase is stored in /var/cache, and switch_root will clean
all of them, so I guess it won't leak.

> Ansgar
>
> PS: I also don't understand why cryptsetup-2fa-enroll(1) references
> privacyIDEA.

Thanks. Removed.

Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup

[YunQiang Su]

Package: wnpp
Severity: wishlist
Owner: YunQiang Su 
X-Debbugs-Cc: debian-devel@lists.debian.org, s...@debian.org

* Package name: cryptsetup-2fa
  Version : 0.1
  Upstream Contact: YunQiang Su 
* URL : https://github.com/wzssyqa/cryptsetup-2fa/
* License : BSD-2
  Programming Lang: SHELL
  Description : 2FA plugin for cryptsetup

2 mthods are supported for 2 FA:
  - Yubikey Challenge
  - TPM2 Keypair
PIN-less is also supported, if the PINs are present in
/etc/cryptsetup/2fa.conf.

Since I am not expert of security and encrypt:
CODE Review is requested here, too.

Re: GCC 13 stopped supporting a documented option (was Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL')

[YunQiang Su]

>
> Now, what is the problem?  Well, the spec removes the knowledge about
> the -EL and -EB arguments by overriding *cc1.  So the fix is to re-add
> those arguments:
>
> | %rename cc1 old_cc1
> | *cc1:
> | %(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem 
> include%s %(old_cc1)
>

Yes. You are correct.
I guess `%(cc1_cpu)` was supposed to contains all of switches support
by the author of this specs file,
while this suppose is not true.

Such as mips, the EL/EB option is added by
#undef CC1_SPEC
#define CC1_SPEC "\
%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
%(subtarget_cc1_spec)"

And it is also true for most target, since they are using
`%(subtarget_cc1_spec)` or similar.

-- 
YunQiang Su

Re: GCC 13 stopped supporting a documented option (was Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL')

[YunQiang Su]

I can reproduce this problem. I will try to solve this problem (by git bisect



git bisect told me that this behaivor changed since 
6d3c634c8baebd9ff12c39d61947752486758bd.


Let's study it: is it a feature or bug ;)

commit 6d3c634c8baebd9ff12c39d61947752486758bd3
Author: Jason Merrill 
Date:   Sun Nov 27 14:30:14 2022 -0500

driver: fix validate_switches logic

Under the old logic for validate_switches, once suffix or starred 
got set,

they stayed set for all later switches found in the spec.  So for e.g.

%{g*:%{%:debug-level-gt(0):

Once we see g*, starred is set.  Then we see %:, and it sees that as a
zero-length switch, which because starred is still set, matches any 
and all
command-line options.  So targets that use such a spec accept all 
options in

the driver, while ones that don't reject some, such as the recent
-nostdlib++.

This patch fixes the inconsistency, so all targets would complain about
-nostdlib++, and then sets SKIPOPT for it so they don't.

gcc/ChangeLog:

* gcc.cc (validate_switches): Reset suffix/starred on loop.

gcc/cp/ChangeLog:

* g++spec.cc (lang_specific_driver): Set SKIPOPT for 
nostdlib++.


 gcc/cp/g++spec.cc | 4 +++-
 gcc/gcc.cc| 7 +--
 2 files changed, 8 insertions(+), 3 deletions(-)

Re: GCC 13 stopped supporting a documented option (was Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL')

[YunQiang Su]

Bastian Blank  于2023年11月25日周六 17:48写道：
>
> Hi Thorsten
>
> On Fri, Nov 24, 2023 at 06:58:40PM +, Thorsten Glaser wrote:
> > Matthias Klose dixit:
> > >, this is not an RC issue. Please stop playing
> > > bug ping pong.
> >
> > If GCC stops supporting an option it used to support,
> > and where the GCC documentation say it’s supported,
> > it in my opinion very much is an RC bug.
>
> Thank you for purposefully not mentioning that this only applies if you
> use the bothed(?) gcc spec override to build with musl instead of glibc.
> Can you show it is broken if using the standard toolchain as asked
> by the maintainer?
>
> The gcc spec also defines which arguments are supported.  So if your
> spec override does not support a particular one, then it will not work.
>
> However what I now find interesting is: the Debian gcc 12 on amd64
> got the options -muclibc, -mbionic amd -mmusl for some limited support
> for those alternative libc.
>

I can reproduce this problem. I will try to solve this problem (by git bisect

> Bastian
>
> --
> I'm frequently appalled by the low regard you Earthmen have for life.
> -- Spock, "The Galileo Seven", stardate 2822.3
>


-- 
YunQiang Su

Re: The future of mipsel port

[YunQiang Su]

Aurelien Jarno  于2023年7月19日周三 14:43写道：
>
> On 2023-07-19 11:23, Paul Wise wrote:
> > On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote:
> >
> > > As CIP United, we do maintain an unofficial port of mipsel.
> > > So I wish that Debian can still accept our patch to support mipsel
> > > port (source only).
> > > https://repo.oss.cipunited.com/debian/
> >
> > The closest Debian has to source-only ports are the ones that are
> > supported in rebootstrap but not on debian-ports. You could also
> > migrate mipsel to debian-ports instead of dropping it entirely.
>
> Please note that maintaining a port in debian-ports in good state
> requires more work than an official port. Therefore this should only be
> done if there are people actually going to do the work, otherwise it's
> just a waste of time and resources.
>
> > https://wiki.debian.org/HelmutGrohne/rebootstrap
> > https://wiki.debian.org/PortsDocs/New
> >
> > > (And let's keep mips64el port).
> >
> > DSA would appreciate it if you could publicly document your plans for
> > trixie mips64el hardware qualification on the wiki, as riscv64 did:
>
> Yes. Please also clarify how do you plan to handle the NaN2008 issue for
> mips64el. Some of the newer buildds have NaN2008 FPU, while the port and
> the toolchain are configured for the old MIPS NaN. This causes some
> issues in some packages, a lot of headaches to packages maintainers and
> upstream that have to debug the issues, and eventually testsuites being
> fully or partially disabled.
>

I am working on getting more NaN1985 hardware for Debian.

> Regards
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://aurel32.net



-- 
YunQiang Su

Re: The future of mipsel port

[YunQiang Su]

Paul Wise  于2023年7月19日周三 11:23写道：
>
> On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote:
>
> > As CIP United, we do maintain an unofficial port of mipsel.
> > So I wish that Debian can still accept our patch to support mipsel
> > port (source only).
> > https://repo.oss.cipunited.com/debian/
>
> The closest Debian has to source-only ports are the ones that are
> supported in rebootstrap but not on debian-ports. You could also
> migrate mipsel to debian-ports instead of dropping it entirely.
>

Yes. It sound a good idea to migrate to debian-ports.
Since we have only 15 years to 2038, I hope the ports in debian-ports
should be y2038-free.

> https://wiki.debian.org/HelmutGrohne/rebootstrap
> https://wiki.debian.org/PortsDocs/New
>
> > (And let's keep mips64el port).
>
> DSA would appreciate it if you could publicly document your plans for
> trixie mips64el hardware qualification on the wiki, as riscv64 did:
>
> https://dsa.debian.org/ports/hardware-requirements/
> https://wiki.debian.org/HardwareQualification
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise



-- 
YunQiang Su

The future of mipsel port

[YunQiang Su]

Hi, folks,

Welcome to era of Trixie, and let's talk about the future of mipsel.

mipsel port has some problems as somebody may know:
1. 2G user RAM space make some packages FTBFS, especially with LTO enabled.
2. Y2038 problem, which requires almost rebootstrap.
3. The current hardwares, include MIPS P5600, Ingenic X2000, Loongson 3A4000,
are NAN2008 hardwares, and some new software supposed that NAN2008 is
always true.
[1] https://sourceware.org/binutils/docs-2.25/as/MIPS-NaN-Encodings.html
4. the maintenance status of big projects, like Firefox, Libreoffice
etc are not so good.

So I consider to suggest drop mipsel support from the list of official ports.
(And let's keep mips64el port).

As CIP United, we do maintain an unofficial port of mipsel.
So I wish that Debian can still accept our patch to support mipsel
port (source only).
https://repo.oss.cipunited.com/debian/

Debian mips32r2el port with:
* -mnan=2008
* -mfp64
* -mmsa (not yet, will have another port)
* -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
* -D_TIME_BITS=64

Known supported hardwares:
MIPS P5600
Ingenic X2000
Loongson 3A4000

Re: 64-bit time_t transition for 32-bit archs: a proposal

[YunQiang Su]

For mipsel, we have one more thing to do:
- NaN2008 vs NaN legacy
So I'd prefer rebootstrap (only for mipsel).
And In fact we did it: https://repo.oss.cipunited.com/debian/

Russ Allbery  于2023年5月17日周三 12:31写道：
>
> Steve Langasek  writes:
>
> > * Largely via NMU, add a “t64” suffix to the name of runtime library
> >   packages whose ABI changes on rebuild with the above flags.  If an
> >   affected library already has a different suffix (c102, c2, ldbl, g…), drop
> >   it at this time.
>
> This is possibly me being too fiddly (and also I'm not 100% sure that I'll
> get to this in time), but ideally I'd like to do an upstream SONAME
> transition for one of my shared libraries (and probably will go ahead and
> change it for i386 as well, since I'm dubious of the need to run old
> binaries with new libraries in this specific case).
>
> What's the best way for me to do that such that I won't interfere with the
> more automated general transition?  Will you somehow automatically detect
> packages that have already been transitioned?  Or should I wait until the
> package has been automatically transitioned and *then* do an upstream
> transition?
>
> > Your thoughts?
>
> The one additional wrinkle is that there are packages that, due to
> historical error or unfortunate design choices, have on-disk data files
> that also encode the width of time_t.  (I know of inn2, which is partly my
> fault, but presumably there are more.)  Rebuilding that package with the
> 64-bit time_t flags would essentially introduce an RC bug (data loss)
> because it will treat its existing data files as corrupt.  Do you have any
> idea how to deal with this case?
>
> (The LFS transition was kind of a mess and essentially required users to
> do manual data migration.  This time around, maybe we'll manage to write a
> conversion program in time.)
>

Since there may be some unknown problems, we cannot tell our user that
they can upgrade smoothly, no matter rebootstrap or rebuilding some packages.

So I guess, rebootstrap may be a better choice, at least for users to
understand what we did.

> --
> Russ Allbery (r...@debian.org)  <https://www.eyrie.org/~eagle/>
>


-- 
YunQiang Su

Re: No mips64el porterbox?

[YunQiang Su]

mips64el uses the same porterbox with mipsel, since mips32 and mips64 are
compatiable; and all of our machines are in fact 64bit.

Julien Puydt  于 2022年3月1日周二 下午5:28写道：

> Hi,
>
> one of my package has a failure on mips64el and upstream is ready to
> help me find the cause and debug the issue.
>
> Unfortunately, on https://db.debian.org/machines.cgi I only see five
> developer machines on this architecture -- all buildd!
>
> Is there really no mips64el porterbox, or is it only a transitory
> situation?
>
> Cheers,
>
> J.Puydt
>
>

Re: Porter roll call for Debian Bookworm

[YunQiang Su]

Sandro Tosi  于2022年1月14日周五 13:54写道：
>
> YunQiang,
>
> On Tue, Jan 4, 2022 at 9:48 AM PICCA Frederic-emmanuel
>  wrote:
> >
> >
> > > > In case #1000435 (matplotlib crashes on mips64el) is not already on
> > > > your radar, would you please take a look?
> > > >
> > >
> > > Thank you. I will work on it right now.
> >
> > Hello, I just added some information about this problem on this bug
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001168#72
> >
> > it seems to me that this is something related to gcc-11.  If I build 
> > matplotlib with gcc-10 there is no more crash.
>
> did you have a chance to look at it yet? there's quite a substantial
> number of packages depending on matplotlib that cant migrate to

OK. I will have a look at this now.

> testing until this issue is fixed, so we'd greatly appreciate it if
> you can investigate it soon.
>
> Thanks,
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi



-- 
YunQiang Su

Re: Porter roll call for Debian Bookworm

[YunQiang Su]

Graham Inggs  于2021年12月26日周日 21:58写道：
>
> Hi YunQiang Su
>
> On Sun, 26 Dec 2021 at 11:17, YunQiang Su  wrote:
> >
> >   For mipsel and mips64el, I
> >   - test most packages on this architecture
> >   - run a Debian testing or unstable system on port that I use regularly
> >   - fix toolchain issues
> >   - triage arch-specific bugs
> >   - fix arch-related bugs
> >   - triage d-i bugs
> >   - test d-i regularly
> >   - fix d-i bugs/issues
> >   - maintain buildds
> >   - maintain/provide hardware for (or assist with) automated tests on 
> > ci.d.n,
> > jenkins.d.n (etc.)
> >
> > I am a DD.
>
> Thanks for your response!
>
> In case #1000435 (matplotlib crashes on mips64el) is not already on
> your radar, would you please take a look?
>

Thank you. I will work on it right now.

> Regards
> Graham



-- 
YunQiang Su

Re: Porter roll call for Debian Bookworm

[YunQiang Su]

  For mipsel and mips64el, I
  - test most packages on this architecture
  - run a Debian testing or unstable system on port that I use regularly
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - triage d-i bugs
  - test d-i regularly
  - fix d-i bugs/issues
  - maintain buildds
  - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
jenkins.d.n (etc.)

I am a DD.

-- 
YunQiang Su

Re: Future of /usr/bin/which in Debian?

[YunQiang Su]

Paul Wise  于2021年8月20日周五 上午10:50写道：
>
> On Thu, Aug 19, 2021 at 9:17 PM Boyuan Yang wrote:
>
> > So we will have https://salsa.debian.org/debian/which-gnu providing a binary
> > package with name "which". I will upload it to the NEW queue soon.
>
> Some folks on IRC wanted to package the FreeBSD which too, so I
> suggest using which-gnu as the binary package name too.
>

For such a simple tool, do we really need such many versions?


> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>


-- 
YunQiang Su

Re: Porter roll call for Debian Bullseye

[YunQiang Su]

 I am sorry for the later response.
   Hi,

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the Bullseye release (est. end
  of 2024):

  For mipsel and mips64el, I
  - test most packages on this architecture
  - run a Debian testing or unstable system on port that I use regularly
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - triage d-i bugs
  - test d-i regularly
  - fix d-i bugs/issues
  - maintain buildds
  - provide hardware for automated tests on ci.d.n,
jenkins.d.n (etc.)
  - ...

  I am a DD

  YunQiang Su
 


signature.asc
Description: This is a digitally signed message part

Re: DNF for Debian

[YunQiang Su]

ckages
> on a Debian stretch machine. The proposed packages contain a few patches 
> needed
> for stretch integration (and stretch also needs changes to
> gobject-introspection, glib and util-linux for DNF to build and work 
> correctly).
> I didn't want to rip them out and they don't cause trouble on 
> newer-than-stretch
> systems since their effect is essentially deactivated there. They are, 
> however,
> marked with "stretch" in the description and dropping them should be very 
> easy.
>
> They seemed to be very usable and stable for my use case - building RPM 
> packages
> via mock.
>
>
>
> Mihai
>
>
>
> [0] Debian/dpkg/apt has already known one of these "boolean(/rich) 
> dependencies"
> for quite some time - OR dependencies. RPM adds further ones, like (A if B)
> which pulls in package A if B is already installed on the user system while
> installing the dependent package, (A if B else C), which is the but extended
> with a ternary term and crazier ones like (A with B), which instructs the 
> solver
> to find ONE single package that fulfills both A and B. Confused? A and B need
> not be actual packages, it's totally valid for them to be other expressions,
> like fully virtual ones. RPM spec files can use any statement in Provides:
> clauses - and those can either live in a specific namespace (e.g.,
> "pkgconfig(rpm)", which looks for an "rpm" capability in the "pkgconfig"
> namespace) or in the global namespace (e.g., "mta", as a virtual package
> specification). Yes, it's complicated to understand and arguably error-prone
> (for humans), but the usage of such expressions is abundant within the
> repositories nowadays.
>


-- 
YunQiang Su

Re: Y2038 - best way forward in Debian?

[YunQiang Su]

Steve McIntyre  于2020年2月14日周五 上午12:20写道：
>
> YunQiang Su wrote:
> >Ansgar  于2020年2月13日周四 下午5:29写道：
> >>
> >> For arm* and mips*, we mostly seem to be talking about special-purpose
> >> systems where just switching to a new architecture/port doesn't seem to
> >> be that much as a problem as for i386.  I think rebuilding the world and
> >> breaking ABI might thus be acceptable there.
> >>
> >> i386 seems different.  I think option C above would be the only
> >> realistic proposal so far to fix the time_t problem for (parts of) i386,
> >> but if glibc upstream doesn't want to expose two interfaces then i386
> >> will probably just break.
> >>
> >
> >just redefine time_t to 64bit may also cause a problem:
> >   a bad designed and old network protocol which aims  only target 32bit 
> > system,
> >   a binary data packet, may contain time_t:
> >struct {
> >int a;
> >time_t b;
> >}
> >just define time_t to 64 will break this protocol, although it is bad 
> >designed.
>
> Oh, sure. We'll find bugs like this, guaranteed.
>
> >Currently, the major task of 32bit ports is to keep compatible with
> >old system/binary.
> >Should we really want to break them?
>
> Well, that's the question. AIUI people seem to be wanting to keep i386
> as-is, due to the existing ecosystem of binaries (both free and
> proprietary), and I've not seen anybody really saying that i386 needs
> to live beyond 2038.
>
> armhf is different, and we want to fix it (/replace it with
> armhf_) with a 64-bit clean ABI. Where do the other existing
> 32-bit ports sit?
>
>  * armel? anybody want to chime in?
>  * mipsel?

For mipsel, I prefer keeping align with i386.

>
> I'd like to start making decisions *soon* on what we want to do, so we
> can start work. I'm *hoping* that we might be able to get a new armhf
> port done and released with bullseye, but that's clearly up to the
> release team to make a call on. The longer we leave things, the harder
> that target will be.
>
> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
>   Armed with "Valor": "Centurion" represents quality of Discipline,
>   Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
>   concord the digital world while feeling safe and proud.
>


-- 
YunQiang Su

Re: Y2038 - best way forward in Debian?

[YunQiang Su]

Ansgar  于2020年2月13日周四 下午5:29写道：
>
> Steve McIntyre writes:
> > wzss...@gmail.com wrote:
> >>Is there the option C?
> >>
> >>Draft:
> >>  1. define time64_t
> >>  2. for data_struct which act as a part of ABI, define a new data_struct64
> >>  3. for function which act as part of ABI, define a new version func64.
> >>  4. patch all packages to use time64_t instead of time_t step by step.
> >>  5. set a time as deadline (2030?), and then treat all packages
> >>haven't finished
> >>  the migration as rc-buggy.
> >>
> >> Since we have enough time, we can patch all packages in that period.
> >
> > It's possible, but...
> >
> > The problem here is that we have many thousands of packages to work
> > on, glibc up through other libs to all the applications that use
> > them. It's invasive work, and likely to take a very long time. Since
> > it's work that would *not* be needed for 64-bit architectures, we're
> > also likely to see push-back from some upstreams.
> >
> > 2030 is also too late to fix the problem - people are already starting
> > to see issues in some applications. We want to make a difference soon:
> > the earlier that we have fixes available, the fewer broken systems
> > will have to be fixed / removed / replaced later.
>
> For arm* and mips*, we mostly seem to be talking about special-purpose
> systems where just switching to a new architecture/port doesn't seem to
> be that much as a problem as for i386.  I think rebuilding the world and
> breaking ABI might thus be acceptable there.
>
> i386 seems different.  I think option C above would be the only
> realistic proposal so far to fix the time_t problem for (parts of) i386,
> but if glibc upstream doesn't want to expose two interfaces then i386
> will probably just break.
>

just redefine time_t to 64bit may also cause a problem:
   a bad designed and old network protocol which aims  only target 32bit system,
   a binary data packet, may contain time_t:
struct {
int a;
time_t b;
}
just define time_t to 64 will break this protocol, although it is bad designed.

Currently, the major task of 32bit ports is to keep compatible with
old system/binary.
Should we really want to break them?

> Ansgar
>


-- 
YunQiang Su

Re: Y2038 - best way forward in Debian?

[YunQiang Su]

ed
  the migration as rc-buggy.

 Since we have enough time, we can patch all packages in that period.

> What do people think here? Which do you think is the better path? Feel
> free to point out things you think I may have missed. We should get
> started on this soon - the longer we leave it, the more likely it is
> that we'll see 2038 bugs biting people.
>
> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
> "Yes, of course duct tape works in a near-vacuum. Duct tape works
>  anywhere. Duct tape is magic and should be worshipped."
>-― Andy Weir, "The Martian"
>


-- 
YunQiang Su

Re: binutils: add host64-target32 package

[YunQiang Su]

On Mon, 3 Feb 2020 14:22:49 +0800 YunQiang Su 
wrote:
> Package: binutils
> Version: 2.34-2
> X-Debug-Cc: debian-devel@lists.debian.org
> 
> Since we meet lots of packages ftbfs on 32bit ports due to 2GB/3GB
> and then virtual memory exhausted
> 
> We had some discuss here:
>https://lists.debian.org/debian-devel/2019/08/msg00171.html
> 
> The patch is attached and submit as a PR
> https://salsa.debian.org/toolchain-team/binutils/merge_requests/5
> 
> 
> This package is built with multilib, and with option --host 64bit
> --target 32bit It diverts non-multiarch programs with dpkg-divert as
> c++filt dwp elfedit ld.bfd ld.gold Add a with_host64 option --
default
> off
> 
> We will have a src:binutils64, while will use these code.

For gcc we also need gcc64 package.

> 
> 
> -- 
> YunQiang Su

anybody see problems with radeon drive on sid?

[YunQiang Su]

Background: I have a MIPS/Loongson laptop.
It may have bad RGB after a short uptime.
It also may show some colorful mosaic.

This only happens with kernel built with gcc-9.
I tried 5.2 ~ 5.5.
It also only happens on desktop environment, not on console
screen(control-alt-FN).

does anybody meet the same problem on x86 platform?
So that I can narrow the problem to gcc/kernel or MIPS unique.

It's GPU is:
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Device 9615
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Seymour [Radeon E6460]

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[YunQiang Su]

I figure out a set of
  --build=amd64 --host=amd64 --target=i686
toolchain. [1]

It seems work, with some problems left:

1. gcc64 depends on mpfr4/gmp/mpclib3, which has no multilib support yet.
2. I use dpkg-divert to replace the executable with this one. Is it suitable?

It is in a very early stage. any suggestions is welcome.

[1] http://mips64el.bfsu.edu.cn/debian-new/tarball/host64/

Re: Tell me about your salsa experience

[YunQiang Su]

Dmitry Bogatov  于2019年4月22日周一 下午5:56写道：
>
>
> [ I know, it month and half late ]
> [ I did my best to recover thread. Sorry, If I failed. ]
>
> [ Please, CC me if you want me to reply. I'm not subscribed to debian-devel@ ]
>
> [ Alexander Wirt ]
> > Thats where you come in, please tell me how tools like salsa, alioth,
> > git, tracker and so on changed to way you work. I want to know
> > everything, the good, the bad and so on.
>
> Glad you asked. So I have excuse for stating my opinion, which is quite
> unpopular.
>
> Summary: Introduction of salsa is nothing short of disaster.
>

One problem of salsa is that the speed of fork is quite slow.
I guess we need something like CoW.

> I started working with Debian in mid-2014, when all code lived on
> alioth. The best thing about alioth is that I did not interact with it.
>
> Alioth did not get in my way. I had ssh access to alioth.debian.org, all
> operations was simple and intuitive. I had choice of VCS to use, git
> hooks were easy to setup, every chore was easy to script. I participated
> in two teams -- Haskell and Emacs. Everything was smooth, it is just
> matter of file permissions.
>
> Maybe developers, who granted me access to teams, had to deal with
> something more terrible I can imagine. Maybe administering Alioth for
> DSA team was nightmare. No idea, I am telling about my experience.
>
> And then came yet another tragic day for Debian, and Gitlab replaced
> alioth.debian.org. It brought pain, inconvenience and friction.
>
>   Performing basic operations with repository now either impossible
>   (salsa forces foo/bar naming, instead of flexibility of proper
>   filesystem on Alioth), or requires learning new useless stuff.
>
>   There is no longer proper git hooks.
>
>   Other version control systems are gone.
>
> In an instant, I became second-class citizen, now everything --
> documentation, processes, defaults -- everything is optimized for
> running "modern" browser and pushing buttons. Scriptability is pain.
>
> That is not all, folks. Salsa brought own issue tracker and concept of
> pull-request. So now I can't just mail a patch with reportbug(1) --
> there are chances, that maintainer will either ignore it, because he
> only follows salsa issue tracker, or that he will ask you to make a
> pull-request on salsa.
>
> git was step forward from svn/cvs -- now we can work on our version
> control system offline. Salsa issue tracker is a same step backward from
> debbugs -- it disables offline working with bugs.
>
> To be fair, there is very minor positive thing in salsa -- Gitlab CI.
> Its usefulness is limited, since there is no API to capture output in
> real time, so I still have to use sbuild on my local machine, but
> ability to rebuild package once in a week and get email on failure is
> good thing to prevent package rot.
>
> I know, Alioth was unmaintained, but just having box with sudo rules
> about adduser/usermod and Apache, running cgit would be much better
> replacement. Well, this ship sailed; I have been writing scripts to deal
> with madness around for a while, and it seems I will have to continue to
> do so.
> --
>     Note, that I send and fetch email in batch, once every 24 hours.
>  If matter is urgent, try https://t.me/kaction
>  
> --



-- 
YunQiang Su

Re: Server for system update of Debian in Sweden ?

[YunQiang Su]

lcf  于2018年12月6日周四 上午4:06写道：
>
> Hi
>
> My installed Debian version 9.5, is set up to use a Debian mirror in Denmark, 
> which it also uses automatically when I install packages.
>
> When I make a system update, it automatically connects to a Swedish server 
> with the address 151.101.84.133 SKYCA-3 Sweden. Is that OK?
>

It depends on your location and ISP.
If you feel the speed is acceptable, it is OK then.

Here is the list of mirrors:
https://www.debian.org/mirror/list

>
> Flemming Christensen
> Denmark
> --
> lcf 
>


-- 
YunQiang Su

AMD64 problem: mips cross gcc munmap_chunk(): invalid pointer (on AVX cpu only)

[Yunqiang Su]

I meet a problem of Debian’s cross toolchain.[1]
It happens for gcc-7/gcc-8 in Debian Sid/Buster, while not for gcc-6 in stretch.

This problem only appears on amd64, not on i386.
And this problems seems only on CPUs with AVX support, I have an old HP server, 
with CPU
   Intel(R) Xeon(R) CPU E7- 4807  @ 1.87GHz
works well. Which don’t support AVX.

Anybody has machines with AMD CPUs?

FYI: Windows Subsystem for Linux has this problem, too.

1. Install Debian testing/sid env on amd64
2. apt-get install gcc-8-mips64el-linux-gnuabi64 gcc-8-mips64-linux-gnuabi64 
gcc-8-mips-linux-gnu

These bellow cmd will show:
 munmap_chunk(): invalid pointer
 Aborted

$ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -c -mabi=32 -xc -
$ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -B/non_exists/ -c 
-mabi=32 -xc -
$ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -B/usr/share -c 
-mabi=32 -xc -
$ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -EB -c -mabi=32 
-xc -


These bellow cmd works well
# for both n32 or 64 abi, it works well
$ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -c -mabi=n32 -xc -
$ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -c -mabi=64 -xc -

# -B a path which contains MIPS cross assembler
$ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 
-B/usr/mips64el-linux-gnuabi64/bin/ -c -mabi=32 -xc -
$ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -B/usr/bin/ -c 
-mabi=32 -xc -

# none mips64el-linux-gnuabi64 toolchains works well.
$ echo "int a(){ return 1; }" | mips64-linux-gnuabi64-gcc-8 -c -mabi=32 -xc -
$ echo "int a(){ return 1; }" | mips64-linux-gnuabi64-gcc-8  -EL -c -mabi=32 
-xc -
$ echo "int a(){ return 1; }" | mipsel-linux-gnu-gcc-8 -c -mabi=64 -xc -
$ echo "int a(){ return 1; }" | mipsel-linux-gnu-gcc-8 -c -mabi=n32 -xc -
$ echo "int a(){ return 1; }" | mipsel-linux-gnu-gcc-8 -c -mabi=32 -xc -

With some debug, this problem is triggered in  gcc/gcc.c
static int
execute (void)
{
 ….
  pex_free (pex);


[1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915194
[2] gcc -v for these toolchains.

xxx@xxx:~$ mipsel-linux-gnu-gcc-8 -v
Using built-in specs.
COLLECT_GCC=mipsel-linux-gnu-gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/mipsel-linux-gnu/8/lto-wrapper
Target: mipsel-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-10' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm 
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support 
--enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos 
--enable-multiarch --disable-werror --enable-multilib --with-arch-32=mips32r2 
--with-fp-32=xx --with-madd4=no --with-lxc1-sxc1=no --enable-targets=all 
--with-arch-64=mips64r2 --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=mipsel-linux-gnu 
--program-prefix=mipsel-linux-gnu- --includedir=/usr/mipsel-linux-gnu/include
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-10)

xxx@xxx:~$ mips64el-linux-gnuabi64-gcc-8 -v
Using built-in specs.
COLLECT_GCC=mips64el-linux-gnuabi64-gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/mips64el-linux-gnuabi64/8/lto-wrapper
Target: mips64el-linux-gnuabi64
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-10' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm 
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support 
--enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos 
--enable-multiarch --disable-werror --enable-multilib --with-mips-plt 
--with-arch-64=mips64r2 --with-madd4=no --enable-targets=all 
--with-arch-32=mips32r2 --with-fp-32=xx --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=mips64el-linux-gnuabi64 --program-prefix=mips64el-linux-gnuabi64- 
--includedir=/usr/mips64el-linux-gnuabi64/include
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-10)

xxx@xxx:~$  mips64-linux-gnuabi64-gcc-8 -v
Using built-in specs.
COLLECT_GCC=mips64-linux-gnuabi64-gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/mips64-linux-gn

Re: About Sphinx search debian package

[YunQiang Su]

Adrian Nuta  于2018年8月30日周四 下午6:38写道：
>
> Hi YunQiang,
>
> Are you still maintaining the sphinxsearch deb package?

I just upload a minor version of Sphinx. Since I am not a heavy Sphinx
user or developer,
I guess I don't have enough knowledge to continue maintain it.

> Sphinx was forked last year (by some users) as Manticore, which is maintained 
> by most of the team that worked on Sphinx.
> Meanwhile, Sphinx got a major release, but it's only distributed as free 
> binaries, not open-source  and the old, open-source version is not maintained 
> anymore. So the current 2.2.11 that is in debian repos is a software without 
> support (we offer help to sphinx users, but this goes inevitable to switch to 
> manticore,as we did a lot of progress since we forked and doesn't make sense 
> to maintain older versions). Our fork is gplv2 (as the original project) and 
> we continue from where the last open source version left.
>
> My question for you is if you are interested to be maintainer for a manticore 
> debian package, as you worked with the sphinx before. We did some upgrades to 
> our compiling scripts, as now it uses cmake and can generate packages. In the 
> past, there wasn't much attention on distros packages (as we offered them on 
> software website) and there was only a ppa maintained, but we want to bring 
> manticore to distribution repositories to make it easier for users.
>
> If not, could you guide us how to proceed: either to find a maintainer or 
> package ourselves?

I guess guys on debian-devel may have a interesting.

Hi, Debian folks,
Who is heavy sphinx search user and have willing to maintain manticore?
If so, just pick up this package.

>
> Best regards
>
>
> --
> Adrian Nuta
> Director of Support
> http://www.manticoresearch.com
> https://github.com/manticoresoftware/manticore
>

Re:Missing: Mobile Debian-Solution referring to Smartphone Operating Systems (Alternative to Google/Android OS)

[YunQiang Su]

at first, you need a good ui and a set of base-apps. as i know, we don't have them yet.




在 Andreas Jakowidis ，2018年8月15日 下午5:59写道：

Dear Developers of Debian Operating-Systems and Debian-Software.

Because of a long experience in developing Debian-Software since the year 1995 it would be
important/necessary for everyone if you could offer Debian also as a mobile solution 
for smartphone hardware in near future.

As an alternative mobile operating system to Google OS (Android).

The clear and well-ordered surface of Debian would be an alternative to some commercial 
OS.

So that everyone get the choice to substitute Google OS with a Debian Mobile OS.

An own developed debian-based mobile-hardware is a further option.

But I would prefer a flexible usability (substitution of preinstalled Google-Android-OS)


Greetings,
Andreas Jakowidis







Versendet mit Emailn.de - Freemail 

* Unbegrenzt Speicherplatz
* Eigenes Online-Büro
* 24h besten Mailempfang
* Spamschutz, Adressbuch 

Re: [NLnet Labs Maintainers] Looking for new opendnssec and softhsm maintainer

[YunQiang Su]

On Tue, Aug 15, 2017 at 8:00 PM, Berry A.W. van Halderen
 wrote:
> On 31 July 2017, Ondřej Surý wrote:
>> I am looking for a new maintainer for opendnssec and softhsm package.
>> Honestly, I am not using neither, and it's quite hard to do a packaging
>> when you don't use the packages in question, and I think the package
>> suffer as a consequence, and I very much dislike that, so a new
>> maintainer using the package and interested in improving the Debian
>> packages would be great.
>
> At NLnet Labs we prefer these open source packages are better maintained
> by someone from within the (Debian) community.  It allows non-affiliated
> persons to be more in-tune with the packaging method of the distribution
> and are more free to make own choices.  We don't advocate a particular
> distribution.
>
> Having said that, we have a natural interest that the maintenance
> does not get orphaned.  I'm sure that one of us, on a personal
> basis (i.e. outside of our organization control) would want to
> volunteer, but only if there are really no other candidates and
> for a transitional period.  Our organization allows for us to do
> these kind of things, without NLnet Labs having any responsibility
> or accountability in this.
>
> But it would be a lot better for Debian as well to have others step in.

I moved softhsm2 to salsa, and upload 2.4.0 to Debian with 3 days delayed.
https://salsa.debian.org/debian/softhsm2

If you don't agree with it, please feel free to cancel it.

>
> With kind regards,
> Berry van Halderen
>



-- 
YunQiang Su

consider using arch-bits=32/64 syntax if possible?

[YunQiang Su]

I am working to port Debian to some new architectures, and some packages ftbfs
due to symbol file error, and most of them is due to difference
between 32bit and 64bit.

I noticed that in dpkg 1.18.0, dpkg-gensymbols has support a new syntax,
(arch-bits=32)32bit_specific_symbol@Base 1.0
(arch-bits=64)64bit_specific_symbol@Base 1.0

Since stretch's dpkg is greater than 1.18.0, backport won't be a quite
big block.
Should we ask for all packages use this new syntax if possible?

-- 
YunQiang Su

Re: Replacing apt's http method (dropping curl)

[YunQiang Su]

On Wed, Jun 28, 2017 at 2:00 AM, Julian Andres Klode  wrote:
> Hi everyone,
>
> as we discussed before in IRC, we plan to eventually replace
> our existing curl-based https method with our http method,
> by adding TLS support to it. This will move HTTPS support
> into apt proper, removing the apt-transport-https package.
>
> I'm not sure how long this will take, I hope we get something
> useful next month.
>
> Rationale
> =
> * The https method is split out of apt because curl has a lot
>   of dependencies (29 vs 7 on my test setup, 15.9 vs 4 MB of
>   disk space)
> * We want https to be a default these days, even if it provides
>   only minor security improvements.
> * Our http method is actually tested a lot because it is the
>   default and supports advanced features, the https method just
>   does curl easy stuff sequentially.
>
> Transition plan
> ===
> I plan to do this in two stages, both of which I expect to
> happen in unstable if all features have been implemented
> quickly. There might be feature-incomplete alphas in
> experimental.
>
> In the first stage, the "https" method is renamed to
> "https+curl", and a https->http symlink is added in apt.
>

I'd guess you have to help process the bootstrap process.
The TLS stuff is a quilt big trouble when bootstrap Debian for new
architecture.
So, I prefer the current schema, aka split https stuff to itself's
source package.

> If no significant regressions are reported (we might drop
> some options or increase some checks), and the package has
> been in testing for some time, the apt-transport-https
> package is removed.
>
> This ensures that (a) we get proper testing and (b) users
> have a workaround if something fails in that testing period.
>
> Implementation
> ==
> I so far implemented basic https support using GnuTLS, including
> SNI and certificate validation, and one (!) local CA file (as our
> tests need that). The code is incredibly hacky right now. And
> https->http redirects don't work yet.
>
> Alternatives would be to use libnss or openssl. In the latter
> case, we'd have to build a separate helper binary that does not
> link to the GPLed code, and just unwraps a TLS connection into
> a pipe (similar to stunnel) - we could also use a helper generally,
> it would allow us to run the TLS stack as nobody (!!!) [OK,
> we have to open the socket in the parent process and pass it
> down to the TLS stack, so _apt opens the connection for firewalls].
>
> The existing shitty proof of concept is available on GitHub:
>
> https://github.com/Debian/apt/compare/master...julian-klode:feature/http-https?expand=1
>
> But as I said it's ugly. It also does not yet link the http
> binary to the https binary.
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>



-- 
YunQiang Su

Re: Porter roll call for Debian Stretch

[YunQiang Su]

  Hi,

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the Stretch release (est. end
  of 2020):

  For mips, mipsel and mips64el, I
  - test most packages on this architecture
  - run a Debian testing or unstable system on port that I use regularly
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - triage d-i bugs
  - test d-i regularly
  - fix d-i bugs/issues
  - maintain buildds
  - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
jenkins.d.n (etc.)
  - run other automated tests outside the Debian QA services
 Run daily build test
 Run autopkgtest
  - ...

  I am a DD

  I believe the ports *are* ready to have -fPIE/-pie enabled by default.

  YunQiang Su

On Sun, Aug 28, 2016 at 11:53 PM, Aurelien Jarno  wrote:
> On 2016-08-17 22:05, ni...@thykier.net wrote:
>> Hi,
>>
>> Like last release, we are doing a roll call for porters of all release
>> architectures.  If you are an active porter behind one of the [release
>
> Does it really concerns *all* release architectures? Traditionally amd64
> and i386 have been granted waivers as "the toolchain maintainers are
> happy to support" these architectures "as-is". That said the toolchain
> maintainers do not fix ports specific bugs outside of the toolchain.
>
> While I fully agree that we can have a waiver for amd64 due to being the
> de facto standard architecture, it seems that a few leaf packages do
> not build on i386 and that we have no porters to fix them. That is
> probably still fine, but I wonder how fast the number of such packages
> will increase in the future.
>
>> architectures] for the entire lifetime of Debian Stretch (est. end of
>> 2020), please respond with a signed email containing the following
>
> What is the relation between the end of support of Stretch...
>
>> before Friday, the 9th of September:
>
>>  * Which architectures are you committing to be an active porter for?
>>  * Please describe recent relevant porter contributions.
>>  * Are you running/using Debian testing or sid on said port(s)?
>>  * Are you testing/patching d-i for the port(s)?
>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
>
> ... and the above questions?
>
> I fully agree that running testing/sid, fixing bugs or working on d-i up
> to the release of Stretch will improve its quality. But after the
> release it will improve the quality of Buster and later Bullseye. On the
> other hand running testing/sid after the release of Stretch will not
> help to catch bugs that can be fixed through a point release.
>
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net



-- 
YunQiang Su

Re: Porter roll call for Debian Stretch

[Yunqiang Su]

Sorry for the previous post without signature.

  Hi,

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the Stretch release (est. end
  of 2020):

  For mips, mipsel and mips64el, I
  - test most packages on this architecture
  - run a Debian testing or unstable system on port that I use regularly
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - triage d-i bugs
  - test d-i regularly
  - fix d-i bugs/issues
  - maintain buildds
  - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
jenkins.d.n (etc.)
  - run other automated tests outside the Debian QA services
 Run daily build test
 Run autopkgtest
  - ...

  I am a DD

  I believe the ports *are* ready to have -fPIE/-pie enabled by default.

  YunQiang Su

> 在 2016年8月31日，00:04，YunQiang Su  写道：
> 
>  Hi,
> 
>  I am an active porter for the following architectures and I intend
>  to continue this for the lifetime of the Stretch release (est. end
>  of 2020):
> 
>  For mips, mipsel and mips64el, I
>  - test most packages on this architecture
>  - run a Debian testing or unstable system on port that I use regularly
>  - fix toolchain issues
>  - triage arch-specific bugs
>  - fix arch-related bugs
>  - triage d-i bugs
>  - test d-i regularly
>  - fix d-i bugs/issues
>  - maintain buildds
>  - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
>jenkins.d.n (etc.)
>  - run other automated tests outside the Debian QA services
> Run daily build test
> Run autopkgtest
>  - ...
> 
>  I am a DD
> 
>  I believe the ports *are* ready to have -fPIE/-pie enabled by default.
> 
>  YunQiang Su
> 
> On Sun, Aug 28, 2016 at 11:53 PM, Aurelien Jarno  wrote:
>> On 2016-08-17 22:05, ni...@thykier.net wrote:
>>> Hi,
>>> 
>>> Like last release, we are doing a roll call for porters of all release
>>> architectures.  If you are an active porter behind one of the [release
>> 
>> Does it really concerns *all* release architectures? Traditionally amd64
>> and i386 have been granted waivers as "the toolchain maintainers are
>> happy to support" these architectures "as-is". That said the toolchain
>> maintainers do not fix ports specific bugs outside of the toolchain.
>> 
>> While I fully agree that we can have a waiver for amd64 due to being the
>> de facto standard architecture, it seems that a few leaf packages do
>> not build on i386 and that we have no porters to fix them. That is
>> probably still fine, but I wonder how fast the number of such packages
>> will increase in the future.
>> 
>>> architectures] for the entire lifetime of Debian Stretch (est. end of
>>> 2020), please respond with a signed email containing the following
>> 
>> What is the relation between the end of support of Stretch...
>> 
>>> before Friday, the 9th of September:
>> 
>>> * Which architectures are you committing to be an active porter for?
>>> * Please describe recent relevant porter contributions.
>>> * Are you running/using Debian testing or sid on said port(s)?
>>> * Are you testing/patching d-i for the port(s)?
>>> * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>>   also apply to this port? [0]
>> 
>> ... and the above questions?
>> 
>> I fully agree that running testing/sid, fixing bugs or working on d-i up
>> to the release of Stretch will improve its quality. But after the
>> release it will improve the quality of Buster and later Bullseye. On the
>> other hand running testing/sid after the release of Stretch will not
>> help to catch bugs that can be fixed through a point release.
>> 
>> Aurelien
>> 
>> --
>> Aurelien Jarno  GPG: 4096R/1DDD8C9B
>> aurel...@aurel32.net http://www.aurel32.net
> 
> 
> 
> --
> YunQiang Su



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[YunQiang Su]

On Fri, Jul 8, 2016 at 10:55 PM,   wrote:
> I value stability of a FS over other considerations like shiny new features 
> and performance. I know that Debian Stable includes only that versions of 
> software that were considered rock-solid and mostly bug-free. But on the 
> other hand I read documentation for version of a Linux kernel of Debian 
> Stable and it says that btrfs is under heavy development and isn't suitable 
> for any uses other than benchmarking and review. Proof-link: 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v3.16.36

Believe the upstream.
While in the nearest kernel, there is no sentence about "under heavy
development".
Installer is just installer.

>
>
> I'm really confused, I don't know whom to believe.
>



-- 
YunQiang Su

Re: Xeon Phi port

[YunQiang Su]

On Sun, Aug 9, 2015 at 6:02 PM, Václav Šmilauer  wrote:
> Hi devs,
>
> I am currently trying to complie numerical simulation code Woo [1] to run on
> Xeon Phi. Woo is written in a mix of Python and c++, using a number of c++
> libs and Python packages.
>
> As you may know, Xeon Phi is 60-core (240 Hyper-Threaded cores) card with
> 4-16GB RAM, Pentium-like cores and ISA with many extensions for 64bit and
> parallel computing; it can be used either as co-processor for CPU tasks, or
> as a standalone machine accessible over virtual network between the host and
> the card. The card itself boots minimalistic Linux and userland
> (Yocto-based) and has access to the host filesystem through NFS. The
> platform is identified as x86_64-k1om-linux-gnu; gcc, binutils and glibc
> support this arch since a few years back (gcc supports it as target, but
> does not have target-specific optimizations, which are only present in the
> commercial Intel compiler).
>
> My experience with Yocto was not great (it fails to build with newer headers
> in the system), and Intel's forum seems to welcome only people running huge
> clusters in this segment.
>
> The first goal of this port would be to bootstrap Debian (using gcc+binutils
> as cross-compiler, those are available from Intel IIRC) and use its
> cross-compiled userland (compiler, packaging infrastructure) over NFS to
> compile other packages on the card itself, using cross-compiled native
> compiler (Python cannot be really cross-compiled currently).
>
> Second optional goal would be to compile some of the debian packages (many
> wouldn't make sense) on the card natively and have pre-built binaries in the
> public archive.
>
> After that, see how feasible it would be to boot Debian itself on the card
> -- that might be complicated due to special services for the card (like
> virtual network, configuration framework, no access to console while booting
> AFAIK) and is perhaps not really needed.
>

FIrst, you should make sure gcc/linux/glibc works for Phi,
and then bootstrap them with these steps:

https://wiki.debian.org/MultiarchCrossToolchainBootstrap

You will need to figure out your patch for these 3 packages' debian/ staff.

> From what I understood, the porting infrastructure is being consolidated at
> the moment, so I would appreciate some guidance on where to start; if there
> is a more specific and more suitable list (debian-ports was shut down
> recently), please let me know. Maybe some other Debian developers have the
> same interest, or more experience with Xeon Phi.
>
> Looking forward to fruitful discussion.
>
> Cheers, Václav
>
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794710



-- 
YunQiang Su


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cakcpw6vx+ts0npku-kpdywqpknqal2cci5v+hc8qygi0eg6...@mail.gmail.com

Re: Can a leaf package require SSE2 on i386?

[YunQiang Su]

On Tue, Sep 16, 2014 at 7:05 AM, Samuel Thibault  wrote:
> Thomas Goirand, le Mon 15 Sep 2014 20:45:27 +0800, a écrit :
>> On 09/15/2014 05:17 PM, Samuel Thibault wrote:
>> > Thomas Goirand, le Mon 15 Sep 2014 16:53:25 +0800, a écrit :
>> >> I suppose (according to what's above) that using
>> >> /usr/lib/sse4.2/x86_64-linux-gnu isn't supported (yet), right?
>> >
>> > I guess it shouldn't be hard to add the support, once the need is
>> > expressed :)
>> >
>> > Samuel
>>
>> Really? Ok... then *I NEED IT* ! :)
>
> As a bug report against libc6, I meant.
>
> Samuel
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> https://lists.debian.org/20140915230525.ga2...@type.youpi.perso.aquilenet.fr
>

I meet the similar problem: a package (shine) set itself as mips32r2.
I found it when I try dig out why it ftbfs on mips64el.

-- 
YunQiang Su


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cakcpw6xcheuauh44+przyhbfkau0xz10eg6zro9j1nkh98l...@mail.gmail.com

Re: preparing for GCC 4.9 (bug squashing on May 16/17)

[Yunqiang Su]

On Wed, May 14, 2014 at 12:10 AM, Matthias Klose  wrote:
> Am 13.05.2014 17:44, schrieb Yunqiang Su:
>> Do you plan make 4.9 the only version of gcc in jessie?
>
> This first depends on building the kernel, both linux and kfreebsd, and eglibc
> using gcc-4.9.
>
I tried build eglibc with gcc-4.9, and use it. All of them works well.

For kernel, gcc-4.8/4.9 have a problem: the prevent the Loongson 3 kernel boot.
We still have no idea why. gcc-4.7 works fine.


-- 
Yunqiang Su


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKcpw6UU-iM35oqXiOkyF_L3W9S5BmceRwOhBF4EbR=r2y0...@mail.gmail.com

Re: preparing for GCC 4.9 (bug squashing on May 16/17)

[Yunqiang Su]

On Tue, May 13, 2014 at 8:56 PM, Matthias Klose  wrote:
> With gcc-4.9 now available in testing, it is time to prepare for the change of
> the default to 4.9, for a subset of architectures or for all (release)
> architectures.  The defaults for the gdc, gccgo, gcj and gnat frontends 
> already
> point to 4.9 and are used on all architectures.  Issue #746805 tracks the
> gfortran default change, including the change of the Fortran 90 module 
> version.
>
> An email a week ago to debian-{release,ports} [1] didn't show any obvious
> blockers, and various test rebuilds don't show at least any internal compiler
> errors anymore.
>
> The Debian archive was rebuilt twice on amd64, once in February, resulting in
> bug submissions for GCC and feedback for the porting guide [2], a second time 
> in
> March to file issues for packages failing to build with GCC 4.9 [3].  Another
> test rebuild for mips64 didn't show any additional build failures [4]. Another
> test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other
> compiler regressions on these architectures.
>
> I'll work on fixing the build failures in [3], help is of course appreciated.
> Trying to be online on May 16/17 on IRC #debian-toolchain (OFTC) and uploading
> packages to the delayed queue.
>
> Almost all build failures are analysed and should be easy to fix (exceptions
> e.g. #746883).  Patches for the ones not caused by the Debian packaging may be
> found in distributions already using GCC 4.9 as the default compiler (e.g.
> Fedora 21).
>
> If anything goes well, and a large amount of build failures are fixed, I plan 
> to
> make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of 
> May,
> beginning of June.
>
> Bugs reports for packages building with a legacy version of GCC (4.6, 4.7) are
> filed [5] [6], and will be filed for 4.8 once 4.9 is the default.

Do you plan make 4.9 the only version of gcc in jessie?

>
>   Matthias
>
> [1] https://lists.debian.org/debian-release/2014/05/msg00086.html
> [2] http://gcc.gnu.org/gcc-4.9/porting_to.html
> [3]
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org
> [4] https://lists.debian.org/debian-release/2014/05/msg00087.html
> [5]
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gcc-4.6-legacy;users=debian-...@lists.debian.org
> [6]
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gcc-4.7-legacy;users=debian-...@lists.debian.org
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/53721687.2000...@debian.org
>



-- 
Yunqiang Su


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cakcpw6wbhlne-noqodj0b26jod+jfg22h2qbsvs0qu+xep6...@mail.gmail.com

mips64el: FTBFS list and buildlogs

[Yunqiang Su]

After more than 2 month rebuild, we have more than 7k packages built
successfully,
and more than 1k in queue, and it will be more with the process of build.

You can get the buildlogs from
http://mips.wicp.net:9998/mips2/buildlog/

The FTBFS list (aka attempted in sbuild) can be get from
http://mips.wicp.net:9998/mips2/temp/mips64el-attempted.txt

If you have interest on fixing these ftbfs, they may be helpful.


-- 
Yunqiang Su


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKcpw6VxJ1UWQ0mmZ6hs+cQiyNvomwWNh0=tj8mwmwc3agi...@mail.gmail.com

Re: ld.so for multiarch and multilib installed at same time

[Yunqiang Su]

On Fri, Apr 25, 2014 at 9:00 PM, Andrey Rahmatullin  wrote:
> On Fri, Apr 25, 2014 at 06:49:49PM +0800, Yunqiang Su wrote:
>> >>On amd64 system:
>> >>
>> >> libc6-i386  make /lib/ld-linux.so.2  link to /lib32/ld-linux.so.2 and 
>> >> link to
>> >>   /lib32/ld-2.18.so
>> >>
>> >>libc6:i386 make /lib/ld-linux.so.2 link to /lib/i386-linux-gnu/ld-2.18.so
>> >>
>> >>when these 2 packages installed at the same time
>> >> /lib/ld-linux.so.2 is linked to /lib/i386-linux-gnu/ld-2.18.so
>> >>
>> >>And dpkg is happy about that this happens.
> [...]
>
>> The problems is why on amd64, dpkg is happy about it?
> I'm not sure what the original question is, but the answer is most likely
> "Replaces: libc6-i386" in libc6:i386.
>

Thank you very much.
I refreshed this patch:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715038

> --
> WBR, wRAR
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/20140425130046.gb31...@belkar.wrar.name
>



-- 
Yunqiang Su


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cakcpw6xgvrcjjau4sk+-642pxuxwpkxlnp73rzvum6rrm_s...@mail.gmail.com

Re: ld.so for multiarch and multilib installed at same time

[Yunqiang Su]

On Fri, Apr 25, 2014 at 5:58 PM, Steve McIntyre  wrote:
> Yunqiang Su wrote:
>>On amd64 system:
>>
>> libc6-i386  make /lib/ld-linux.so.2  link to /lib32/ld-linux.so.2 and link to
>>   /lib32/ld-2.18.so
>>
>>libc6:i386 make /lib/ld-linux.so.2 link to /lib/i386-linux-gnu/ld-2.18.so
>>
>>when these 2 packages installed at the same time
>> /lib/ld-linux.so.2 is linked to /lib/i386-linux-gnu/ld-2.18.so
>>
>>And dpkg is happy about that this happens.
>
> What's responsible for making the links? Are they directly in the
> package, or made by postinst etc.? Are the 2 packages sensible in
> terms of multi-arch setup?

ldso is the load of binary, it is the entrance of any binary execution.
On any system, it is fixed

please see:
https://wiki.debian.org/Multiarch/LibraryPathOverview#ELF interpreter

It is directly in these packages.

>
>>On mips64el system:
>>
>>libc6-mips32 make /lib/ld.so.1 link to /lib/ld-2.18.so
>> (yes, quite strange, mips system asks for use /lib as o32
>>multilib path)
>
> Meh, it's not doing the braindead /lib32 thing. That shouldn't be a
> problem. :-)

lib32 is left for n32 multilib on mips* systems.

>
>>libc6:mipsel make /lib/ld.so.1 link to /lib/mipsel-linux-gnu/ld-2.18.so
>>
>>When try to install these 2 packages both, dpkg will be unhappy:
>>
>>dpkg: error processing archive libc6_2.18-4_mipsel.deb (--install):
>> trying to overwrite '/lib/ld.so.1', which is also in package
>>libc6-mips32 2.18-4
>>Errors were encountered while processing:
>>
>>
>>I also tried to repack libc6:mipsel to link /lib/ld.so.1 to
>>/lib/mipsel-linux-gnu/ld.so.1
>>instead of ld-2.18.so directly.
>>It aslo has the same problem.
>
> Well, you're still trying to replace the same file (link) on
> disk. dpkg is not going to be happy with that, unless they're
> consistent for multi-arch.
>

The problems is why on amd64, dpkg is happy about it?

> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
> Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/



-- 
Yunqiang Su


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKcpw6W9vrU5+TmvXPiw=zvugccrsau7ynywcbb53gunns3...@mail.gmail.com

ld.so for multiarch and multilib installed at same time

[Yunqiang Su]

On amd64 system:

 libc6-i386  make /lib/ld-linux.so.2  link to /lib32/ld-linux.so.2 and link to
   /lib32/ld-2.18.so

libc6:i386 make /lib/ld-linux.so.2 link to /lib/i386-linux-gnu/ld-2.18.so

when these 2 packages installed at the same time
 /lib/ld-linux.so.2 is linked to /lib/i386-linux-gnu/ld-2.18.so

And dpkg is happy about that this happens.


On mips64el system:

libc6-mips32 make /lib/ld.so.1 link to /lib/ld-2.18.so
 (yes, quite strange, mips system asks for use /lib as o32
multilib path)

libc6:mipsel make /lib/ld.so.1 link to /lib/mipsel-linux-gnu/ld-2.18.so

When try to install these 2 packages both, dpkg will be unhappy:

dpkg: error processing archive libc6_2.18-4_mipsel.deb (--install):
 trying to overwrite '/lib/ld.so.1', which is also in package
libc6-mips32 2.18-4
Errors were encountered while processing:


I also tried to repack libc6:mipsel to link /lib/ld.so.1 to
/lib/mipsel-linux-gnu/ld.so.1
instead of ld-2.18.so directly.
It aslo has the same problem.


Is it a problem of dpkg or eglibc?

-- 
Yunqiang Su


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKcpw6UAEZ17Fvvfk=0anagsQppa9Qter5u=fha3la9dqmy...@mail.gmail.com

Re: Roll call for porters of architectures in sid and testing

[YunQiang Su]

在 2014年1月21日，下午9:51，Aníbal Monsalve Salazar  写道：

> On Tue, Jan 21, 2014 at 01:43:55PM +0100, Matthias Klose wrote:
>> Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar:
>>> For mips/mipsel, I - fix toolchain issues together with other
>>> developers at ImgTec
>> 
>> It is nice to see such a commitment, however in the past I didn't see
>> any such contributions.
> 
> Hello doko,
> 
> At my current job, we are working on fixing mips* bugs including
> possible compiler errors. As an example, I recently run tests to try to
> find tool chain errors for packages that on non-Debian distro were
> failing to build. So, at least so far, I'm working on that.
> 
> Regards,
> 
> Aníbal

  Hi,

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:

  For mipsel/mips64el and maybe mips/mips64, I
  - test most packages on this architecture
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - maintaining rebuild test

  I am a DM

  Yunqiang Su


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: MIPS64EL rootfs available for use and test

[YunQiang Su]

Anybody can help to test whether the out current webkit workable?

Maybe by install epiphany-browser and use it?

All of my board/laptops are working as build nodes.

If it work, can you reply to
https://bugs.webkit.org/show_bug.cgi?id=124370
and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729572
?

On Thu, Nov 14, 2013 at 7:31 PM, Graham Whaley  wrote:
>
> On 14 November 2013 00:46, David Daney  wrote:
>>
>> On 11/13/2013 04:32 PM, YunQiang Su wrote:
>>>
>>> On Thu, Nov 14, 2013 at 8:03 AM, David Daney 
>>> wrote:
>>>>
>>>> On 11/11/2013 09:57 AM, 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/
>>>>>
>>>>
>>>> Nice!
>>>>
>>>> I tested it on our OCTEON boards.  Seems to be working.  I had to enable
>>>> CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT in my kernel and edit
>>>> /etc/inittab
>>>> to put gettys on my serial ports, and set the root password.  But after
>>>> that, it works seemingly without a hitch.
>>>
>>> Great news, while wait... does OCTEON support little endian?
>>
>>
>> Yes.  The kernel.org kernel doesn't yet contain full little-endian
>> support, but getting little-endian support merged is on our list of things
>> to do.
>>
> Hi David,
>  out of interest, do you know if there are any commercially (ideally easily
> and cheaply ;-) available boards out there that can run Octeon little
> endian? afaik things like the CN5020 based boards like the Erlite-3 and
> CAM-0100 only do big, and afaik there is no (documented) way to jumper them
> differently.
>  My presumption is that the Cavium Octeon devboards from Cavium themselves
> (available I believe, but not too cheap) can do both?
>
>  Graham
>
>>
>> David Daney
>>
>>
>>
>>>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> 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/52841d71.3090...@caviumnetworks.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/CAKcpw6Xi6RfO-VxsnLscG__Pzwws=NmaXMAFZ6VP1v=ro3z...@mail.gmail.com

Re: MIPS64EL rootfs available for use and test

[YunQiang Su]

On Thu, Nov 14, 2013 at 8:03 AM, David Daney  wrote:
> On 11/11/2013 09:57 AM, 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/
>>
>
> Nice!
>
> I tested it on our OCTEON boards.  Seems to be working.  I had to enable
> CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT in my kernel and edit /etc/inittab
> to put gettys on my serial ports, and set the root password.  But after
> that, it works seemingly without a hitch.
Great news, while wait... does OCTEON support little endian?
>
>
>
>> 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/cakcpw6xejpylmqutg+r7y5gshmfjeaij_53spz80ein+ew0...@mail.gmail.com

Re: MIPS64EL rootfs available for use and test

[YunQiang Su]

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

Re: MIPS64EL rootfs available for use and test

[YunQiang Su]

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

MIPS64EL rootfs available for use and test

[YunQiang Su]

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

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

[YunQiang Su]

On Tue, Oct 29, 2013 at 10:50 PM, Graham Whaley  wrote:
>
>
>
> On 29 October 2013 13:34, Aron Xu  wrote:
>>
>>
>> It would require much more resource to spend on making more ports,
>> this means more build machines and man power, which is not sufficient
>> at mean time.
>>
>
> True. I hopefully have some resource coming online, and I may also have some
> in-house build hardware available to help with any unofficial ports. We will
> just have to be pragmatic, and it will take time...
Let's pull Fuxin Zhang in and ask him about it.
@Fuxin:
Is there a server available to by which support IPMI? How about its precise?
Or is their any something else which is suitable for build machine?
Imgtec may purchase some.
>
>  Graham



-- 
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/CAKcpw6Vm+6t9+TVJ9sZn00Hp8d30AANdye8z91=UF=y9f-c...@mail.gmail.com

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

[YunQiang Su]

On Sat, Oct 26, 2013 at 9:50 AM, Paul Wise  wrote:
> On Sat, Oct 26, 2013 at 12:22 AM, YunQiang Su wrote:
>
>> After more than half of a year's hard work, we have the mips64el port
>> almost done.
>> Now we have more than 7600 packages build successfully.
>
> Congrats!
>
> Please create a page on the Debian wiki and or update the MIPSPort
> wiki page about this new architecture. You could also send patches to
> update the list of ports on the Debian website:
>
> https://wiki.debian.org/MIPSPort
> http://www.debian.org/ports/
> http://www.debian.org/ports/mips/
> http://www.debian.org/devel/website/
I have update the wiki pages and working on update WML.
>
>> The current build status can be found in http://vip.moonux.org/attempted/
>
> Would you like me to register mips64el.debian.net and CNAME it to
> vip.moonux.org or another domain?
>
>> Now I get a new board and give it 18GiB DDR3 memory and 1TB hardisk.
>> Most important is that it is running a Debian Unstable, MIPS64EL.
>>
>> Anyone has need to port package(s) can apply a account.
>> Please post me your ssh public key signed by a trust-able PGP key.
>
> You should probably talk to DSA about getting it a debian.net domain
> and getting it listed in LDAP as a porter machine.
>
> https://db.debian.org/machines.cgi
I have mailed to DSA, and am waiting for their response.
>
>> I also working on make a rootfs to make it easy to install this port.
>
> In Debian we usually expect people to either run debootstrap or d-i to
> perform Debian installations since otherwise some files that should be
> different between installs will be identical. So please just point
> people at debootstrap instead. This is a problem with Debian that we
> currently have to work around once for every image creation tool; all
> of debian-live, cloud images, mips64el rootfs' etc  need/have hacks to
> remove files like the dbus machine identifier or the openssh host keys
> from the system after debootstrap has run.
The patch for loongson 3A has not be in upstream kernel.
The D-I support is not possible for now.
Live system may be a good option.
>
>> Here we still have 2 problems:
>>1. I believe that it is time of use to talk about how to make this
>> port to debian-ports.org.
>> Anyone can help us?
>
> http://www.debian-ports.org/contacts
>
> I have heard rumours on IRC that debian-ports.org is having resource
> issues so adding new ports there might be hard.
>
>>2. Which ISA  to be used for this port when it is in debian-ports.
>> Now we use mips64r2 with tune loongson3a.
>> Should we downgrade ISA requirement to mips3 or mips64?
>
> That is up to yourself and people who own or otherwise care about MIPS
> hardware. Take into consideration what hardware is available
> commercially now and will be in the future, as well as what hardware
> most people already own. I don't know much about GCC tuning but I
> expect that tuning for one specific machine isn't a good idea.
>
> For future the future steps, here are the requirements for adding
> mips64el to the archive and getting it officially included in a future
> Debian release:
>
> https://ftp-master.debian.org/archive-criteria.html
> http://release.debian.org/testing/arch_policy.html
Thanks for you link.
>
> --
> 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/caktje6en85omcxtdu+3-zj3-k5rgppemiwg6vah1jpbe2sc...@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/CAKcpw6UVzKe5q8fO_02fVYOp04jxVW5y9=cxrn766e6onkf...@mail.gmail.com

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

[YunQiang Su]

On Tue, Oct 29, 2013 at 7:05 PM, Graham Whaley  wrote:
> On 25 October 2013 17:22, YunQiang Su  wrote:
>
>> After more than half of a year's hard work, we have the mips64el port
>> almost done.
>> Now we have more than 7600 packages build successfully.
>> The current build status can be found in http://vip.moonux.org/attempted/
>
>
> Hey! - well done. That's quite some effort!
>
>>
>> Now I get a new board and give it 18GiB DDR3 memory and 1TB hardisk.
>> Most important is that it is running a Debian Unstable, MIPS64EL.
>
>
> Nice. Can I ask which board that is? I have some boards reserved for me in
> Loongson that I am highly likely to purchase, and suspect (but would like to
> confirm) that they are the same board that you are using. I will also check
> on any further availability. If I can I will donate one/some of these for
> Debian as well.
I prefer that you don't purchase this model of board: I can even not
use the power
button of chassis. Maybe that you can purchase a newer model.
If  IPMI is available, it will be much better.
>
>>
>> Anyone has need to port package(s) can apply a account.
>> Please post me your ssh public key signed by a trust-able PGP key.
>>
>> I also working on make a rootfs to make it easy to install this port.
>>
>> Here we still have 2 problems:
>>1. I believe that it is time of use to talk about how to make this
>> port to debian-ports.org.
>> Anyone can help us?
>
> One of the issues will be hardware availability. If I can source the above
> boards (which it looks like I can), then I can help with that. Also, we are
> trying out the Loongson 2F mini-PC's, expanding their RAM to their maximum
> (which may only be 1Gbyte, but we hope 2Gbyte), and adding SSD's. If that
> works out then they are cheaper, available, and we can relatively easily
> build a small farm of those for (donated to) Debian I hope.
Great news.
Without DMA, my current WD blue disk has a speed about 50MB/s.
>
>>
>>2. Which ISA  to be used for this port when it is in debian-ports.
>> Now we use mips64r2 with tune loongson3a.
>> Should we downgrade ISA requirement to mips3 or mips64?
>>
>
> Much though I would love to say go with MIPS64R2, I suspect for the main
> debian-ports.org upload that is not the best single choice. The Loongson 2F
> cores are MIPSIII I believe, as are some other platforms. I have a suspicion
> that some of the Broadcom chips for instance are MIPS32R1.
> I would suggest that we go with MIPSIII for the first mips64le upload, and
> then we can work on MIPS32R2 for the 'unofficial ports' to begin with. What
> do you think ?
It is also my opinion. Use MIPSIII can make more people use it, and we can
work with some of other unofficial ports.
>
>>
>> Thanks for all of the people helped me to make this project be realized:
>> Eleanor Chen, Aron Xu,  Anthony Fok, Fuxin Zhang from Lemote and lots
>> of other people.
>>
>
> You have my thanks as well :-)
>
>>
>> --
>> YunQiang Su
>>
> Graham
>
>>
>>
>> --
>> 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/CAKcpw6WvRdF-9O7HKZSr_Vr_ZugF4W0VbTsd=cx-3=qawpz...@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/cakcpw6upmbad8xydoovmmslvs5h6mjtagt90bvqvyxyo1s-...@mail.gmail.com

MIPS64EL port box is ready for use (Was: mips64el port build failed list)

[YunQiang Su]

After more than half of a year's hard work, we have the mips64el port
almost done.
Now we have more than 7600 packages build successfully.
The current build status can be found in http://vip.moonux.org/attempted/

Now I get a new board and give it 18GiB DDR3 memory and 1TB hardisk.
Most important is that it is running a Debian Unstable, MIPS64EL.

Anyone has need to port package(s) can apply a account.
Please post me your ssh public key signed by a trust-able PGP key.

I also working on make a rootfs to make it easy to install this port.

Here we still have 2 problems:
   1. I believe that it is time of use to talk about how to make this
port to debian-ports.org.
Anyone can help us?
   2. Which ISA  to be used for this port when it is in debian-ports.
Now we use mips64r2 with tune loongson3a.
Should we downgrade ISA requirement to mips3 or mips64?

Thanks for all of the people helped me to make this project be realized:
Eleanor Chen, Aron Xu,  Anthony Fok, Fuxin Zhang from Lemote and lots
of other people.

-- 
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/CAKcpw6WvRdF-9O7HKZSr_Vr_ZugF4W0VbTsd=cx-3=qawpz...@mail.gmail.com

Re: mips64el port build failed list

[YunQiang Su]

On Wed, Oct 16, 2013 at 3:02 AM, Bernd Zeimetz  wrote:
> hi!
>
> On 10/15/2013 03:59 PM, YunQiang Su wrote:
>>>> The buildlog of these packages can be found in
>>>>  http://vip.moonux.org/attempted/
>
>
> Looking at one of my pet packages (gpsd):
>
> dpkg-checkbuilddeps: Unmet build dependencies: pps-tools (>=
> 0.20120406+g0deb9c7e-2~)
After install pps-tools manually, It built successfully now.
>
> but I don't see that building pps-tools failed, at least its not in the list. 
> Am
> I missing something or is there just something confused about the right order 
> to
> build packages?
>
>
> Cheers,
>
> Bernd
>
>
> --
>  Bernd ZeimetzDebian GNU/Linux Developer
>  http://bzed.de    http://www.debian.org
>  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



-- 
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/CAKcpw6XcKW7DKWXSBQR-e8nn4uU9FY5A8a2EEMkwzbCe3R=e...@mail.gmail.com

Re: mips64el port build failed list

[YunQiang Su]

On Tue, Oct 15, 2013 at 11:23 PM, Paul Wise  wrote:
> On Tue, Oct 15, 2013 at 7:33 PM, YunQiang Su wrote:
>
>> We are working on the port of mips64el, and the progress is quite good.
>
> Please add that to debian-ports.org so that maintainers can find
> failed build logs linked from the PTS and work on fixing the issues.
> Until you are able to add mips64el to debian-ports.org, please at
> least provide the output of the dd-list command so that pro-active
I still cannot add it to debian-ports now. The dd-list output can be found
http://vip.moonux.org/attempted/0_dd-list.txt.xz

> maintainers can fix issues early. Do you have a machine that
> maintainers can access to port their packages to mips64el?
I am trying to build the third machine up, while I met some trouble.
So at least several days may be needed.
>
> Please add your architecture characteristics here:
>
> https://wiki.debian.org/ArchitectureSpecificsMemo
Added while
long long alignment , alignment of long, max alignment, unaligned access OK,
func param location, func return ptr location, page size(s)
need to be ensured again.
>
> --
> 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/caktje6hunru4ce1mwhl9aondncpnwkqmkouup233xtyuakk...@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/CAKcpw6UmHXnCfSnpjh6o8AFX9h895HHZCJaM1qDHu=zfuoi...@mail.gmail.com

Re: mips64el port build failed list

[YunQiang Su]

On Tue, Oct 15, 2013 at 9:53 PM, Adam D. Barratt
 wrote:
> On 2013-10-15 12:33, YunQiang Su wrote:
>>
>> http://192.168.252.248/attempted/0_attempted.txt
sorry for me, it should be
http://vip.moonux.org/attempted/0_attempted.txt
>> is the list of packages which have tried to build while failed,
>> which is so called attempted in sbuild.
>
>
> That's a private IP address, so not that helpful to others. :-) There is a
> file named "0_attempted.txt" at the other URL you mentioned:
>
>
>> The buildlog of these packages can be found in
>>  http://vip.moonux.org/attempted/
>
>
> Regards,
>
> Adam
>
>
> --
> 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/b86d78c29951c167d169655a0b898...@mail.adsl.funky-badger.org
>



-- 
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/cakcpw6wyph7smcdzmvchy6xvzal2qnrnzvowibmu8ninyfn...@mail.gmail.com

mips64el port build failed list

[YunQiang Su]

We are working on the port of mips64el, and the progress is quite good.

We have about 11000 packages to build for this port.
About 2666 packages are not in build queue, due to lack of build-deps
About 695 packages are building or waiting or attempted
   or failed to build due to something wrong
The others are successfully built (maybe with our patches)

http://192.168.252.248/attempted/0_attempted.txt
is the list of packages which have tried to build while failed,
which is so called attempted in sbuild.

The buildlog of these packages can be found in
 http://vip.moonux.org/attempted/

The help of to fix these build is warm welcomed.

-- 
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/cakcpw6u4hxoljori3ow9efrbxga-estrlqgpybdaqi4x2jj...@mail.gmail.com

Re: Bootstrappable Debian - a decision is needed, patches exist

[YunQiang Su]

On Tue, Oct 15, 2013 at 2:03 PM, Johannes Schauer  wrote:
> Hi,
>
> This email is a follow up on the thread started January 2013 [1]. In summary:
> it seems that the ability to bootstrap Debian from scratch and the requirement
> to extend the Build-Depends syntax meet general agreement.
>
> What is yet to be decided is the concrete format for the Build-Depends syntax 
> extension. The first proposals suggested a syntax which looked like
>
> Build-Depends: foo [amd64] 
I'd prefer Build-Depends-Stage1 if possible.
When bootstrap, dpkg only ask for these build-depends while for normal build,
dpkg should merge Build-Depends-Stage1 and Build-Depends.
>
> Which would indicate that the build dependency "foo" would not apply if the
> build profile called "stage1" is activated. It was critisized [2] that this
> syntax wastes a meta character and thus prohibits future extensions of the
> Build-Depends syntax. Therefore the second proposal (finalised at debconf13)
> looked like this:
>
> Build-Depends: foo [amd64] [!profile.stage1]
>
> The rectangular brackets are reused and a prefixed namespace is used to
> indicate that "stage1" is a build profile name. We hoped this would be the
> final spec, given the previous discussion, but those brackets also got some
> pushback [3] and thus the third version was born:
>
> Build-Depends: foo [amd64] 
>
> We wrote down the last two options in form of a spec on the Debian wiki [11].
>
> Patches for dpkg, python-debian, apt and sbuild implementing the original
> format have existed for years [4]. Patches for the new formats have existed 
> for
> some time as well [5]. They are surely not perfect but we would like to get
> them into a state in which they can be integrated into dpkg. But for that we
> need some feedback from the dpkg devs as well as a final decision of the 
> Debian
> community about which syntax to choose. We are writing to d-devel this time
> because the thread on d-dpkg [6,7] has been dormant for a month once again.
> Maybe bringing this issue to a wider audience will help make a decision on 
> this
> problem. The results from two years of GSoC [8,9] as well as the year long
> efforts of others [10] cannot bear any fruit without this issue finally being
> taken care of.
>
> Thank you!
>
> josch & wookey
>
> [1] http://lists.debian.org/20130115181840.GA16417@hoothoot
> [2] http://lists.debian.org/20726.45081.38709.233...@chiark.greenend.org.uk
> [3] http://lists.debian.org/20130816121504.gb20...@gaara.hadrons.org
> [4] http://people.debian.org/~wookey/bootstrap/patches/profiles/tools/
> [5] http://lists.debian.org/20130917103117.2726.40546@hoothoot
> [6] http://lists.debian.org/20130419194252.17205.76995@hoothoot
> [7] http://lists.debian.org/debian-dpkg/2013/08/msg00019.html
> [8] http://www.alkmim.eti.br/~alkmim/gitrepo/autobootstrap.git
> [9] https://gitorious.org/debian-bootstrap/botch
> [10] http://people.debian.org/~wookey/bootstrap
> [11] https://wiki.debian.org/BuildProfileSpec
>
>
> --
> 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/20131015060337.7934.42627@hoothoot
>



-- 
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/CAKcpw6VGjrC=++ka2cjq8bp6r8w8y4odviddtfr2nunsjlk...@mail.gmail.com

Re: Upcoming changes in Tcl/Tk packaging

[YunQiang Su]

On Wed, Sep 25, 2013 at 5:39 PM, Matthias Klose  wrote:
> Am 25.09.2013 10:25, schrieb Sergei Golovan:
>> Hi fellow developers,
>>
>> I would like to introduce a few significant changes into Debian Tcl/Tk
>> packages. Some of them have quite significant impact on their reverse
>> dependencies which will need a transition, I think. The proposed
>> changes are already in the experimental branch, so anyone could try
>> and break things.
>>
>> The changes are (I use Tcl/Tk 8.5 as an example, but the same changes
>> are applied to 8.4 and 8.6 as well):
Will there is a /usr/bin/tclsh8.6 like python?
>
> would it be possible to drop 8.4 first?
>
>> 1. Multiarchifying Tcl/Tk. This means splitting out the libtcl8.5
>> package with libraries moved to /usr/lib/ and with common Tcl
>> code in /usr/share/tcltk/tcl8.5. The same is for Tk (libtk8.5 is the
>> new package name). This change doesn't cause any impact on the reverse
>> dependent packages.
>
> Is this just the shared library, or -dev and -dbg packages as well?  Will it 
> be
> possible to cross-build Tcl/Tk extensions?
>
>> Also, current stable upstream Tcl/Tk version is 8.6.1, but I wouldn't
>> like to switch to it now because it'll complicate the process of
>> removing alternatives a lot. But later I'd like to have another
>> transition (switching to 8.6 as default Tcl/Tk version).
>
> Do you have numbers what will break with 8.6?
>
>   Matthias
>
>
> --
> 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/5242af5b.4080...@debian.org
>



-- 
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/CAKcpw6X=+0Af6Bei1GrfSsGatzvHYUeJs6YzMYtm=afs4vv...@mail.gmail.com

Re: link with -L/usr/lib

[YunQiang Su]

On Tue, Sep 17, 2013 at 7:23 PM, Samuel Thibault  wrote:
> YunQiang Su, le Tue 17 Sep 2013 19:06:54 +0800, a écrit :
>> I am shutdowning the wrong bugs.
>
> You mean only the wrong bugs, not completely all of them?  If your
> program had troubles submitting the right ones, I'm afraid it will have
> troubles closing the wrong ones.  Just close all of them and submit your
> program here with rationale before starting it.
There is about 200 true bugs report, while another about 300 is invaild

>
> Also, I'm really unconvinced -L/usr/lib does really bring any problem
> anyway, see what I wrote:
Yes, we can talk about it here.

Say sorry again.
>
> On Tue, Sep 17, 2013 at 7:05 PM, Samuel Thibault  wrote:
>> > which will make it ftbfs if there is libraries under /usr/lib,
>> > while is not the default architecture, mips* for example.
>> >
>> > On mips* systems, /usr/lib is defined as place to hold O32
>> > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
>>
>> That's not necessarily a problem: a spurious -L/usr/lib does not hurt,
>> the linker will simply not take the binaries.  It's only if -L/usr/lib
>> is required for proper linking that it would be a problem.  But the
>> compiler already has that in its search path, so there is really no
>> problem.
>>
>> > Beside the way, on the multiarch system like Debian, user may install
>> > libraries under /usr/lib by hand.
>>
>> No, they are not supposed to be doing that.
>
> Samuel



-- 
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/CAKcpw6X6-8WazWV1XxG_zogwX71Fv4KZCRfXYNoA5b=rzbv...@mail.gmail.com

Re: link with -L/usr/lib

[YunQiang Su]

sorry for huge mistake bugs report.

My program met some problem. I am shutdowning the wrong bugs.

On Tue, Sep 17, 2013 at 7:05 PM, Samuel Thibault  wrote:
> Let's discuss this on debian-devel. Here is what I answered to bug
> 723358 about hwloc.
>
> Samuel Thibault, le Tue 17 Sep 2013 13:01:32 +0200, a écrit :
>> YunQiang Su, le Tue 17 Sep 2013 18:38:26 +0800, a écrit :
>> > This package has one or more -L/usr/lib in its build system,
>>
>> Err, no, it doesn't.  Please recheck your build log carefully.  And
>> don't do Mass Bug Filling without extra care, which includes discussing
>> about it on debian-devel first!
>>
>> > which will make it ftbfs if there is libraries under /usr/lib,
>> > while is not the default architecture, mips* for example.
>> >
>> > On mips* systems, /usr/lib is defined as place to hold O32
>> > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
>>
>> That's not necessarily a problem: a spurious -L/usr/lib does not hurt,
>> the linker will simply not take the binaries.  It's only if -L/usr/lib
>> is required for proper linking that it would be a problem.  But the
>> compiler already has that in its search path, so there is really no
>> problem.
>>
>> > Beside the way, on the multiarch system like Debian, user may install
>> > libraries under /usr/lib by hand.
>>
>> No, they are not supposed to be doing that.
>>
>> > The attachement is the buildlog of this package on mips64el platform.
>>
>> The build didn't even start...
>
> Samuel



-- 
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/cakcpw6xvyjuh5qb6wfggum1h6ft-eqmbebjhqflf-upoyqw...@mail.gmail.com

Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)

[YunQiang Su]

you always need to build for one arch and test, then why not upload it?


On Thu, Nov 22, 2012 at 4:33 PM, Andrey Rahmatullin  wrote:

> On Wed, Nov 21, 2012 at 09:21:19PM +0100, Didier Raboud wrote:
> > What is yet unclear is if we want to build all (as in arch:any+all) or
> all (as
> > in arch:any) packages on buildds.
> Are there any reasons to not built arch:all on buildds aside from
> technical problems?
>
> --
> WBR, wRAR
>



-- 
YunQiang Su

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

[YunQiang Su]

On Mon, Jun 25, 2012 at 5:50 PM, Bernd Zeimetz  wrote:
> On 06/25/2012 09:49 AM, Simon McVittie wrote:
>> 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 unstable users.
I am talking about after freeze.
>
> Also it avoids that you have to go trough testing-proposed-updates for
> fixes in wheezy - you upload to unstable, test there and if it works as
> expected you ask the release team for a freeze exception to fix the
> issues in wheezy.
Some guys may prefer unstable as an roll distribution.
>
> --
>  Bernd Zeimetz                            Debian GNU/Linux Developer
>  http://bzed.de                                http://www.debian.org
>  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
>
>
> --
> 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/4fe83470.3030...@bzed.de
>



-- 
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/CAKcpw6UL-r2GybiD98qZ3vAVX3xx1BLS9wt98AgCFRU=2p8...@mail.gmail.com

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

[YunQiang Su]

I am confused that where to upload packages after testing freeze.

Give a package foobar, version 1.0 is planned to be included in the
next release.
And now, the version 2.0 released, I want make it available in Debian,
in either unstable or experimental.

Now  I have several choice:
1. upload 2.0 to experimental, and unstable users should install it manually.
2. upload 2.0 to unstable, and unstable users can install it directly, while
if 1.0.1 released and fixes an important bug, I have to upload it
testing-proposed-updates,
and it seems that we treated testing-proposed-updates the same as testing.
testing-proposed-updates has no several days to testing

And I am also confused by the connection of proposed-updates and updates.


-- 
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/cakcpw6xgn-8n6eekmwpaf5fezbkv5odcummftuu9dbqfphh...@mail.gmail.com

Re: On init in *Debian*

[YunQiang Su]

It' said that the 2 main advantage of systemd are parallel and
much simpler configuration file.

Is it possible to implement an init system for kFreeBSD and Hurd,
which init system support the configuration file format, while doesn't
support parallel.

Then for maintainer of packages with service, she/he can maintain only
one configuration file, and it works on both kFreeBSD/Hurd and Linux.

On Wed, Mar 21, 2012 at 10:54 PM, Josselin Mouette  wrote:
> Le mercredi 21 mars 2012 à 13:39 +, Ian Jackson a écrit :
>> Marco d'Itri writes ("Re: On init in *Debian*"):
>> > On Mar 21, Thomas Hood  wrote:
>> > > The proposal to drop support for kernels other than Linux has already
>> > > been adequately aired.  For the sake of focus I'd like to make the
>> > > assumption in this thread that support for alternative kernels and
>> > > architectures will not be dropped on account of the choice of init
>> > > system alternative.
>> >
>> > I do not believe this to be a reasonable assumption.
>>
>> Yes, we know, but as Thomas says, that view has already been
>> adequately aired.  You don't need to post every time to contradict
>> it.
>
> Just because a few vocal people disagree with it, doesn’t mean there is
> consensus against it.
>
> Anyway, the point of these discussions is not to hang kFreeBSD
> developers or to throw stones at Hurd. The point is to choose a good
> init system for Linux. And if other kernels can’t deal with it, so be
> it.
>
> --
>  .''`.      Josselin Mouette
> : :' :
> `. `'  “If you behave this way because you are blackmailed by someone,
>  `-    […] I will see what I can do for you.”  -- Jörg Schilling
>
>
> --
> 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/1332341680.2806.4.camel@tomoe
>



-- 
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/cakcpw6xtqnf+k+_ybk9mw53cnnuvoopdjo6vcgketaj2q01...@mail.gmail.com

Re: A few observations about systemd

[YunQiang Su]

Is it possible to implement the linux-only feathers that systemd needs?

On Sun, Mar 4, 2012 at 6:20 PM, David Weinehall  wrote:
> On Sun, Feb 26, 2012 at 09:00:07PM +0100, Svante Signell wrote:
> [snip]
>> The main question is: For who's interest should Debian exist, the
>> upstream authors, the Debian maintainers or the users? My vote is on the
>> latter :)
>
> I think few argue against Debian being for the users.  But the question
> is, what does our users really want?  I honestly never heard the huge
> outcry from users demanding us to port Debian to the FreeBSD kernel.
> I'm fairly certain this started out as a project that some of our
> developers thought would be interesting.
>
> Likewise I've never noticed any demand for a Hurd port (and in fact I
> suspect that even when the Hurd port finally reaches a reasonable state
> of completion the userbase will be limited to people running it for the
> novelty factor rather than because it actually provides any real
> benefit).
>
> That said I haven't heard any outcry from users for systemd or upstart
> either.
>
> Point being is that sometimes we as developers need to try to make a
> judgment on what would serve our users the most.  What we do know is
> that we have a huge userbase of Linux users.
>
> I think most people also realise that sysvinit is beginning to really
> show signs of aging (or rather, that the world around it has developed
> to a point where it no longer can keep up).  systemd and upstart both
> aim to solve a lot of these issues, and also at least in systemd's case,
> but I guess this also goes for upstart, to add additional value that
> hasn't even been an option with sysvinit (socket activation being one
> thing).
>
>
> Regards, David Weinehall
> --
>  /) David Weinehall  /) Rime on my window           (\
> //  ~   //  Diamond-white roses of fire //
> \)  http://www.acc.umu.se/~tao/    (/   Beautiful hoar-frost       (/
>
>
> --
> 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/20120304102042.ge17...@suiko.acc.umu.se
>



-- 
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/CAKcpw6Ug5h6SPrdD6_mBqq3xMLhe9a=tiWwEmK1=7s1+5pd...@mail.gmail.com

Re: A few observations about systemd

[YunQiang Su]

On Mon, Feb 27, 2012 at 4:00 AM, Svante Signell
 wrote:
> On Sun, 2012-02-26 at 21:03 +0200, Uoti Urpala wrote:
>> On Sun, 2012-02-26 at 17:36 +0100, Goswin von Brederlow wrote:
>> > Uoti Urpala  writes:
>
>> I don't think it's an accident that this discussion came up in
>> the context of kFreeBSD. Extra hardware architectures typically require
>> a lot less effort than extra software platforms. I think it is quite
>> realistic to support extra hardware architectures without adding undue
>> burden on people not using them. It's a lot less realistic or reasonable
>> in the kFreeBSD case.
>
> Of course supporting additional hardware architectures under Linux is
> simpler than supporting other software platforms. However, the main issue 
> is:w hy
> does Debian exist and who is Debian aiming their releases for. This is
> definitely a policy decision to make.
>
>> > > It's definitely arrogant for users of other operating systems to try to
>> > > obstruct people from using better technology on Linux. It's not like
>> > > there would be anything equaling the quality of systemd that would run
>> > > on BSD. It's not your place to say that people shouldn't get to use it
>> > > on Linux, or that Linux users should have to work on BSD support to be
>> > > allowed to use it now.
>> >
>> > It is equaly arrogant to say that people must use it on Linux and screw
>> > BSD users.
>>
>> You see no difference between "group A chooses to use what's good for
>> group A" and "small group B tells group A that they must use what B
>> prefers"?
>
> Of course group A can choose what's good for group A. But there are
> consequences of doing that for Debian as a whole. And what are your
> alternatives for group A, systemd and upstart seems to be equally
> screwed, and not providing much improvement compared to sysvinit. For
> example, where is your rescue shell if something goes wrong?
>
>> There's no obligation for Linux users to keep supporting BSD, any more
>> than there's an obligation to support Linux kernel version 1, MSWindows
>> or OS/2. Yes, there are still users asking for OS/2 support too.
>
> The main question is: For who's interest should Debian exist, the
> upstream authors, the Debian maintainers or the users? My vote is on the
> latter :)
>
The really question is that for which group of users?

>
>
> --
> 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/1330286407.18649.100.ca...@hp.my.own.domain
>



-- 
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/cakcpw6xzfoqqzatixqdhemdwmghrkjgunppkn5hdo_jbjwy...@mail.gmail.com

Re: Bug#655232: ITP: pushkey -- ITP: pushkey - Pushes your ssh key to a remote location. It tries to create a .ssh folder remotley then it adds your ssh key to authorized_keys.

[YunQiang Su]

On Tue, Jan 10, 2012 at 12:04 AM, James McCoy  wrote:

>
> On Jan 9, 2012 10:03 AM, "Al Biheiri"  wrote:
> > * Package name: pushkey
> >  Version : 1.0
> >  Upstream Author : Al Biheiri 
> > * URL : http://dl.dropbox.com/u/77428/website-dev/index.htm
> > * License : (GPL v3)
> >  Programming Lang: (bash)
> >  Description : Pushes your ssh key to a remote location. It tries to
> > create a .ssh folder remotely then it adds your ssh key to
> authorized_keys.
>
> Why not use the ssh-copy-id command that comes in the openssh-client
> package?
>
+1


-- 
YunQiang Su

Bug#642319: ITP: fcitx-handwrite -- an GTK+ frontend, zinnia based handwrite input method for fcitx

[YunQiang Su]

Package: wnpp
Severity:   wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: fcitx-handwrite
Version: 0.1.1
Upstream Author : chenfc2...@gmail.com, wen...@gmail.com, dream.liuguobiao
URL: http://code.google.com/p/fcitx-handwriting/
License: GPLv3
Programming Lang: c
Description: an GTK+ frontend, zinnia based handwrite input method for fcitx

-- 
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/CAKcpw6W30+4q7QUuF2MnPEwsJ_WwEtHHaKf-pBL=h78hb4b...@mail.gmail.com

Re: Bug#641699: ITP: gnome-globalmenu -- global menu plug-in for gnome-shell

[YunQiang Su]

The mentors.debian.net seem break, that I can not upload it today.
Who can sponsor it?

Many thanks.

Know problem: make top of Chrominum to the middle of screen.

I upload them here : http://people.ubuntu.com/~wzssyqa/gnome-globalmenu/

the dsc file is :
http://people.ubuntu.com/~wzssyqa/gnome-globalmenu/gnome-globalmenu_0.9~gitba924c3d97-1.dsc


-- 
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/cakcpw6vm4g66tr3n3cizaskxr8futk2ezewebfctarmljgk...@mail.gmail.com

Bug#641699: ITP: gnome-globalmenu -- global menu plug-in for gnome-shell

[YunQiang Su]

Package: wnpp
Severity:       wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: gnome-globalmenu
Version: 0.9~alpha5
Upstream Author : Yu Feng 
URL: http://code.google.com/p/gnome2-globalmenu
License: GPLv2
Programming Lang: vala, c
Description: global menu plug-in for gnome-shell

-- 
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/cakcpw6xf1l97sq4dwm3a-kkhzco1cc2fyw6l_jrybbsyb9h...@mail.gmail.com

Re: Bug#601596: RFH: festival -- General multi-lingual speech synthesis system

[YunQiang Su]

On Mon, Aug 15, 2011 at 11:03 AM, Kumar Appaiah
 wrote:
> On Mon, Aug 15, 2011 at 09:33:50AM +0800, YunQiang Su wrote:
>> Would you found a TTS team?
>> and invite all TTS packager to join it?
>
> This would be the ideal solution. I'd love it for people interested to
> come forward in this effort.
>
done ?

-- 
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/cakcpw6uf9dmdffsgkk3ftk0jdu_slkgbwmwllachgbwl+lt...@mail.gmail.com

Bug#640970: ITP: ibus-googlepinyin -- googlepinyin engine for ibus

[YunQiang Su]

Package: wnpp
Severity:   wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: ibus-googlepinyin
Version: 0.1.1
Upstream Author : Jiahua Huang 
URL: http://code.google.com/p/libgooglepinyin/
License: GPLv2+
Programming Lang: python
Description: googlepinyin engine for ibus


-- 
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/cakcpw6ul0ekmhjvsfuaenvohjphlck-utl+xed1jpfre1u0...@mail.gmail.com

Re: A short question about apt-get build-dep

[YunQiang Su]

> Does changing the order prefer openjade before openjade1.3? Or would
> adding openjade1.3 [!hurd-i386] be a better solution.
>
I believe that changing the order is better.

-- 
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/CAKcpw6XCuzQqMAmrUD3r4JyXK=82m13tmz1nf-4hyd_ocok...@mail.gmail.com

Re: Bug#601596: RFH: festival -- General multi-lingual speech synthesis system

[YunQiang Su]

Would you found a TTS team?
and invite all TTS packager to join it?

-- 
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/CAKcpw6XUKSML+O-2a1Q+m1DoaLivBMY=jsmev8ittv716aw...@mail.gmail.com

Re: [kfreebsd] massive report for uninstallable FUSE packages

[YunQiang Su]

Is it the job for fuse4bsd maintainers to set Provide: fuse-utils ?

-- 
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/cakcpw6u8rj-9mqn1t9r-+1znhrbuo91tssj6y9enovtusog...@mail.gmail.com

Re: [Soc-coordination] ESA Summer of Code in Space 2011

[YunQiang Su]

I am interesting in to package Opticks - a remote sense software.
or Maybe i18n even, if time is enough.


Will we (Debian) apply as a mentor organization ?


PS: add cc to debian-...@lists.debian.org


-- 
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/4e15d5ea.9040...@gmail.com

Re: [Soc-coordination] ESA Summer of Code in Space 2011

[YunQiang Su]

Maybe, some Remote Sense software are related with it. These RS
software are maintained by DebianGIS team.


-- 
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/CAKcpw6XVxajhqo6uiZewKRVxgg46fpFvTNrGR=ito=dt98o...@mail.gmail.com

Re: Whether should grub2 write MBR automatic

[YunQiang Su]

>
> I suspect you should have grub installed in a single distro only,
> e.g., only Debian, or only Ubuntu. Since there's only one MBR, thre's
> only one bootloader, you don't need to have it in every distro.
>
>
Yes, if only for Linux distro, it can be done like this.
Then if there are Windows and Mac OS X?

It's my fault that didn't notice that it can be done by
`dpkg-reconfigure grub-pc'

But I believe that debconf is not a good idea for grub.
We can just install some files and if need, call grub-install by
Debian-Installer or LiveCD-installer or users manually.

It is both friendly to users and maintainers.
-- 
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/BANLkTinTkZHkGUtGdcykgCn1cX=_D=x...@mail.gmail.com

Re: Re: Whether should grub2 write MBR automatic

[YunQiang Su]

> What if the updated grub is incompatible with the bootloader installed by a
> previous version of grub?
>

If so, it should not be called grub2 again.

-- 
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/BANLkTik=a1nzof7hppdsy58dxe4ofi9...@mail.gmail.com

Re: Whether should grub2 write MBR automatic

[YunQiang Su]

> Did you? Try 'dpkg-reconfigure grub-pc' ;)
> 
yes it works. BUT:

When installing, user will usually install grub in MBR or they have no
choice to set it when install (install from LiveCD).

and I can not find out any necessity to run grub-install every time.


-- 
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/4e0194cd.9070...@gmail.com

Re: Whether should grub2 write MBR automatic

[YunQiang Su]

> Maybe what needs to be fixed is grub not writing to your “alternative
> place”?
>

now I installed one Debian Sid/Experimental and an Ubuntu 11.10.
I perfer Debian to take control my MBR.

But once upgrade Ubuntu, the MBR is taken place, and once then upgrade
Debian, it's back.

I hate this behavior.

I believe that the MBR must be taken control by users.

-- 
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/banlktimsujmsbv+yg1_6k__mulvogk3...@mail.gmail.com

Re: Whether should grub2 write MBR automatic

[YunQiang Su]

> On Wed, 2011-06-22 at 11:33 +0800, YunQiang Su wrote:
>> When update to grub-pc 1.99-8, it write my MBR, then I report a bug.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631224
>>
>> and Colin Watson  tell me that it's a new feature.
>> Y, it maybe, he tell to install grub-pc-bin only, but this package has
>> no kernel hook even.
>>
>> Here is my suggestion:
>> make 3 packages:
>> one calls upgrade-grub and grub-install;
>> one calls only upgrade-grub.
>> one calls nothing.
>> and, the second one should be the default.
> 
> More packages means more user confusion.  And the first behaviour is
> definitely the correct default, as installing a boot loader package
> almost always means you want to install the boot loader in the boot
> sector.
> 
> What is your use case for the second behaviour?
> 
The second behavior means that: when update/reinstall grub or
update/install/reinstall kernel will call update-grub but not call
grub-install.
>> Don't do it like M$.
>  
> Oh, grow up.
> 
Even M$ will not write MBR when update software.
We do much worse than any other OS.


-- 
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/4e018758.7060...@gmail.com

Whether should grub2 write MBR automatic

[YunQiang Su]

When update to grub-pc 1.99-8, it write my MBR, then I report a bug.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631224

and Colin Watson  tell me that it's a new feature.
Y, it maybe, he tell to install grub-pc-bin only, but this package has
no kernel hook even.

Here is my suggestion:
make 3 packages:
one calls upgrade-grub and grub-install;
one calls only upgrade-grub.
one calls nothing.
and, the second one should be the default.

Don't do it like M$.



signature.asc
Description: OpenPGP digital signature

When create base.tgz with pbuilder , occured a error

[YunQiang Su]

I am using unstable/experimental, and when

pbuilder create

When it nearly success, an error occoured :

I: mounting /proc filesystem
mount: /proc already mounted or /media/tmpfs/pbuilder/4079/proc busy
mount: according to mtab, /proc is mounted on /proc
W: Aborting with an error
I: cleaning the build env
I: removing directory /media/tmpfs/pbuilder/4079 and its subdirectories
rmdir: failed to remove `/media/tmpfs/pbuilder/4079/proc': Device or
resource busy
rmdir: failed to remove `/media/tmpfs/pbuilder/4079': Directory not empty

And the base.tgz buil

-- 
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/banlktikg9hm8wtcf7r6qdsjx4tg0bst...@mail.gmail.com

When create base.tgz with pbuilder , occured a error

[YunQiang Su]

I am using unstable/experimental, and when

pbuilder create

When it nearly success, an error occoured :

I: mounting /proc filesystem
mount: /proc already mounted or /media/tmpfs/pbuilder/4079/proc busy
mount: according to mtab, /proc is mounted on /proc
W: Aborting with an error
I: cleaning the build env
I: removing directory /media/tmpfs/pbuilder/4079 and its subdirectories
rmdir: failed to remove `/media/tmpfs/pbuilder/4079/proc': Device or
resource busy
rmdir: failed to remove `/media/tmpfs/pbuilder/4079': Directory not empty

And the base.tgz create before, works well.

-- 
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/BANLkTimSEgTXW5GsOm8VFr8h+QPPjLj4=q...@mail.gmail.com

Bug#622968: ITP: libcitygml -- a small and easy to use C++ library for parsing CityGML files

[YunQiang Su]

Package: wnpp
Severity: wishlist
Owner: YunQiang Su 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: libcitygml
  Version : 0.1.4
  Upstream Author : jpouder...@gmail.com
* URL : http://code.google.com/p/libcitygml/
* License : LGPL
  Programming Lang: C++
  Description : a small and easy to use C++ library for parsing CityGML 
files

CityGML (City Geography Markup Language) is an XML-based schema for the 
modelling and exchange of georeferenced 3D city and landscape models that is 
quickly being adopted on an international level.

libcitygml is a small and easy to use open source C++ library for parsing 
CityGML files in such a way that data can be easily exploited by 3D rendering 
applications (geometry data are tesselated and optimized for rendering during 
parsing). For instance, it can be used to develop readers of CityGML files in 
many 3D based applications (OpenGL, OpenSceneGraph, ...) Most metadata are not 
lost, they are available through a per-node hashmap.

libcitygml is developed by the 3D team of BRGM (the French leading public 
institution involved in the Earth Science field for the sustainable management 
of natural resources and surface and subsurface risks) for the research project 
DeepCity3D.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJNqV/OAAoJEGqO9vovZQkSBXcIALP7SMW2+EbaulqkYe2FYzdS
GsMRBaGInxw+DBkcCfArNdBj9W1NR06DXjaMquS6Hm+BSVt9x7StS8Lzq2cRLIZG
GEDMVzuolde6TRWCNmrNQcHiHFa6VrQnBoLAGHDKLZh/0GqHf0gzPWHDunFyED4o
my+0LQO9Uo7AswoVe1rFZ5/TB+6vs7mQo72wrs0t/oUMSCs6j0z8sQxTXj2YQr7r
SrDTprkTsCxuMg1K5GdpC1l3kF4EanVCN7X0efIGtmwHcjWvJBlJhjOwTV0mbYwg
MF5oHZg4hnT+rzOE6gutBhdI6onczFiTMI/uW3p0xc5uGzF9G/LhlZcJ9ahGAL8=
=Nu6x
-END PGP SIGNATURE-



-- 
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/2011041609.15501.93095.reportbug@localhost6

Bug#605985: ITP: gitso -- a frontend to reverse VNC connections

[YunQiang Su]

Package: wnpp
Severity: wishlist
Owner: YunQiang Su 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: gitso
  Version : 0.8
  Upstream Author : gerberad etc.
* URL : http://code.google.com/p/gitso/
* License : GPLv3
  Programming Lang: Python
  Description : a frontend to reverse VNC connections

 Gitso is meant to be a simple two-step process that connects one person to
 another's screen. First, the support person offers to give support. Second, 
 the person who needs help connects and has their screen remotely visible. 
 .
 Because Gitso is cross-platform (Linux, OS X and Windows) and uses a reverse 
 VNC connection, it greatly simplifies the process of getting support. 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJM+2ywAAoJEGqO9vovZQkS/QUH/jY/h4ZTPf0skcTKP7IexluD
TM930yQMK8V/UJKyynPZtwKsn9JZ3YsYxwFKX9Pm4WU7UxvHYyeJhoWRpXpZZYWY
AxjJ2kbf1JZW3G95zyuD02Ww8c/QhEAYpdLns01GDSXUlyUQM428Ft5q794o2DzB
hSZpC39D71Q+F8DDybyAyLunTEypPR4GvmIPnQX3oTbnplY+z7mgr2Ru6KtW8wJz
zVHx9VDttm4DPj3bGZH1hpxWIBlusjFNjlpUZ+BCbaWlfZNn2sc7fKzFjW6VMVd8
5WQVgF0qiAo1CSc3JMWk8iBHBQ69+Nx2qO5bc77M+32+rrfhjgsGSKBcxTJUZrc=
=N3CB
-END PGP SIGNATURE-



-- 
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/20101205104302.3310.80936.report...@localhost6

Bug#604460: ITP: ibus-handwrite -- handwrite input engine for ibus

[YunQiang Su]

Package: wnpp
Severity: wishlist
Owner: YunQiang Su 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: ibus-handwrite
  Version : 2.1.0
  Upstream Author : Cai WanZhao
* URL : http://code.google.com/p/ibus-handwrite
* License : GPLv3
  Programming Lang: C
  Description : handwrite input engine for ibus

 Ibus-handwrite is a handwrite input engine for ibus.
 It supports Chinese and can support Japanese by libzinnia.
 .
 Initially written for my father. But re-write for the whole world.
   --microcai

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJM6lG3AAoJEGqO9vovZQkS7l4H/1NLFj4UMObgsc6qb1KOcbqI
Op7jPsF4oy4a8ie6Aa42bAV1CdeC+yQIzYX+uyNq2QmjFXh6bhrlcAqmtjbqR0Zm
o2qyqmR6QDZT0Pb448DtcUlcfscL/RgpyMR6f1Po6YaJ94nL97k/Gl/wyjAKEsA+
N4kCfZhNk3kcv0O8cZl6/86+G/QHUJ6TusFo0F2mQKIuExnF4mjlxQ4Bu46JqQai
f8p1xjsjOakXHacaMRGnNZpzzFW4ecFgNx4N3SqIMB/mlOAnWUiWs3GGtYvCSAyh
NPxIv91GvtMGdcClndxACIef72XGi7hvp/ZxtIsRrovDt7Q0de7CTIMMEy5xt7c=
=/xqa
-END PGP SIGNATURE-



-- 
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/20101122111925.15103.608.report...@localhost6.localdomain6