Re: Re: Port to LoongArch architecture for Debian

[Aron Xu]

On Fri, Nov 4, 2022 at 1:58 PM 张丹丹  wrote:
>
> Hi,pabs
>Nice to receive your reply.
> ,this document you have initiated and 
> contributed which gives us a lot of guidance.
>
> The result of the discussion on debian-dpkg is that dpkg architecture is 
> loong64,likely,
> aarch64 → arm64, x86_64 → amd64
> loongarch64 → loong64，loongarch32 → loong32
> Detailed info has archived in 
> https://lists.debian.org/debian-dpkg/2022/11/msg1.html.
>
> Dpkg architecture of loong64 just determine the name of the software packages.
> About the channel of IRC,we agree with the #debian-loongarch64 even more.
>

I would suggest you to consider using #debian-loongarch if your
management prefer to keep the whole "loongarch" keyword, rather than
accompanied with a detailed 32 or 64 suffix.

Also I'd like to mention that Debian mailing lists prefer plain text
over HTML, and your company email signature declaring it contains
confidential information is not supposed to exist on a mailing list
that its content is intended to be public available.

Regards,
Aron

Re: membership revoked?

[Aron Xu]

On Wed, Sep 14, 2022 at 4:05 PM Brian Smith
 wrote:
>
> Hi,
>
> I don't see my name "Brian Smith" listed at https://nm.debian.org/members/. 
> However, I do see my profile at https://nm.debian.org/person/bsmith/. Did I 
> get kicked?
>

It appears that the first page only lists official Debian Developers,
and your status is Debian Maintainer currently.

Cheers,
Aron

Re: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Aron Xu]

Hi,

On Sat, Jun 18, 2022 at 12:43 AM Lance Lin  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Lance Lin 
> X-Debbugs-Cc: debian-devel@lists.debian.org, lqi...@protonmail.com
>
> * Package name: libBabaSSL
>   Version : 8.3.1
>   Upstream Author : Copyright (c) 2020-2022 Alibaba Digital Economy
> * URL : https://github.com/BabaSSL/BabaSSL
> * License : Apache 2.0
>   Programming Lang: C
>   Description : BabaSSL is a base library for modern cryptography and 
> communication security protocols.
>
> - BabaSSL is a modern cryptographic and secure protocol library developed by 
> the amazing people in Alibaba Digital Economy.
> - BabaSSL provides the following major features:
> -Support RFC 8998, Chinese SM cipher suites in TLS 1.3 protocol
> -Support NTLS (formal GM dual-certificate protocol) handshake processing, 
> according to GB/T 38636-2020 TLCP
> -QUIC API support
> -Support delegated credentials, according to draft-ietf-tls-subcerts-10
>
> I plan to package and maintain BabaSSL myself.
>

AFAIK this library is forked from OpenSSL with some extensive
modifications to support new crypto technologies, do you think we need
to involve the Security Team to review whether this package can be
supported during the next stable release cycle?

Also this project has a planned rename, and I'm a bit concerned this
could cause some maintenance burden if the rename is not well
coordinated at the time we accept it into Debian.

Regards,
Aron

Bug#989900: ITP: dnf-plugins-core -- Core plugins for DNF, the Dandified Yum package manager

[Aron Xu]

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


* Package name: dnf-plugins-core
  Version : 4.0.21
  Upstream Author : DNF-PLUGINS-CORE authors and contributors
* URL : https://github.com/rpm-software-management
* License : GPL-2+
  Programming Lang: Python
  Description :
This package enhances DNF with builddep, config-manager, copr, debug,
debuginfo-install, download, needs-restarting, groups-manager, repoclosure,
repograph, repomanage, reposync, changelog and repodiff commands.
.
Additionally provides generate_completion_cache passive plugin.

Note, the initial purpose of packaging these dnf plugins are not meant
to make dnf more useful to install RPM packages on Debian, but rather
it enables the downloading and mirroring of Yum repositories on Debian
based systems.

Re: Be nice to your fellow Debian colleagues

[Aron Xu]

On Sun, Dec 29, 2019 at 5:00 AM Ondřej Surý  wrote:
>
> Hi,
>
> the init systemd GR is over and we have reached the results in a democratic 
> way by following Debian Constitution. However following the process is 
> orthogonal to our opinions, positions we took, and our feelings. Now, more 
> than ever, it’s important to be nice to each other, have a lot of compassion 
> and not be condescending, whatever group you belong to.
>
> So, I am sending hugs to all my fellow Debian colleagues no matter whether 
> the are pro-systemd, anti-systemd, anything in between, or something 
> completely different. Happy new year to all of you and the Debian project as 
> whole.
>

Thank you for saying so.

Some moments I felt quite heart broken to see Debian is at some level
of risk that the project rarely faced before. We might hold different
opinions, techinical or perceptional, such diversity is a strength of
our community and we could to cherish it by being nice to our fellow
people.

Best regards,
Aron

Re: Q: what's the blocker for firefox-esr update migrates to testing

[Aron Xu]

On Fri, Nov 1, 2019 at 1:59 AM Carsten Schoenert
 wrote:
>
> Am 31.10.19 um 16:28 schrieb Aron Xu:
> > This could be a reminder that we should start thinking about whether
> > we want to keep armel as a release architecture for bullseye.
>
> No, but some X-based applications might simply get excluded from the
> that architecture. There are still a lot armv5 based hardware outside
> which is simply working fine with recent Debian releases. I see no real
> reason to make all this hardware obsolete simply because some software
> which requires some X features isn't build-able on armel.
>

I'm not implying to remove it altogether, but it could be moved it to
debian-ports, even RPi4 is alreay aarch64 capable.

Cheers,
Aron

-- 
Regards,
Aron Xu

Re: Q: what's the blocker for firefox-esr update migrates to testing

[Aron Xu]

On Thu, Oct 31, 2019 at 11:09 PM Boyuan Yang  wrote:
>
> According to https://qa.debian.org/excuses.php?package=firefox-esr , firefox-
> esr build-depends on nodejs, which is not available on armel anymore
> (explicitly not built on armel). Since armel is an release architecture,
> firefox-esr won't migrate to Testing when its armel build is missing.
>

This could be a reminder that we should start thinking about whether
we want to keep armel as a release architecture for bullseye.

Cheers,
Aron

Re: salsa.debian.org partially down

[Aron Xu]

On Thu, Aug 15, 2019 at 6:23 PM Thomas Goirand  wrote:
> [...]
> 1/ CI Jobs going faster
> 2/ Have a way more workers
> 3/ Don't have all our eggs on the same Google basket
> 4/ Use free software platforms instead of GCE
> 5/ Stop being bound to a single VM provider [1]
>

Would it be more attractive to use dedicated hardware for such a long
running, resource hungry service? We already have quite some servers
running at our hosting partners' places, adding a few more won't be a
hugh problem. Doing so will make the service a lot more reliable and
flexible in the long run, even we can have its own Openstack
installation if the team really like it.

Regards,
Aron

Re: default firewall utility changes for Debian 11 bullseye

[Aron Xu]

On Wed, Jul 31, 2019 at 11:10 PM Marco d'Itri  wrote:
>
> On Jul 31, Aron Xu  wrote:
>
> > utility (for instance, firewalld) for certain use cases, i.e. it could
> > be useful for a "standard" server installation with graphic desktop,
> > for which we could expect most users choosing this method would like
> > to have advanced firewalling as an enterprise feature to have
> > out-of-box.
> Can you explain better which problems this would solve?
>

If there is no pre-installed firewall application in a standard/full
installation (which does not exist for us theoretically), Debian could
be easily marked as missing feature in some enterprise IT evalutation,
even having them installed on disk without defining any rules would
help out most of the cases. I understand this sounds very awkward
because users can always install one if they really need or want it,
but it's quite offen that fixed rules (which are usually seen awkward)
would apply in companies no matter of its size and IT management
level.

Regards,
Aron

Re: default firewall utility changes for Debian 11 bullseye

[Aron Xu]

On Wed, Jul 31, 2019 at 12:27 PM Scott Kitterman  wrote:
>
> Please don't install one by default.  I suspect it will cause more trouble 
> for end users than it's worth.  Making sure our default install is severely 
> limited in what ports it listens to is likely more broadly useful and less 
> risky.
>

I agree, we should mitigate risks by keeping open ports as restricted
as possible by default. But it could be useful for higher level
tasksel tasks or meta packages to pull in a firewall configuration
utility (for instance, firewalld) for certain use cases, i.e. it could
be useful for a "standard" server installation with graphic desktop,
for which we could expect most users choosing this method would like
to have advanced firewalling as an enterprise feature to have
out-of-box.

Cheers,
Aron

P.S. I know there is no such a thing called "standard" installation in
Debian, but only referring the name for the sense of RHEL's default
installation entries.

Re: Challenge from Julia's non-standard vendored openblas"64_"

[Aron Xu]

On Mon, Jul 29, 2019 at 9:35 AM Mo Zhou  wrote:
>
> Hi Marco,
>
> After the merger of (64bit-indexing) * (multi-thread flavor)
> feature enhancement, an libopenblas-julia package will
> look abrupt, and break the symmetry of package layout
> (libopenblas-julia doesn't need development files) :
>
> ~/D/o/o/debian ❯❯❯ rg \^Package control
> 19:Package: libopenblas0
> 41:Package: libopenblas0-pthread
> 64:Package: libopenblas0-openmp
> 87:Package: libopenblas0-serial
> 134:Package: libopenblas-dev
> 156:Package: libopenblas-pthread-dev
> 179:Package: libopenblas-openmp-dev
> 202:Package: libopenblas-serial-dev
> 227:Package: libopenblas64-0
> 245:Package: libopenblas64-0-pthread
> 264:Package: libopenblas64-0-openmp
> 283:Package: libopenblas64-0-serial
> 302:Package: libopenblas64-dev
> 321:Package: libopenblas64-pthread-dev
> 341:Package: libopenblas64-openmp-dev
> 361:Package: libopenblas64-serial-dev
>
> Instead, if we embed the openblas source
> to src:julia, no extra binary package is needed.
> So I prefer (3).
>
> It's not the maintenance burden that matters most
> at this point. It's simply that a maintainer doesn't
> want his/her package to look weird.
>

Then we would have two copies of openblas in the archive, which smells
it would look quite weird from FTP Team's perspective.

Regards,
Aron

Re: ZFS in Buster

[Aron Xu]

On Sat, Jun 8, 2019 at 5:33 PM Ondřej Surý  wrote:
>
>
> > On 8 Jun 2019, at 10:56, Aron Xu  wrote:
> >
> > Even further, it's distributed in
> > the form of dkms source and theoretically not in Debian (contrib) to
> > save people of Software Freedom Conservancy from being upset about
> > losing their position of Linux GPL enforcement.
>
> I don’t care much about the rest, I said what I wanted to say, but I strongly 
> disagree with this statement. It’s both untrue and very rude.
>
> We (the Debian community) care about the software freedom and associated 
> licensing because we care “the software freedom”, not to please or displease 
> some people that deeply care about the same/similar thing.
>

There's no point to be rude from me because I was on the table when
the face to face discussion happened. We care about software freedom
and we have agreed that we choose to keep SFC's position for the good
of free software ecology, so in turn we agreed to ship ZFS in contrib
(which is not an official part of Debian) for the best of our users
and community.

"Our priorities are our users and free software", and the current
status quo is what we can do to make sure both our users and free
software are not disregarded from being our priorities. I believe this
is in no way untrue.

Regards,
Aron

Re: ZFS in Buster

[Aron Xu]

On Fri, Jun 7, 2019 at 4:16 PM Philipp Kern  wrote:
>
> On 6/6/2019 8:09 PM, Aron Xu wrote:
> > Key interest in the thread is getting some insights about how to deal
> > with the awkward situation that affects ZFS experience dramatically -
> > Linux will remove those symbols in LTS kernel release, although
> > in-kernel symbols are never promised to be stable. I've been in touch
> > with ZoL upstream to listen to their plans and wishes, so that we
> > (Debian ZoL people) can take actions that serve best for our users and
> > community.
>
> I will note that in terms of prior art Debian has in the past always
> prioritized freeness over performance. Whenever there are binary blobs
> involved to improve performance, we opted not to ship them unless they
> could be reproduced using free software and have their source included.
>
> Of course in that case people were still free to install the binary
> blobs from non-free, assuming that the blob was in fact distributable.
> This would not be the case here. But crippling the performance would be
> indeed an option, even though this would make Debian much less relevant
> for ZFS deployments and people would just go and use Ubuntu instead.
>

I agree that we usually prefer free-ness and universal-ness over
performance, you know Mo Zhou in this thread is actively pushing deep
learning stuff into Debian and he is discovering a lot of way to
exploit better performance while not being too invasive to existing
culture.

Also I'd like to mention, it could be a widespread misunderstanding
that "when something is incompatible with GPL/Linux then it's likely
non-free". ZFS itself is free and open source software, I don't think
it's comparable to non-free blobs. Even further, it's distributed in
the form of dkms source and theoretically not in Debian (contrib) to
save people of Software Freedom Conservancy from being upset about
losing their position of Linux GPL enforcement.

> Still, crippling performance would still provide a lever and motivation
> for upstream to come up with a way to disable the FPU on every supported
> architecture one by one (if only on the most important one), even if
> it's brittle and hacky. I personally wonder why a kernel which provides
> a module interface does not provide a way to save FPU state, but alas,
> they made their decision.
>

It is hard to interpret why Greg KH would like to disallow access to
hardware features and I don't think I'm at the position to comment.
There is another way around at implementation side though, when a
kernel thread is going to use FPU, preempt is usually (if not always)
disabled, so it's still possible to make use of those registers
without messing up with all the kernel states. But it's still weeks to
go before being able to have an PR upstream. We are confident to have
a version of ZFS that could make use of vector instructions in several
months, but it could be hardly possible to merge back to buster stable
updates, so that we'll have to recommend people using
stretch-backports which is fine.

> In the great scheme of things doing things the slow way has forced
> certain progress to happen in the past when it was painful enough. The
> question I wonder is if we are relevant enough here to push the needle
> or if essentially all other distributions (say Ubuntu) will dare not to
> follow upstream here and carry a patch forever.
>

IIRC all major distributions have a series of downstream maintained
patches being carried for very long time, like the aufs4 patchset in
Debian kernel. But this is not the case for the FPU one because it's
not technically complex but people tend to avoid something supposed to
lead to heated discussion in some regard.

Regards,
Aron

Re: ZFS in Buster

[Aron Xu]

On Thu, Jun 6, 2019 at 11:16 PM Ondřej Surý  wrote:
>
> Hey all,
>
> I understand the woes on all sides, but I believe the correct “Debian" way 
> would be to drop ZoL from Buster release.  Of course we can wait until it 
> breaks after Linux kernel upgrade, but I would say it’s better to prevent the 
> dance around removing the package from the buster and just not release with 
> it.
>

Perhpas you have misread the thread, or have just partially get the
idea of current situation... Please be a bit more patient.

The situation here is about the kernel unexporting
__kernel_fpu_{begin,end}, which was EXPORT_SYMBOL, that will lead to a
future installation failure of zfs-linux/0.7.12-2 (testing). We
already have minimal patch to disable FPU usage when those symbols are
not available, so be relaxed because we have gatekeeper to make sure
it won't explode in stable.

Key interest in the thread is getting some insights about how to deal
with the awkward situation that affects ZFS experience dramatically -
Linux will remove those symbols in LTS kernel release, although
in-kernel symbols are never promised to be stable. I've been in touch
with ZoL upstream to listen to their plans and wishes, so that we
(Debian ZoL people) can take actions that serve best for our users and
community.

Best,
Aron

Re: ZFS in Buster

[Aron Xu]

On Wed, May 29, 2019 at 8:55 PM Ian Jackson
 wrote:
>
> Ansgar writes ("Re: ZFS in Buster"):
> > Ian Jackson writes:
> > > I think this would be both unwise legally (without seeking additional
> > > legal advice) and rather rude to the kernel upstream whose code is
> > > then being reused without permission - indeed, contrary to their
> > > explicitly stated intent.
> >
> > At least one commercial distribution (Ubuntu) has been distributing ZFS
> > binary modules as part of their Linux packages for some years and didn't
> > have any problems.
>
> That doesn't prove anything other than that no-one felt it was
> politically or financially expedient to sue.
>
> AIUI Debian's position is still that summarised here:
>   https://blog.halon.org.uk/2016/01/on-zfs-in-debian/
> (sorry about the pale grey on white disease; it works well in w3m)
>
> Are you trying to reopen that discussion ?  If so then you should be
> CCing ftpmaster@ and leader@ probably...
>

(With my Debian ZoL hat on.)

I don't know whether this is correct time to discuss about Debian's
position but it was a compromise. Having Mehdi Dogguy (DPL of the
time) and representatives of Software Freedom Conservancy on the
table, we talked about this very topic at DebConf 16 and agreed to put
ZFS into contrib for the good of our users.

ZFS is free and open source software, perfectly complies with DFSG for
main archive inclusion on its own, and we had another copy of the code
in FreeBSD kernel which is main. While putting it into contrib is a
very expressive language telling the world that Debian and, more
importantly SFC, would like to see that the licensing issue could have
a better resolution at the root. And this is exactly the compromise
that made ZFS possible to go through NEW.

Regards,
Aron

Re: allowed uses of non-baseline CPU extensions

[Aron Xu]

On Sun, Oct 22, 2017 at 5:33 PM, Adrian Bunk  wrote:
>
> There are two options availabe:
> 1. RC bug that qtwebengine-opensource-src must not be built on i386
>since it violates the baseline, all code using it has to do whatever
>mitigation is already done for the other architectures without
>qtwebengine-opensource-src
> 2. bless the SSE2 usage with a dependency on sse2-support, making
>KDE and several other Qt applications not available without SSE2
>

Option 2 is much better because explicitly supporting such old/rare
hardware at a price of hurting general use cases significantly doesn't
look meaningful to me, even if we fully understand that new x86
hardware with limited instruction set support is still being produced.
SSE2 is aged from 2001 and is very well adopted, and we are now at
2017Q4.

With packages like sse2-support maintainers have the option of
creating different flavors of their packages with modern instructions
enabled/disabled, this gives great possibility to some very common use
cases, for instance "avx-support" on amd64, which is critical to most
scientific software to run at appropriate performance. In this case we
can avoid a painful tradeoff between keeping and raising the baseline
which has zero flexibility.

Users of really old or rare hardware should be able to handle their
own case - by recompiling critical packages themselves, by producing
something like raspbian, or at least by staying on an old release if
they need something can't be supported at all (i.e. upstream removed
compatibility in current release).

Regards,
Aron

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

[Aron Xu]

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

Great stuff!

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

I think this shouldn't work (at least by default). If https->http
happens silently (not dying with an error or requiring a force
option), that would make degradation happen while users think they are
using HTTPS properly.

Regards,
Aron

Re: When should we https our mirrors?

[Aron Xu]

On Sunday, October 16, 2016, Aron Xu  wrote:

>
>
> On Sunday, October 16, 2016, Paul Wise  > wrote:
>
>> On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote:
>>
>> > Doing this for the per-country mirrors means that repointing mirrors
>> > becomes a lot harder than it currently is, and this is something we do
>> > on a daily basis.  We'd need a solution for deploying the TLS cert for,
>> > say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for
>> > maintenance.
>>
>> I never really liked the per-country mirrors being under debian.org,
>> redirectors would be a better option. I think we really need to
>> redesign the apt archive namespace for Debian.
>>
>>
>>
> Yeah but at the risk of making it broken like pypi and npm to quite
> some people including me.
>
>
To make it clear, content delivery systems used by pypi and npm don't work
for many people in China because:

1) Major global CDN providers don't have decent services in the country
(except akamai and cloudflare but need special contract);

2) BGP based network topology discovery never work because eBGP routing is
not widely deployed for subscriber network;

There's more to mention for Debian:

3) cdn.debian.net / httpredir.d.o tend to exclude local mirrors because of
the synchronization delays are much higher than in EU/US, even current
ftpX.cn.d.o would easily exceed the tolerance of redirecting software.

Best
Aron

Re: When should we https our mirrors?

[Aron Xu]

On Sunday, October 16, 2016, Paul Wise  wrote:

> On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote:
>
> > Doing this for the per-country mirrors means that repointing mirrors
> > becomes a lot harder than it currently is, and this is something we do
> > on a daily basis.  We'd need a solution for deploying the TLS cert for,
> > say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for
> > maintenance.
>
> I never really liked the per-country mirrors being under debian.org,
> redirectors would be a better option. I think we really need to
> redesign the apt archive namespace for Debian.
>
>
>
Yeah but at the risk of making it broken like pypi and npm to quite
some people including me.

 Best,
Aron


-- 
Regards,
Aron Xu

Re: When should we https our mirrors?

[Aron Xu]

On Sunday, October 16, 2016, Tollef Fog Heen  wrote:

> ]] Paul Tagliamonte
>
> > So, when are we going to push this? If not now, what criteria need to
> > be met? Why can't we https-ify the default CDN mirror today?
>
> The usual crypto answer: because key handling is hard.
>
> Doing this for the per-country mirrors means that repointing mirrors
> becomes a lot harder than it currently is, and this is something we do
> on a daily basis.  We'd need a solution for deploying the TLS cert for,
> say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for
> maintenance.
>
>
I agree key handling is difficult, but it's not that hard to work
around such scenarios when HTTP 302 can be provided from the original
maintianers (i.e. through a temporary virtual machine).

Actually we have backup plan on ftp.cn.d.o and ftp2.cn.d.o
that is battle-tested. They would redirect traffic to selected mirrors in a
way similar to httpredir.d.o when outages happen. Performance and bandwidth
requirements are acceptable for a temporary service even they are of the
busiest FOSS mirrors in China.

The two mirrors are delivering most of the traffic through HTTPS
nowadays according to statistics because we've deployed User-Agent based
HTTPS redirection on all supported domains and never heard a complain.
Overhead is negligible because IOPS of disk arrays is always the most
significant problem and bandwidth the next.


> Doing this for deb.d.o would mean we need to get certs on both Fastly
> and Cloudfront deployed, which is, frankly, a more realistic proposition
> than jury-rigging something on the per-country mirrors.
>
>
There's no reason to not do it, but it doesn't cover parts in the world
like China where neither Fastly nor Cloudfront provides a decent service.

Best,
Aron

Bug#796464: general: there is no auto crash reporting

[Aron Xu]

On Sat, Aug 22, 2015 at 6:04 AM, Richard Jasmin  wrote:
> Package: general
> Severity: important
>
> debian should implement an automatic crash detection and reporting system like
> Fedora and Ubuntu teams have.If not mistaken, Fedora uses upstream of what
> ubuntu uses --apport.
>
> There is no reason for debian to not have this feature.Yes, it is mostly a gui
> tool. Debian is used on both client workstations and servers.
>
> Tool should catch crashes as they happen and allow users to report them.It
> should auto-generate and allow people to auto generate debugging backtrace
> reports, installing gdb packages as needed.This would generate useful traces
> for developers in non-trivial way.
>
> Hint: corekeeper? ..but that is console based. Who uses a console these days?

We have a GSoC project this year working specifically on Apport for
Debian, and you might be interested to follow up on that, :)

Thanks,
Aron

[1]https://wiki.debian.org/SummerOfCode2015/Projects#SummerOfCode2015.2FProjects.2FApportForDebian.Apport_for_Debian
[2]http://blog.yurushao.info/2015/07/Debian-Apport-GSoC/
[3]http://www.researchut.com/blog/gsoc-apport-for-debian

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Aron Xu]

On Mon, Jun 15, 2015 at 5:04 PM, Thomas Goirand  wrote:
> On 06/14/2015 05:10 PM, Don Armstrong wrote:
>> On Sun, 14 Jun 2015, Thomas Goirand wrote:
>>> Therefore, I'm tempted to raise this to the technical committee
>>> (putting their list as Cc). Does anyone see a reason why I am
>>> mistaking here?
>>
>> Does a patch exist which can enable lz for orig.tar?
>
> Isn't it what this is doing?
>
> https://bugs.debian.org/600094
> https://bugs.debian.org/556960
>
>> Otherwise, I guess some of us could be involved to help clarify
>> communication, but anyone can do that, really.
>
> I'm not at a stage where I want to involve the CTTE right now. I still
> would prefer to gather opinions and see where it goes.
>

I don't hold a view on whether we want lz support in dpkg/dak, but it
could be a pity if we really involve CTTE for such an issue. To me,
it's sorta abusing the escalation process if every individual
developer raise an issue and seek for overruling when his opinion were
n'acked by the maintainer of relevant part... But this is just my own,
secret, POV, please don't start a flame war for it.

Thanks,
Aron


-- 
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/CAMr=8w58q5cvbq4nvtdeft6_igwmgc8qksskgb66+gy04yn...@mail.gmail.com

Re: Two new architectures bootstrapping in unstable - MBF coming soon

[Aron Xu]

On Wed, Aug 27, 2014 at 08:25:45PM +0100, Manuel A. Fernandez Montecelo wrote:
> 2014-08-27 02:46 Wookey:
> >Hi folks,
> >
> >We are excited to announce that in the last two weeks two new
> >architectures have been added to the archive: arm64 and ppc64el.
> >[...]
> >A lot of people are working hard to get them to a releasable state in
> >time for Jessie.
> 
> Congrats!  The sooner that you graduate out of debian-ports, the
> better for other architectures that want to get into ;-) -- although
> arm64 is still there, for some reasons.
> 
> There were efforts a while ago to try to get mips64el into the club of
> officially supported architectures also for Jessie, or at least in
> debian-ports.  I'm curious about what happened with that, does anybody
> know?
> 

We are waiting for new buildds to be ready, after that we can start off the
work of mips64el, :) 

-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140827200103.GA26203@aron-laptop

Re: Release sprint results - team changes, auto-rm and arch status

[Aron Xu]

On Wed, Dec 4, 2013 at 3:32 PM, Tollef Fog Heen  wrote:
> ]] David Kuehling
>
>> >>>>> "Aron" == Aron Xu  writes:
>>
>> > And here you are: http://item.taobao.com/item.htm?id=22206048695
>>
>> > Price is CNY 3999 right now, seems to be much cheaper than before (I
>> > remember it was about CNY6999).
>>
>> I recently ordered the Xinghuo 3A 6100 directly from lemote.com, by
>> emailing the sales people (can give you the email address I used in
>> private mail).  Payment was in advance via international bank transfer,
>> $600 plus shipment and german import tax/customs.  Machine was delivered
>> via TNT within a few days.
>>
>> It looks pretty solidly build.  Metal enclosure, pretty standard
>> mini-ITX/ATX equipment AFAICS.  Large enough to hold at least one 3.5"
>> harddisk (a 2.5" drive is preinstalled, two SATA sockets provided on
>> board).  Has another case fan mounted above the hard-drive, so shouldn't
>> easyly overheat.
>
> Does it have IPMI, LOM/DRAC/ILO/some sort of remote management or is all
> that serial console + networked power switch?  I suspect Debian would be
> more interested in the 3A 2001 server, any idea about cost for that?
> (And same question for remote management.)
>

It was once mentioned to be CNY 10,000~12,000 by a community people,
but we'd ask Lemote for the actual pricing and remote management.

-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7mb+qrzf5s3se-ept6oz-9dhmfijgl+g-hn+1nxvr...@mail.gmail.com

Re: Release sprint results - team changes, auto-rm and arch status

[Aron Xu]

On Wed, Dec 4, 2013 at 2:29 AM, Graham Whaley  wrote:
> On 3 December 2013 12:31, Hector Oron  wrote:
>>
>> Hello Aron,
>>
>> 2013/12/3 Aron Xu :
>> > On Tuesday, December 3, 2013, Hector Oron wrote:
>>
>> >> Debian is currently being bitten by MIPS chinese prototype boards that
>> >> behave unreliably and are hard to replace.
>> >> I, personally, think that being able to buy (if needed) hardware is
>> >> not bad idea either, for the sake of replacements, redundancies,
>> >> etc...
>>
>> > I wonder what do you mean by prototype boards? IIRC those 2E boxes are
>> > not
>> > prototypes but was available for purchase, but because they are old and
>> > 2F
>> > CPUs replaces its position...  Well the bad thing is that there are 3
>> > versions of 2F that has/had been put in production and only the last one
>> > does not have the NOP hardware bug...
>>
>> Apologies for the confusion, allow me to clarify, I was referring to
>> 'mips' Octeon boards, either those were prototypes or failed QA, so
>> out of four boards send to ubcece:
>>  - One board was DOA
>>  - Two boards are really unreliable
>>  - One board is somehow stable
>> All of the above came with notes saying that eth0 was broken.
>>
>> We do not want to repeat the same mistake for the mipsel port.
>>
>> > I once used a 2F box for a couple of days and I now feel that 3A boards
>> > are
>> > much better than 2E/2F. Also, Lemote's Spark 6100 machine is easier to
>> > buy
>> > than Loongson's boards (Lemote's are available for purchase online
>> > without
>> > the need of contacting beforehand).
>>
>> Yes, I found a Spark 3A 6100 at taobao site. I was planning to get one
>> for myself and check whether it can be worth it for Debian
>> infrastructure. So, I was wondering if you had experience with it and
>> if there is mainline supported kernel, bootloader, etc... in essence,
>> is it able to run buildd software with Debian software components
>> (doing minimal enablement)?
>
>
> Does anybody have a URL for purchase of those Spark 6100 machines? I had a
> surf on taobao, but completely failed to find anything lemote or loongson.
> I did check recently with the European distributor (tekmote) if they were
> going to sell the '3A mini-pc or desktop', and they said no :-(
>

And here you are:
http://item.taobao.com/item.htm?id=22206048695

Price is CNY 3999 right now, seems to be much cheaper than before (I
remember it was about CNY6999).

Thanks,
Aron


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5hztfnwgzuu3_uqgjj6j5emmwwtkbcyrjhuyftnd3...@mail.gmail.com

Re: Release sprint results - team changes, auto-rm and arch status

[Aron Xu]

On Tue, Dec 3, 2013 at 8:31 PM, Hector Oron  wrote:
> Hello Aron,
>
> 2013/12/3 Aron Xu :
>> On Tuesday, December 3, 2013, Hector Oron wrote:
>
>>> Debian is currently being bitten by MIPS chinese prototype boards that
>>> behave unreliably and are hard to replace.
>>> I, personally, think that being able to buy (if needed) hardware is
>>> not bad idea either, for the sake of replacements, redundancies,
>>> etc...
>
>> I wonder what do you mean by prototype boards? IIRC those 2E boxes are not
>> prototypes but was available for purchase, but because they are old and 2F
>> CPUs replaces its position...  Well the bad thing is that there are 3
>> versions of 2F that has/had been put in production and only the last one
>> does not have the NOP hardware bug...
>
> Apologies for the confusion, allow me to clarify, I was referring to
> 'mips' Octeon boards, either those were prototypes or failed QA, so
> out of four boards send to ubcece:
>  - One board was DOA
>  - Two boards are really unreliable
>  - One board is somehow stable
> All of the above came with notes saying that eth0 was broken.
>
> We do not want to repeat the same mistake for the mipsel port.
>

Of course, the board they donated are not intended for being
buildd/porterbox but just for continuing the development of 64-bit
port. What Graham mentioned for replacing existing Debian mipsel
hardware are production boards sell by Loongson, Inc.

>> I once used a 2F box for a couple of days and I now feel that 3A boards are
>> much better than 2E/2F. Also, Lemote's Spark 6100 machine is easier to buy
>> than Loongson's boards (Lemote's are available for purchase online without
>> the need of contacting beforehand).
>
> Yes, I found a Spark 3A 6100 at taobao site. I was planning to get one
> for myself and check whether it can be worth it for Debian
> infrastructure. So, I was wondering if you had experience with it and
> if there is mainline supported kernel, bootloader, etc... in essence,
> is it able to run buildd software with Debian software components
> (doing minimal enablement)?
>

As mentioned in previous mails, all Loongson 3A products do not have
proper upstream kernel support currently (patches at linux-mips but
not accepted), and a new group of people are now working on it to see
if the problem can be solved. For boards with Loongson CPUs they use
PMON, which combines the functionality of BIOS and bootloader. PMON of
all the boards I have seen are decent to use, i.e. having at least
32bit DMA support and 4x2GB DDR3 RDIMMs, some of them support 40bit
DMA (most of Lemote's products do). UDIMM support is not good at the
moment and the supported single memory bank size is limited to 2GB for
RDIMM.

So in most cases there's no need to flash PMON except you want to
enable 40bit DMA support for those who doesn't have it before. And
after choosing a properly built kernel then almost (if not) all Debian
packages are working as expected. We have run Debian mipsel buildd
software for a couple of months without problem, and now we are
running the mips64el version without problem. Stuff relies on kernel
features heavily wasn't work as expected as the kernel we used isn't
using standard Debian config (e.g. lacking of aufs support, etc).

Thanks,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4ggejftop73ammioa+yd8mu_isp6itzg5wjfqfs1x...@mail.gmail.com

Re: Release sprint results - team changes, auto-rm and arch status

[Aron Xu]

On Tuesday, December 3, 2013, Hector Oron wrote:

> Hello,
>
> 2013/12/3 Aron Xu >:
>
> >> What do you think of Lemote Spark 3A 6100 machines? As those as
> >> suitable as the motherboards you propose?
>
> > As mentioned previously, we have a board donated by Lemote, which I
> believe
> > is a very early version of the board that have been used for their
> internal
> > testing. From the experience I get from that board, stability is good (no
> > hang or crash so far) and performance do not differ from the one
> produced by
> > Loongson, and it's even better because Lemote people are much easier to
> be
> > reached for support than Loongson (they are really helpful when we were
> > dealing with some PMON upgrading issues).
>
> Debian is currently being bitten by MIPS chinese prototype boards that
> behave unreliably and are hard to replace.
> I, personally, think that being able to buy (if needed) hardware is
> not bad idea either, for the sake of replacements, redundancies,
> etc...
>
> Regards,
> --
>  Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.
>


I wonder what do you mean by prototype boards? IIRC those 2E boxes are not
prototypes but was available for purchase, but because they are old and 2F
CPUs replaces its position...  Well the bad thing is that there are 3
versions of 2F that has/had been put in production and only the last one
does not have the NOP hardware bug...

I once used a 2F box for a couple of days and I now feel that 3A boards are
much better than 2E/2F. Also, Lemote's Spark 6100 machine is easier to buy
than Loongson's boards (Lemote's are available for purchase online without
the need of contacting beforehand).


Thanks,
Aron

Re: Release sprint results - team changes, auto-rm and arch status

[Aron Xu]

On Tuesday, December 3, 2013, Hector Oron wrote:

> Hello,
>
> 2013/12/2 Graham Whaley >:
>
> >  If this works out, my intention is to purchase three 3A motherboards to
> > donate for mipsel use (2x buildd, 1x porter I'd expect?). Then *maybe* we
> > could move one of the BCM91250 Swarm boards over from mipsel to mips(be)
> > whilst I work on some other BE options?
>
> What do you think of Lemote Spark 3A 6100 machines? As those as
> suitable as the motherboards you propose?
>
>
As mentioned previously, we have a board donated by Lemote, which I believe
is a very early version of the board that have been used for their internal
testing. From the experience I get from that board, stability is good (no
hang or crash so far) and performance do not differ from the one produced
by Loongson, and it's even better because Lemote people are much easier to
be reached for support than Loongson (they are really helpful when we were
dealing with some PMON upgrading issues).


Thanks,
Aron

Re: Release sprint results - team changes, auto-rm and arch status

[Aron Xu]

(Re-posting, pressed send accidentally.)

On Friday, November 29, 2013, Aurelien Jarno wrote:

> Some precision about the MIPS machines:
>
> On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote:
> >  * [mips, mipsel] buildds/porterboxes run on hardware which is very old
> or has known defects:
> >- mips octeon is unstable
>
> Better me more precise there, Octeon machines in general are very
> stable. That said out of the three machines we have in Debian, two are
> unstable, the other one is very stable. We never really understood why,
> we only have remarked they have different CPU revision number.
>
> >- mipsel loongson have CPU bugs
>
> I see on http://release.debian.org/jessie/arch_qualify.html that it
> concerns the "NOP implementation error" from Loongson 2F. Debian is
> using Loongson 2E for buildds and porters machines, which are not
> affected by this issue.
>
>
We've got anther 3A board today, which is an official product of Loongson,
Inc. that can be purchased on the market. We are able to run a Sid mips64el
system on the board without any visible glitch like the previous one from
Lemote, so I think 3A boards like the ones we have are really good
candidates for replacing old mipsel buildds and porter boxes. They are much
faster (by being quad-core, and some boards have 2 CPU config), and support
larger memory (standard config is 4GB). Also there are willing party that
is considering donating several to Debian.

What we need to fix are their kernels and PMON:
1. Kernel support isn't upstreamed, and we have only succeeded in merging
the patch set to 3.6 and some lower versions which can produce a working
binary. We are running 3.6 for Lemote products and 2.6.36 for Loongson ones.
2. Different boards use quite different PMON, most of them support 2GB DDR3
RDIMM, so the maximum configuration will be limited to 4x2GB. This could be
a smaller issue comparing with the first one though, we are working with
Lemote to see if 8GB UDIMM can be officially supported on their boards.


Thanks,
Aron


-- 
Regards,
Aron Xu

Re: Release sprint results - team changes, auto-rm and arch status

[Aron Xu]

On Friday, November 29, 2013, Aurelien Jarno wrote:

> Some precision about the MIPS machines:
>
> On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote:
> >  * [mips, mipsel] buildds/porterboxes run on hardware which is very old
> or has known defects:

>- mips octeon is unstable
>
> Better me more precise there, Octeon machines in general are very
> stable. That said out of the three machines we have in Debian, two are
> unstable, the other one is very stable. We never really understood why,
> we only have remarked they have different CPU revision number.
>
> >- mipsel loongson have CPU bugs
>
> I see on http://release.debian.org/jessie/arch_qualify.html that it
> concerns the "NOP implementation error" from Loongson 2F. Debian is
> using Loongson 2E for buildds and porters machines, which are not
> affected by this issue.
>
>
I've got anther 3A board today, which is an official product of Loongson,
Inc. that can be purchased on the market. We have made

Re: [loongson-dev] MIPS64EL rootfs available for use and test

[Aron Xu]

On Tue, Nov 12, 2013 at 2:52 AM, Roman Mamedov  wrote:
> On Tue, 12 Nov 2013 01:57:59 +0800
> YunQiang Su  wrote:
>
>> Hi, folks,
>>
>> In the recent days, I figure out the mips64el rootfs and test it on
>> Loongson 3A platform.
>> It works well in general, it's time to release it.
>>
>> It can be download from:
>> http://mips64el.debian.net/debian/rootfs/
>>
>> To install it, what you need to do is just unpack it to a partition
>> and configure kernel/bootloader/fstab by yourself.
>>
>> This is a more detailed instruction for Loongson 3A users:
>> http://mips64el.debian.net/debian/rootfs/README
>>
>> Know issues:
>> 1. MIPS64r2 ISA is required,
>>  while we have made a agree to downgrade the requirement to
>> mips3 in future.
>
> Hello,
>
> Thank you very much for your work, it is nice to see Loongson is not
> forgotten. :)
>
> I wonder will this work on Loongson 2F? It is MIPS64 too, but is it "r2"?
>

It does not work on Loongson 2F, because Loogson 2F is 64-bit capable
but supports MIPS-III only. You'll need 2G, 3A ,or 3B to use this work
if you'd like to choose from Loongson family.

Original mail also metioned that it will downgrade to use MIPS3 in the
future, that means rebuilding the whole archive and creating a new
rootfs, which is able to work on Loongson 2E/2F.

-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5gw+aftfz4pwdjezohhryk1i5ch_ivnybj0ssh7sk...@mail.gmail.com

Re: MIPS64EL port box is ready for use

[Aron Xu]

On Wed, Oct 30, 2013 at 3:11 AM, Bastien ROUCARIES
 wrote:
> On Tue, Oct 29, 2013 at 7:56 PM, Aron Xu  wrote:
>> On Wed, Oct 30, 2013 at 2:40 AM, Bastien ROUCARIES
>>  wrote:
>>> On Tue, Oct 29, 2013 at 7:35 PM, Aron Xu  wrote:
>>>> On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen  wrote:
>>>>> ]] Aron Xu
>>>>>
>>>>>> > IPMI would be lovely, but I'm not sure we can locate a board right now 
>>>>>> > with
>>>>>> > that - so, we may have to fix remote management with a remotely 
>>>>>> > controlled
>>>>>> > power/reset box - I believe they exist (something else I've been 
>>>>>> > looking
>>>>>> > into). If the DSA already use some then I'd be interested to hear 
>>>>>> > which :-)
>>>>>>
>>>>>> I don't know if IPMI is available, but there is certain kind of PCI
>>>>>> device that can help with remotely power on/off the machine controlled
>>>>>> by SMS. I'm curious if DSA think IPMI is mandatory for buildd and
>>>>>> porterbox.
>>>>>
>>>>> We would very much like «reasonable remote access».  Whether that's IPMI
>>>>> onto a BMC or serial console which can interact with the boot loader and
>>>>> a network-enabled power strip is less important.  Of course, having nice
>>>>> features like mounting of ISOs over HTTP and such is a nice bonus, but
>>>>> not a requirement.
>>>>>
>>>>> We haven't really talked about how and when it should be enforced, but
>>>>> I'm reluctant to take on more porter hardware that lacks reasonable
>>>>> remote management.
>>>>>
>>>>
>>>> If we can find a way of letting Loongson 3A board supports remote
>>>> console then you are able to re-install the system because PMON have
>>>> networking support and can boot the system from tftp. Power control
>>>> can be done by hacking the on-board power button pins.
>>>
>>> It could be done trivally from a chip arm card. Using socat from a tty
>>> to a ssh tunnel
>>> see http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt
>>
>> Looks really cool, and I think it's doable to support power control
>> like what you've suggested already.
>
> What are the safety specification appliable by DSA ? Main tension ?
> Does the board have a power brick ?
>

I'm  not sure about DSA's opinion, and here is the information about
the board. It is an almost standard ITX one, and we've put it in an
ITX chassis retired from a ~2006 Lenovo PC, using its power supply.
The board has some pins for connecting power bottons (Power and
Reset), though we are not using it because it looks not fit to the
connector of the chassis. There is a dedicate button on the board to
power on/off the machine as well. We used the on board button and no
hard reset needed/conducted since successful installation of hardware.
The mentioned ITX machine (6100 model) available for purchase is just
a complete PC box.

Thanks,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w72n5gqjuzez8tgw+_r+z0e6ur7kvtt0vv5m3fogtx...@mail.gmail.com

Re: MIPS64EL port box is ready for use

[Aron Xu]

On Wed, Oct 30, 2013 at 2:40 AM, Bastien ROUCARIES
 wrote:
> On Tue, Oct 29, 2013 at 7:35 PM, Aron Xu  wrote:
>> On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen  wrote:
>>> ]] Aron Xu
>>>
>>>> > IPMI would be lovely, but I'm not sure we can locate a board right now 
>>>> > with
>>>> > that - so, we may have to fix remote management with a remotely 
>>>> > controlled
>>>> > power/reset box - I believe they exist (something else I've been looking
>>>> > into). If the DSA already use some then I'd be interested to hear which 
>>>> > :-)
>>>>
>>>> I don't know if IPMI is available, but there is certain kind of PCI
>>>> device that can help with remotely power on/off the machine controlled
>>>> by SMS. I'm curious if DSA think IPMI is mandatory for buildd and
>>>> porterbox.
>>>
>>> We would very much like «reasonable remote access».  Whether that's IPMI
>>> onto a BMC or serial console which can interact with the boot loader and
>>> a network-enabled power strip is less important.  Of course, having nice
>>> features like mounting of ISOs over HTTP and such is a nice bonus, but
>>> not a requirement.
>>>
>>> We haven't really talked about how and when it should be enforced, but
>>> I'm reluctant to take on more porter hardware that lacks reasonable
>>> remote management.
>>>
>>
>> If we can find a way of letting Loongson 3A board supports remote
>> console then you are able to re-install the system because PMON have
>> networking support and can boot the system from tftp. Power control
>> can be done by hacking the on-board power button pins.
>
> It could be done trivally from a chip arm card. Using socat from a tty
> to a ssh tunnel
> see http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

Looks really cool, and I think it's doable to support power control
like what you've suggested already.

Cheers,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6R+x2+bQ5JWao_fzynnjHt4Nf=rng+edfpjrk01l+...@mail.gmail.com

Re: MIPS64EL port box is ready for use

[Aron Xu]

On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen  wrote:
> ]] Aron Xu
>
>> > IPMI would be lovely, but I'm not sure we can locate a board right now with
>> > that - so, we may have to fix remote management with a remotely controlled
>> > power/reset box - I believe they exist (something else I've been looking
>> > into). If the DSA already use some then I'd be interested to hear which :-)
>>
>> I don't know if IPMI is available, but there is certain kind of PCI
>> device that can help with remotely power on/off the machine controlled
>> by SMS. I'm curious if DSA think IPMI is mandatory for buildd and
>> porterbox.
>
> We would very much like «reasonable remote access».  Whether that's IPMI
> onto a BMC or serial console which can interact with the boot loader and
> a network-enabled power strip is less important.  Of course, having nice
> features like mounting of ISOs over HTTP and such is a nice bonus, but
> not a requirement.
>
> We haven't really talked about how and when it should be enforced, but
> I'm reluctant to take on more porter hardware that lacks reasonable
> remote management.
>

If we can find a way of letting Loongson 3A board supports remote
console then you are able to re-install the system because PMON have
networking support and can boot the system from tftp. Power control
can be done by hacking the on-board power button pins.

Thanks,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5zqqkac0k1j9wfmbff5ybq8rc-n7fjq1rx0dqtjhd...@mail.gmail.com

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

[Aron Xu]

On Tue, Oct 29, 2013 at 8:13 PM, Graham Whaley  wrote:
>
>
>
> On 29 October 2013 11:50, YunQiang Su  wrote:
> [snip]
>>
>> > 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.
>
> Thanks for the heads up - but, which board is it? ;-) Do you have a
> model/reference number so I can check if the ones I am offered are the same
> as the one you have? I have found a few different ones via google. I would
> suspect you have athe 3A-RS780 board:
> http://www.loongson.cn/product_info.php?id=35
>
> rather than the dual-SoC LS3-CCNUMA-DEV board
> http://www.loongson.cn/product_info.php?id=36
>
> but maybe you have something completely different ?
>

What we are running isn't any of them, and the 2-way server board
looks promising.

>> If  IPMI is available, it will be much better.
>
>
> IPMI would be lovely, but I'm not sure we can locate a board right now with
> that - so, we may have to fix remote management with a remotely controlled
> power/reset box - I believe they exist (something else I've been looking
> into). If the DSA already use some then I'd be interested to hear which :-)
>

I don't know if IPMI is available, but there is certain kind of PCI
device that can help with remotely power on/off the machine controlled
by SMS. I'm curious if DSA think IPMI is mandatory for buildd and
porterbox.

> [snip]
>>
>> >
>> > 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.
>
>
> Hey, agreement! :-)
>
>>
>> >
>> >>
>> >> 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
>> >



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7-zd77fdzw1zuxmeacapfvcd-u0fyzqzo6+0c-bqd...@mail.gmail.com

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

[Aron Xu]

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

It is a development board donated by Lemote, and we were told that it
was used for internal testing.

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

I don't think Loongson 2F mini-PC is a good choice since the limited
amount of DIMMs and its limitation on using DDR2 memory only. It's not
quite cost effective comparing with the 3A server boards. We've found
that even the development board has competent performance for being a
buildd. The board uses DDR3 memory add it performs much better than
any other Loongson 2/3 products (Gdium Liberty, 2E/F mini-PC, 3A
notebook) which uses DDR2 memory.

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

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6xasskt0neb2y2zmyutkc3sdeza0qe78pcwh7dpcr...@mail.gmail.com

Re: mips64el port build failed list

[Aron Xu]

On Wed, Oct 16, 2013 at 12:06 AM, Javier Vasquez
 wrote:
> On Tue, Oct 15, 2013 at 5:33 AM, YunQiang Su  wrote:
>> We are working on the port of mips64el, and the progress is quite good.
>
> Are they compiled with "n64" abi, or with "n32" abi?  The arch name is
> confusing at times.
>
> Thanks,
>
> Javier.
>

They are compiled with the n64 abi, using mips64r2 instruction set
currently. The instruction set may be changed later (rebuild) before
introducing it to debian-ports.org as mips64r2 is a quite "new"
instruction to many hardware that is 64bit capable but only supports
mips3.

Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4dnrtgru2aa6zhhsr3xw4m_8lme7wxjkxug-e9c8x...@mail.gmail.com

Re: Reporting 1.2K crashes

[Aron Xu]

On Wed, Jun 26, 2013 at 5:37 AM, Alexandre Rebert
 wrote:
> Hi,
>
>> I understand. But two weeks might be a bit too short for the majority
>> of those crashes. Many upstream authors don't get paid for working on
>> their software.
>
> I first want to clarify the purpose of the two-week delay to make sure
> we are on the same page.We do not expect upstream developers to fix
> the bugs in that time frame. The two-week delay allows developers to
> assess the bugs' seriousness. If the bug is security critical and two
> weeks is too short to patch it, they can contact us and we'll gladly
> delay the public disclosure further. If the bug is not security
> critical however, then I do not see any reason not to submit it on the
> BTS.
>
> If you believe that the delay is too short nonetheless, we can
> definitely extend it. What would be a reasonable of time for
> developers to review the bugs then?
>
> Thanks,
> The Mayhem Team
> Cylab, Carnegie Mellon Univeristy
>

I wonder whether you have checked where the crash is caused, you have
sent several mails to me for every binary in your test run, but in
dmesg.txt you provided all of them are from the very same library.
This will cause lots of duplicates, and it seems feasible for you to
merge them and make the report more accurate.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6fywy_ktikgx-v1rrbprdy_4qtfghcdq8p54-6oft...@mail.gmail.com

Re: Multi-Arch for plugin packages

[Aron Xu]

On Thu, May 30, 2013 at 11:02 PM, John Paul Adrian Glaubitz
 wrote:
> Hello!
>
> I am maintaining one of the gkrellm2 plugin packages, namely
> gkrellm2-cpufreq. All of these gkrellm2 plugin packages install their
> plugins into /usr/lib/gkrellm2/plugins, including mine.
>
> However, I was wondering whether the plugins should actually
> get installed into /usr/lib/${DEB_HOST_MULTIARCH}/gkrellm2/plugins.
>
> Since the plugins aren't really considered shared libraries, I
> am not sure whether Multi-Arch has to be considered for these.
>
> Anyone knows how Multi-Arch is handled for other similar plugin
> packages, other than gkrellm2 plugins?
>
> I have created a Multi-Arch version of my gkrellm2-cpufreq now,
> but I haven't uploaded it yet.
>
> Cheers,
>
> Adrian

What we've done to IM module packages are exactly what you described,
they are plugins to UI toolkits (GTK+, Qt). But please be careful to
make sure they really work as expected when co-installed, i.e the i386
version of the application can use plugins from i386 path, and amd64
version of the program likewise.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5xzOHgvmk0eovZ1EjMh17K=dmr6elpe872jkkyhah...@mail.gmail.com

Re: optimizing PNGs

[Aron Xu]

On Mon, May 27, 2013 at 1:42 AM, Mathieu Malaterre  wrote:
> On Sun, May 26, 2013 at 5:56 PM, Adam Borowski  wrote:
>> A while ago, someone raised the possibility of recompressing PNG files.
>> Unlike xz, this would save space not only on mirrors but also on live
>> installed systems.  PNGs are nearly incompressible so this is mostly
>> independent from xz.
>>
>> At least by number, there's a lot of PNG images:
> [...]
>>   5 ns3-doc
>
> This one is slightly different and should be treated differently IMHO.
> See `Subject: Ridiculously large packages`[1] on debian-cd, which got
> solved using SVG output when generating doxygen documentation. See for
> example:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557238
>
> 2cts
> [1] https://lists.debian.org/debian-cd/2009/11/msg00039.html
>

Can you give a more detailed pointer to `got solved using SVG output
when generating doxygen documentation`? ns3-doc currently runs optipng
against all generated PNG files during the arch:all package
generation, which costs quite some time to finish even on a quite fast
server but reduces the size for about 300MiB.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5aH9E2RTPMTL=rxce1fjk9fbxo6krjugjzy6gpadb...@mail.gmail.com

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

[Aron Xu]

On Wed, May 8, 2013 at 12:52 AM, Marco d'Itri  wrote:
> On May 07, Jonathan Dowland  wrote:
>
>> > If we do this, I'd prefer to make /usr a symlink to / on new installs
>> I've always thought that myself, but it seems most folks who are pro
>> merge tend to propose going the other way. I've never understood why.
> I was trying to not start a new discussion about this, but since you
> asked: moving /usr in / does not solve any significant problem, while
> moving /{bin,sbin,lib} to /usr allows some very interesting new things
> like being able to have a truly shared stateless /usr containing the
> whole OS, which can be used for things like appliances which can then be
> upgraded and rolled back with a single rename(2).
>
> The Fedora page explains some:
> http://fedoraproject.org/wiki/Features/UsrMove
>

I support doing /usr move, for it can help on making better use of
snapshot function of BTRFS/ZFS.

An easy example is that, on Solaris, there is a something called boot
environment (BE), which is essentially snapshots of the combination of
/usr and /boot, users can switch between different BEs easily without
affecting any user data. Without /usr merge, doing such work could be
much more complicated because user data and system data is mixed in
the file system's hierarchy, it's hard to make sure switching between
different snapshots won't change user data. While if such thing is
done properly, then user won't be bothered about messing up the system
on upgrades or experiments anymore. They can switch among different
working environments easily, without dealing with the odds caused by
multi-boot.

There is apt-btrfs-snapshot around for some time (hasn't been in
Debian, yet), and it can be relied upon in production systems only
when the separation of system data and user data is done.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6enqh2uphthhezupggq0oj_hftm32ufunipbcpwki...@mail.gmail.com

Re: jpeg8 vs jpeg-turbo

[Aron Xu]

On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert
 wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>> Hi Bill and Debian Developers,
>>
>> My proposal is:
>> A. Add libjpeg-turbo to Debian archive (that's easy)
>> B. Add required provides/alternatives for libjpeg62-dev and
>> libjpeg8-dev (where API/ABI match)
>> C. Decide which package should provide default libjpeg-dev library
>>
>> 1. 
>> https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
>> 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
>> 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034
>
> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more 
> feature.
>

>From a user's prospective, I don't think adding bunches of not widely
used features is that useful (I mean it's useful but not that
important), but speed does matter a lot, especially on slower hardware
like ARM-boards.



--
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7KO=g7vi+uymphed5jp9xqxpgtvxaj0-c6_ax-ugz...@mail.gmail.com

Bug#697270: PC 32-bit programs fails to work on amd64

[Aron Xu]

On Fri, Jan 4, 2013 at 1:44 AM, Alexey Eromenko  wrote:
> But having 32-bit LSB compliance will help people a _LOT_.
>

This does not mean you can't run 32bit application under a 64bit
Debian installation, it's because the support is not added into
default installation as the feature isn't considered "stable" in the
Debian way. You can search for Multi-Arch for more details on this
topic. You will be able to run most of the 32bit applications by
installing the required 32bit libraries, and the error of "File does
not exist" means some/all of the required 32bit libraries do not
exist.  I agree it is not a user-friendly error message which can
cause misunderstanding, but that message should not be fixed by Debian
as Russ has given the details.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7077GELw3Wn98Mw3RW=+ojab9h-ud+o5-qyl+gxdg...@mail.gmail.com

Bug#697270: PC 32-bit programs fails to work on amd64

[Aron Xu]

On Fri, Jan 4, 2013 at 1:31 AM, Alexey Eromenko  wrote:
> On Thu, Jan 3, 2013 at 7:25 PM, Thomas Goirand  wrote:
>>
>> on a 64 bits arch Debian, when really, you'd better just do:
>> apt-get install iceweasel
>>
>> and use your newly installed browser in 64 bits mode...
>
> Not, because my job requires the latest FireFox (latest-and-greatest).
> And the standard FireFox, which is 32-bits, should work.
> Debian should ship with at least basic 32-bit packages, for LSB
> dependency. (3rd party vendors code for 32-bit LSB)
>

Btw, if you want the "latest" Nightly, try
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
or "latest" Firefox, try
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest/

All of them are available under both 32bit and 64bit x86 architectures.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7lzvob5ubn3o_7rgqd_ndh5_jssrremctnksuzgnu...@mail.gmail.com

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Aron Xu]

On Sun, Aug 19, 2012 at 1:47 AM, Marco d'Itri  wrote:
> On Aug 18, Marc Haber  wrote:
>
>> Because Debian prides itself in being Universal regarding ports and
>> architectures.
> Does it? Who said so?
> But even if this were true, it does not automatically justify dumbing
> down the OS which people in the real world use for the sake of toy
> ports.
>

For yourself, they might be toy ports, but please don't speak on
behalf of others from time to time when nobody authorized you to do
so. I'm not using those ports everyday but I respect their passion and
efforts.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7_8b3CeCjceUxYB27KRKrJ_Su_SHrqDv7sCq=smkn...@mail.gmail.com

Re: scim: problems with libclutter-imcontext*

[Aron Xu]

On Sun, Jul 8, 2012 at 8:28 PM, Toni Mueller  wrote:
>
> Hi,
>
> while working on scim, we found that there's a problem that appears to stem 
> from
> libclutter-imcontetext-0.1-dev apparently not being multi-arch'ed. I quote 
> from
> an email by Tz-Huan:
>
>
> -- cut
> The scim try to figure out the module directory of clutter-imcontext
> in these ways:
>
> * search clutter-libdir via `$PKG_CONFIG --variable=libdir
> clutter-imcontext-0.1`,
>if it successes, set the module directory to
> $clutter-libdir/clutter-imcontext/immodules
> * otherwise, set the module directory to $libdir/clutter-imcontext/immodules
>   (libdir is passed when running configure script, so it should be
> /usr/lib/${MULTI_ARCH_PATH}
>in debian).
>
> In testing, libclutter-imcontext-0.1-dev doesn't multi-archified itself
> (http://packages.debian.org/testing/i386/libclutter-imcontext-0.1-dev/filelist),
> so scim get "/usr/lib" from the first step (pkg-config way) and set
> the module directory to
> /usr/lib/clutter-imcontext/immodules.
>
> However, libclutter-imcontext-0.1-dev does multi-archified in sid
> (http://packages.debian.org/sid/i386/libclutter-imcontext-0.1-dev/filelist)
> so scim get "/usr/lib/${MULTI_ARCH_PATH}" from pkg-config and set the module
> directory to /usr/lib/${MULTI_ARCH_PATH}/clutter-imcontext/immodules.
> -- cut
>
> What would be the preferred way to solve this problem, please?
>
> TIA!
>
>
> Kind regards,
> --Toni++
>
>

Short answer is: wait.

clutter-imcontext package was uploaded to unstable at Jun 28, so it's
not blocked by freeze. Just wait until it migrate to testing then
everything will be fine. If your package haven't been uploaded now,
then you don't need to bother with this issue because it will need
more time to migrate unless release team guaranteeing they will
unblock _and_ force its migration as soon as you upload, which is
almost impossible to happen.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6bqcyepcscoqnxnfhyd0vmp8a076jpxbbh8dx8w1z...@mail.gmail.com

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

[Aron Xu]

Hi,

Regarding your question, it is recommended to do as follow during freeze:

unstable: any version that you would like to hit testing soon, so it's
the version that Release Team agreed (or likely) to unblock it.

experimental: any version that won't make its way to unstable,
including usual experimental stuff as well as things that Release Team
aren't likely to have in testing during the freeze, for example
significant upstream releases.

testing-proposed-updates: only use it when you haven't followed above
suggestions, that is to say you have a higher version number in
unstable which won't migrate to testing, in the case you can't upload
your fix for the testing version to unstable as usual and you have to
upload it to testing-pu instead.

Because packages uploaded to testing-proposed-updates are unlikely to
have so much testing as in unstable, it's discouraged to be used
unless necessary (versioning issues). So please make sure that
unstable is only for versions actually destined for testing. :-)

--
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6o5t2ycrlek9hvmvgyf1np-qpli1nfk-ozmv7m-oo...@mail.gmail.com

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Aron Xu]

On Tue, Jun 12, 2012 at 2:39 AM, Clint Adams  wrote:
> On Tue, Jun 12, 2012 at 02:23:47AM +0800, Aron Xu wrote:
>> sure whether it's relevant to Debian. People at Security Team are not
>> only responsible for fixing things when it breaks out, but also make
>> sure sensitive information is being disclosed in a correct form at a
>> correct time. In the end, I believe talking with them beforehand is
>> always a right way to do, no matter if Debian is affected by this
>> particular issue.
>
> Coordinated disclosure is irresponsible, and we shouldn't do it.
>

Then it's better to start the discussion at debian-security@l.d.o or
at least start a new thread, :) Currently our Security Team is tend to
coordinate disclosures, I think (but I'm not a team member, of
course).



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5royoyascd1wppvjma3mwk10jquopn5dkxggse2y0...@mail.gmail.com

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Aron Xu]

On Tue, Jun 12, 2012 at 2:40 AM, Thomas Goirand  wrote:
> On 06/12/2012 02:23 AM, Aron Xu wrote:
>> I'm not saying you are disclosing anything, but you are asking if
>> someone knows it's in what status publicly in a Debian development
>> mailing list. Then this may lead to some disclosing and even mislead
>> some other people. Yes there are many people doing tests just like
>> you, and they are reporting their results in many ways they prefer.
>> But as you are a DD you'd better not ignore our Security Team when
>> starting discussion publicly about a security incident your are not
>> sure whether it's relevant to Debian. People at Security Team are not
>> only responsible for fixing things when it breaks out, but also make
>> sure sensitive information is being disclosed in a correct form at a
>> correct time. In the end, I believe talking with them beforehand is
>> always a right way to do, no matter if Debian is affected by this
>> particular issue.
>>
>
> The first time I wrote it, it wasn't clear enough. Maybe writing with
> CAPS-ON will help your understanding! :)
>
> IT HAS ALREADY BEEN MADE PUBLIC (for example: on slashdot) !!!
>
> Do you get it now? :)
>

It's YOU that didn't get my point, :)

> With such security "glitch", how much do you expect from keeping
> such a discussion secret, with the security team? I'm telling you,
> you'd achieve absolutely nothing. Everyone will know so fast that
> it doesn't mater at all. And it's better that everyone in Debian knows
> about what's going on, so we have at least a little be of opportunity
> to fix what can be before disasters.
>

I'm not expecting to hide anything, but it's harmful to announce the
world by a discussion in debian-devel that we are affected with no
solution provided, at the time related people (means the maintainers
and Security Team, not including the user - like you) haven't said a
word about it.

If you are trying to informing people to act, then debian-devel is not
a good place, because you can't expect all Debian users are following
our mailing lists, it's YOU want to be sure for something, then
confirm with mysql's maintainer and/or Security Team will give you a
certain answer. debian-devel is not a place for collecting random
trying discoveries for security related issues anyway.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7wdcxsinarakgyjmcunbsdachultnyroj4_0b1k4z...@mail.gmail.com

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Aron Xu]

On Tue, Jun 12, 2012 at 2:11 AM, Thomas Goirand  wrote:
> On 06/12/2012 01:52 AM, Aron Xu wrote:
>> IMHO I suggest to talk with Security Team before disclosing
>> information that might be sensitive in the mean time on a Debian
>> development mailing list.
>>
> Could you explain to me what exactly I'm disclosing?
> The news is already on slashdot and so on, and I think
> it'd be better to know, as hackers will.
>

I'm not saying you are disclosing anything, but you are asking if
someone knows it's in what status publicly in a Debian development
mailing list. Then this may lead to some disclosing and even mislead
some other people. Yes there are many people doing tests just like
you, and they are reporting their results in many ways they prefer.
But as you are a DD you'd better not ignore our Security Team when
starting discussion publicly about a security incident your are not
sure whether it's relevant to Debian. People at Security Team are not
only responsible for fixing things when it breaks out, but also make
sure sensitive information is being disclosed in a correct form at a
correct time. In the end, I believe talking with them beforehand is
always a right way to do, no matter if Debian is affected by this
particular issue.




-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6smb3shwjwmeo_-vuruvzrviigonbsxf3pgnxpkoq...@mail.gmail.com

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Aron Xu]

On Tue, Jun 12, 2012 at 1:44 AM, Thomas Goirand  wrote:
> Hi,
>
> Since it has been made public, I believe it's ok to discuss it in
> -devel. I came across this:
> http://seclists.org/oss-sec/2012/q2/493
>
> Is the Squeeze version affected? And SID? By reading it, especially the
> end about GCC, it's unclear to me if we need an urgent patch:
>
> "To my knowledge gcc builtin memcmp is safe, BSD libc memcmp is safe.
> Linux glibc sse-optimized memcmp is not safe, but gcc usually uses the
> inlined builtin version."
>
> In which case are we?
>

IMHO I suggest to talk with Security Team before disclosing
information that might be sensitive in the mean time on a Debian
development mailing list.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4mob-swjzygcwbw-qlbhhjf+umos+38uq839bmra2...@mail.gmail.com

Re: [xml/sgml-pkgs] Processed: severity of 676686 is important

[Aron Xu]

severity 676686 serious
thanks

Please don't lower it to make it migrate, I've already explained the
reasons, and let me repeat:

1. There aren't so many user-visible changes in this version, but the
most important one is moving patches to quilt maintained.
2. I'll make sure to upload new version or downgrade the severity
before 15th, so it won't bother release team for unblocking.

On Mon, Jun 11, 2012 at 6:45 PM, Debian Bug Tracking System
 wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> severity 676686 important
> Bug #676686 [libxslt1.1] libxslt1.1: libxslt1.1 binNMU broke multi-arch 
> installability
> Severity set to 'important' from 'serious'
>> thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
> --
> 676686: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676686
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
> ___
> debian-xml-sgml-pkgs mailing list
> debian-xml-sgml-p...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-xml-sgml-pkgs



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5Snye1=GN60OkrUe=TsTnohpHuk_zw=y7falmuggz...@mail.gmail.com

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

[Aron Xu]

On Sat, Jun 9, 2012 at 8:30 AM, Henrique de Moraes Holschuh
 wrote:
> On Sat, 09 Jun 2012, Philipp Kern wrote:
>> On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
>> > Does this mean M-A:same packages should be prevented from being
>> > binNMUed, but only source upload can be accepted?
>>
>> You cannot deprive the Release Team of this tool. Also multiarch bugs are 
>> IMHO
>
> Indeed, we cannot.  But there has never been a need to, anyway.
>
> We'd just have to teach the tool to binNMU all arches when the target
> package would need it due to multiarch.  Release team requests a binNMU of a
> package for some arch, the tool notices it has to do them all because of
> multi-arch constraints, and replicates the request for all other arches.
>
> This is even listed in Ubuntu's MultiarchSpec wiki package...
>
>

Yes, but things are a little bit different here. I did request binNMUs
of all archs, but unfortunately buildds of every architecture
generates a unique changelog entry saying the NMU is done by "${arch}
architecture buildd admin", and you already know what would happen, :)

-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6LoQHqjaBXb-V0z_-_4K=ZbE7MEVA8Yp9SZQ½rr...@mail.gmail.com

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

[Aron Xu]

On Sat, Jun 9, 2012 at 6:17 AM, Philipp Kern  wrote:
> On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
>> Does this mean M-A:same packages should be prevented from being
>> binNMUed, but only source upload can be accepted?
>
> You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO
> at most important, not serious. Possibly we could allow one last sourceful
> upload when the transitions all settled, but it would again increase the 
> review
> load on the release team.
>

OK, I get your point, and I never meant not to binNMU is a reasonable idea.

The reason for RC severity is just to prevent the version from
migrating to testing before I've sorted out the M-A mess as much as
possible on my side - for example #671902. Also, there is no important
user-sensible changes (package maintainers and users) in this version,
but mostly improvements to maintainability.

> IMHO it's on the "if it works, fine, if not, sorry about that" part of the
> list, given that it was finalized so late, with that critical piece missing.
>

Sure, I'll get the final version into archive before freeze,
regardless whether there are remaining odd bits of M-A as long as they
aren't affecting normal users.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4f6buu_jvruta8d9d1m0tcnmkonub3qsh4f4v-mlv...@mail.gmail.com

Re: this bug .. bugs me

[Aron Xu]

On Wed, Jun 6, 2012 at 3:56 AM, Thomas Goirand  wrote:
> On 06/06/2012 01:41 AM, Michael Gilbert wrote:
>> And even then, I plan
>> to defer the matter to the tech committee
> Please do this *now*. We've already discussed about Wine in this
> list few months ago, and the situation is still the same. At some
> point, we need to get things moving...
>
> Thomas
>

They are members of pkg-wine already, so I think they can make changes
that can improve the status but not limited to minimal changes for
NMU. If Mike don't want to "hijack" at least for now, team upload is
good enough.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4j29og50jacldhwidg1be8lvozf5ukkcna0xkxkrf...@mail.gmail.com

Re: About building packages in porterbox

[Aron Xu]

On Sat, May 19, 2012 at 4:38 PM, Aron Xu  wrote:
> On Sat, May 19, 2012 at 4:12 PM, Colin Tuckley  wrote:
>>
>> The problem on armel:
>>
>> /usr/lib/gcc/arm-linux-gnueabi/4.6/../../../arm-linux-gnueabi/libpciaccess.so:
>> undefined reference to `gzopen64@ZLIB_1.2.3.3'
>>
>> Looks like it might be the same problem as mentioned here:
>>
>> http://forums.fedoraforum.org/showthread.php?t=228945
>>
>> Which turns out to be an Ubuntu specific version of zlib which includes
>> gzopen64.
>>
>
> $ objdump -T /usr/lib/i386-linux-gnu/libz.so.1.2.7 | grep gzopen
> d720 g    DF .text  0016  Base        gzopen
> d740 g    DF .text  0016  ZLIB_1.2.3.3 gzopen64
>
> $ objdump -T /usr/lib/x86_64-linux-gnu/libz.so.1.2.7 | grep gzopen
> d7f0 g    DF .text  000d  Base        gzopen
> d800 g    DF .text  000d  ZLIB_1.2.3.3 gzopen64
>
> $ grep gzopen64 /usr/include/zlib.h
>   ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
> #    define z_gzopen z_gzopen64
> #    define gzopen gzopen64
>     ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
>
>

Note: Information above is collected on clean Sid chroots.

I encountered a similar issue with shelxle (1.0.551-1)[1] on mipsel
recently, but rebuilding on mipsel porterbox didn't give more hint
because the build was successful.

[1]https://buildd.debian.org/status/package.php?p=shelxle

-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5rqtsxf87cmdxngxwtzx484dlvmq8dnnrkbwrsbyi...@mail.gmail.com

Re: About building packages in porterbox

[Aron Xu]

On Sat, May 19, 2012 at 4:12 PM, Colin Tuckley  wrote:
>
> The problem on armel:
>
> /usr/lib/gcc/arm-linux-gnueabi/4.6/../../../arm-linux-gnueabi/libpciaccess.so:
> undefined reference to `gzopen64@ZLIB_1.2.3.3'
>
> Looks like it might be the same problem as mentioned here:
>
> http://forums.fedoraforum.org/showthread.php?t=228945
>
> Which turns out to be an Ubuntu specific version of zlib which includes
> gzopen64.
>

$ objdump -T /usr/lib/i386-linux-gnu/libz.so.1.2.7 | grep gzopen
d720 gDF .text  0016  Basegzopen
d740 gDF .text  0016  ZLIB_1.2.3.3 gzopen64

$ objdump -T /usr/lib/x86_64-linux-gnu/libz.so.1.2.7 | grep gzopen
d7f0 gDF .text  000d  Basegzopen
d800 gDF .text  000d  ZLIB_1.2.3.3 gzopen64

$ grep gzopen64 /usr/include/zlib.h
   ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
#define z_gzopen z_gzopen64
#define gzopen gzopen64
 ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6JOA9Z9gao5p=wqk4tebycae6k1xynwothczq9f+7...@mail.gmail.com

Re: Removing the MTA from the default install

[Aron Xu]

On Wed, May 2, 2012 at 7:24 PM, Henrique de Moraes Holschuh
 wrote:
> On Wed, 02 May 2012, Aron Xu wrote:
>> On Wed, May 2, 2012 at 4:37 PM, Adam Borowski  wrote:
>> > On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
>> >> Is this the right time to do it?
>> > No.  Cron needs some way to report about its jobs, mdadm has to notify 
>> > about
>> > failures, etc, etc.
>> >
>> > On the other hand, going from a full blown MTA like exim to something like
>> > ssmtp or dma¹ would be a great idea.
>>
>> Ah, but then we should remove the "Mail server" option from d-i, which
>> is almost useless.
>
> No.  We can keep it, it just doesn't need to be selected by default.
>

Currently if I select only OpenSSH server and basic system tools in
expert mode, Exim gets installed, too.

> However, we really should switch the mail server option to something that
> would be suitable for mail servers (i.e. something that doesn't play stupid
> games with standards), such as postfix.  I've advocated keeping the
> status-quo in the past, but I was not aware of the exim4 brokenness.
>
> I agree that installing "mda" by default on desktop installs would be
> useful.  However IME, server installs are much better served by installing
> postfix, even when they're not MTAs, let alone when they are MTAs...
>

I don't think installing mail servers for desktop installation can be
_that_ useful, not all Debian users are power users who read system
email and mutt (or likewise).


-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4mtmk3-gz5acnoc2tzg_xqhfmzctbxkfvhy6xdc_a...@mail.gmail.com

Re: Removing the MTA from the default install

[Aron Xu]

On Wed, May 2, 2012 at 4:37 PM, Adam Borowski  wrote:
> On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
>> Is this the right time to do it?
>
> No.  Cron needs some way to report about its jobs, mdadm has to notify about
> failures, etc, etc.
>
> On the other hand, going from a full blown MTA like exim to something like
> ssmtp or dma¹ would be a great idea.


Ah, but then we should remove the "Mail server" option from d-i, which
is almost useless.


-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5-ikbB62EhZfbG94B77=njus0wlfnx_0g1ty6x-bu...@mail.gmail.com

Re: Removing the MTA from the default install

[Aron Xu]

On Wed, May 2, 2012 at 4:02 PM, Josselin Mouette  wrote:
> Is this the right time to do it?
>

Not sure whether it's the right time, but I'm sure it's something I've
been waiting for quite some time. :-)



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7iNu4fkHzEm9GPt6bbivjsiYt7dt=cyoob8qqu3vt...@mail.gmail.com

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Aron Xu]

On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow  wrote:
> Aron Xu  writes:
>
>> But what if I endianness does matters for those gettext .mo files?
>> Installing them as libfoo-translations-be and libfoo-translations-le
>> will need some change in gettext support of those
>> applications/libraries, that is finding mo files in alternative paths,
>> and choosing the right one when being built (cross or not) and run
>> (host or qemu).
>
> Yes it does. Or maybe not. Lets talk about the general case instead of
> gettext (gettext uses /usr/share/... so they must be arch independent).
>
> With libfoo being in /usr/lib// any endian dependent data
> should be in /usr/lib/// or /usr/lib/ tuple>// (sorry, did we pick one of them as standard yet?),
> which is usualy a configure option.
>

/usr/lib//package/ is more natural with Autotools and CMake,
which I prefer to use.

> When the files are moved into libfoo-data-be then you can put links in
> /usr/lib/// or /usr/lib/// to
> link to /usr/lib//.
>
>> Apart form (possibly) patching the software, marking the library as
>
> Not the library, only the data files.
>
>> M-A:foreign is questionable. How do we specify dependencies in
>> d/control? If libfoo requires either libfoo-data-be or libfoo-data-le
>> on different architectures, do we really want to hard code which
>> architecture to depend on which package manually?
>
> For the moment I don't see any other choice. If this is a frequent
> problem then some dpkg support could be added or some debhelper
> tool. Detecting the endianness at compile time and setting a substvar
> would be relatively easy even now.
>

Yes, detecting endianness at compile time and setting substvar is
easy, but again if those packages are arch:any, then they'll actually
consume a lot of space on our mirrors (discussed at -devel before).

>> Generating data files for both be and le then making it an arch:all
>> and M-A:foreign package is not a solution for all maintainers, as this
>> requires to patch the software which upstream are tend to reject of
>> inclusion in many cases. Generating such data files in maintainer
>> scripts is another thing I hate because I believe these data meant to
>> have checksum stored in the package file list so that users can verify
>> its integrity when needed.
>
> There is no one solution for all maintainers.
>

If we want to reduce the mirror space consumed by such a package,
building arch:all package is a straightforward solution without
modifying archive management software and dpkg/apt, but it's again not
a good choice because we have to keep using binary upload mechanism
(or the maintainer will be required to patch the software so it can
generate both be/le data during a single buildd run).

> At the moment and given the closeness of the freeze I would just do
> whatever works for now. If that means big and little endian flavours of
> the library have to conflict (libfoo-data-be conflicts libfoo-data-le)
> because the path can't be untangeled then I would still think that would
> be better than no multiarch support at all. The most common case is
> amd64+i386 and adding armel is probably the next common. So most
> multiarch users would be ok.
>
> MfG
>        Goswin

I agree on your opinion. It's much better than nothing. But we do need
to discover possible solution for Wheezy+1 or even Wheezy+2, don't we?
:-)

-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5uu+ojvtfhp-7op6g4ijjdj7pdsi+n5jnqt_r3kt0...@mail.gmail.com

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Aron Xu]

On Fri, Apr 27, 2012 at 16:46, Goswin von Brederlow  wrote:
> Aron Xu  writes:
>
>> On Thu, Apr 26, 2012 at 23:21, Osamu Aoki  wrote:
>>> Hi,
>>>
>>> On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote:
>>>> On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
>>>>
>>>> > If a package is marked as "Multi-Arch: same", files with the same
>>>> > name have to be (byte-to-byte) identical across all architectures.
>>>> > Unfortunately, not all packages obey this requirement. I set up a
>>>> > page to track violators:
>>>> >
>>>> > http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
>>>> > http://people.debian.org/~jwilk/multi-arch/same-md5sums.ddlist
>>>> >
>>>> I've just filed a number of bugs (~60) based on this list, excluding
>>>> binNMUed packages and packages affected by #647522.
>>>
>>> Yep, I got it :-)  And you answered to my question:
>>>
>>>> > Is there any generic solution for GTK girepository files?
>>>> >
>>>> You should remove the multi-arch: same control field, gir packages are
>>>> not ready for multiarch for now.
>>>
>>> I also see for libopencc1 (not mine but I am watching it...)
>>>
>>> [libopencc1 0.3.0-2]
>>> usr/share/locale/zh_CN/LC_MESSAGES/opencc.mo
>>>  2c2024df5378074f4727948eb7133516 mips s390 sparc s390x powerpc
>>>  6a7df4d7f1f5383bd7461de8a0bb4957 kfreebsd-amd64 i386 armel armhf ia64 
>>> kfreebsd-i386 mipsel amd64
>>> usr/share/locale/zh_HK/LC_MESSAGES/opencc.mo
>>>  66224514d0c66fd34bfbf95becf8cfd0 kfreebsd-amd64 i386 armel armhf ia64 
>>> kfreebsd-i386 mipsel amd64
>>>  6c6698b86bbf568baefc414d178108a0 mips s390 sparc s390x powerpc
>>> usr/share/locale/zh_TW/LC_MESSAGES/opencc.mo
>>>  a7fe10a01d59cb26825678bb6c9c2402 kfreebsd-amd64 i386 armel armhf ia64 
>>> kfreebsd-i386 mipsel amd64
>>>  d26ada42ce92c0cea19f4705ca89d433 mips s390 sparc s390x powerpc
>>>
>>> I guess the solution should be the same for now.
>>>
>>> For these issies, I wonder 2 things:
>>>
>>>  * These generated non-code data which depend on arch need some generic
>>>   solution.  Is there any wiki-page summarizing these.  I understand it
>>>   is non-trivial thing and it certainly requires cordinated efforts.
>>>
>>>  * If I vaguely remember, I added this for my package due to the lintian
>>>   warning.  We certainly needs to fine tune text so we do not add
>>>   these.
>>>
>>> Osamu
>>>
>>
>> So we need to revisit the endianness handling in current M-A design.
>> Currently I don't see there are any common way to workaround such
>> problem with Gettext .mo files in a package maintainer's point of
>> view. Even if we have applied workaround for some other data files
>> (install those files under usr/lib/), it does not make sense
>> for these .mo files. Splitting the files into another arch:any package
>> without any M-A fields set does not help, because doing such will make
>> the dependent package which has "M-A:same" not co-installable for two
>> or more architectures.
>
> My understanding of those gettext files was that gettext generated them
> in the hosts endianness but can actualy use them in any endianness. Is
> that right? If so then they could be split out into a M-A:foreign and
> even Arch:all package.
>

I don't know what's the actual situation of gettext dealing with mo
files, maybe someone else can answer. I'm sure someone who are still
caring about tdeb need to have a look at such problem.

> If the endianness of the data matters (not just for gettext files but in
> general) then produce foo-data- with Arch:any and
> M-A:foreign which install the data files into different subdirs. That
> way the data can be shared for the same endianness and both endiannesses
> (?) can be co-installed.
>
> MfG
>        Goswin

But what if I endianness does matters for those gettext .mo files?
Installing them as libfoo-translations-be and libfoo-translations-le
will need some change in gettext support of those
applications/libraries, that is finding mo files in alternative paths,
and choosing the right one when being built (cross or not) and run
(host or qemu).

Apart form (possibly) patching the software, marking the library as
M-A:foreign is questionable. How do we specify dependencies in
d/control? If libfoo requires either libfoo-data-be or libfoo-data-le
on different archite

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Aron Xu]

On Thu, Apr 26, 2012 at 23:21, Osamu Aoki  wrote:
> Hi,
>
> On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote:
>> On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
>>
>> > If a package is marked as "Multi-Arch: same", files with the same
>> > name have to be (byte-to-byte) identical across all architectures.
>> > Unfortunately, not all packages obey this requirement. I set up a
>> > page to track violators:
>> >
>> > http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
>> > http://people.debian.org/~jwilk/multi-arch/same-md5sums.ddlist
>> >
>> I've just filed a number of bugs (~60) based on this list, excluding
>> binNMUed packages and packages affected by #647522.
>
> Yep, I got it :-)  And you answered to my question:
>
>> > Is there any generic solution for GTK girepository files?
>> >
>> You should remove the multi-arch: same control field, gir packages are
>> not ready for multiarch for now.
>
> I also see for libopencc1 (not mine but I am watching it...)
>
> [libopencc1 0.3.0-2]
> usr/share/locale/zh_CN/LC_MESSAGES/opencc.mo
>  2c2024df5378074f4727948eb7133516 mips s390 sparc s390x powerpc
>  6a7df4d7f1f5383bd7461de8a0bb4957 kfreebsd-amd64 i386 armel armhf ia64 
> kfreebsd-i386 mipsel amd64
> usr/share/locale/zh_HK/LC_MESSAGES/opencc.mo
>  66224514d0c66fd34bfbf95becf8cfd0 kfreebsd-amd64 i386 armel armhf ia64 
> kfreebsd-i386 mipsel amd64
>  6c6698b86bbf568baefc414d178108a0 mips s390 sparc s390x powerpc
> usr/share/locale/zh_TW/LC_MESSAGES/opencc.mo
>  a7fe10a01d59cb26825678bb6c9c2402 kfreebsd-amd64 i386 armel armhf ia64 
> kfreebsd-i386 mipsel amd64
>  d26ada42ce92c0cea19f4705ca89d433 mips s390 sparc s390x powerpc
>
> I guess the solution should be the same for now.
>
> For these issies, I wonder 2 things:
>
>  * These generated non-code data which depend on arch need some generic
>   solution.  Is there any wiki-page summarizing these.  I understand it
>   is non-trivial thing and it certainly requires cordinated efforts.
>
>  * If I vaguely remember, I added this for my package due to the lintian
>   warning.  We certainly needs to fine tune text so we do not add
>   these.
>
> Osamu
>

So we need to revisit the endianness handling in current M-A design.
Currently I don't see there are any common way to workaround such
problem with Gettext .mo files in a package maintainer's point of
view. Even if we have applied workaround for some other data files
(install those files under usr/lib/), it does not make sense
for these .mo files. Splitting the files into another arch:any package
without any M-A fields set does not help, because doing such will make
the dependent package which has "M-A:same" not co-installable for two
or more architectures.


-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7uy76eow6y+-urpzungwo11ndswb9q1t4eorlms8a...@mail.gmail.com

Re: Link-Time Optimisation

[Aron Xu]

Hi Thorsten,

You might be interested in reading this thread:
http://lists.debian.org/debian-devel/2011/06/msg00149.html

Activating LTO by default seems not to be a reasonable idea (reasons
are in the given thread), but if maintainer of a package see it's
appropriate then he can use it in the package.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6m_hTzD2=XHKarmyMox=jdkece6jwegnn1-7qltyn...@mail.gmail.com

Re: Multi-arch all-architecture plugins

[Aron Xu]

On Tue, Feb 14, 2012 at 22:10, Ian Jackson
 wrote:
> Aron Xu :
>> On Tue, Feb 14, 2012 at 00:09, Ian Jackson
>>  wrote:
>> > Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"):
>> >> As you said these are usualy plugins that nothing depends on. So this
>> >> wouldn't help much. Also if there is a dependency than the rules for
>> >> m-a:same should be sufficient. If the package is something to depend on
>> >> then packages of all architectures should depend on it if they use
>> >> it. The plugin might only be used by amd64 packages and none of the i386
>> >> would depend on it and then installing only amd64 is perfectly fine.
>>
>> This is true for maybe all programs that use alike communication
>> method between main application and its plugins. I encountered another
>> example with D-Bus. The host architecture side listens on a D-Bus
>> session, and "MA: same" plugins installed in other architecture (i386
>> for me) can communicate with the amd64 one and works perfectly fine.
>
> Goswin and I were talking, I think, about plugins that are loaded with
> dlopen.  These need to be multi-arch:same or something like my
> proposed m-a:all.
>
> Plugins that interact via fork/exec or dbus or sockets or something
> can be any architecture, even a different architecture to the caller.
> They should be m-a:foreign.  They don't present any difficulty since
> we only need to install one version.
>

The plugin I mentioned to be M-A:same was not something that enables
the application to use D-Bus interface, but rather something that
would interact with the main program using D-Bus, especially when they
are also a plugin of another M-A: same library at the same time, they
definitely don't belong to M-A: foreign. And the program set up the
D-Bus session should be M-A: foreign.

My description might be still not very clear, here is an example:

We have:
Non-M-A application: fcitx-bin (fcitx)
M-A: same library: libgtk-3-0
M-A: same plugin: fcitx-frontend-gtk3
M-A: foreign plugin: fcitx-module-dbus

 * libgtk-3-0 is the GTK+ 3 library.
 * fcitx-bin  provides some function that some users need.
 * fcitx-frontend-gtk3 is a libgtk-3-0 plugin, which is intended to
behave as a bridge between libgtk-3-0 and fcitx-bin using D-Bus. It is
called using dlopen() by libgtk-3-0.
 * fcitx-module-dbus is a fcitx-bin plugin, which enables fcitx-bin to
use D-Bus. It is call using dlopen() by fcitx-bin.

Given the host architecture is amd64, fcitx-bin:amd64 and
fcitx-module-dbus:amd64 are configured and running on it, the user has
also configured an i386 architecture, which has libgtk-3-0:i386
installed.

The point here is when fcitx-frontend-gtk3:amd64 is configured,
fcitx-frontend-gtk3:i386 should be Recommended to be installed and
configured as well. I don't know how this can be achieved in
debian/control by the maintainer.


-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w74lsksyyyftjnv5sa2jf8jwweqoweoirz5pd72+xg...@mail.gmail.com

Re: Multi-arch all-architecture plugins

[Aron Xu]

On Tue, Feb 14, 2012 at 00:09, Ian Jackson
 wrote:
> Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"):
>> As you said these are usualy plugins that nothing depends on. So this
>> wouldn't help much. Also if there is a dependency than the rules for
>> m-a:same should be sufficient. If the package is something to depend on
>> then packages of all architectures should depend on it if they use
>> it. The plugin might only be used by amd64 packages and none of the i386
>> would depend on it and then installing only amd64 is perfectly fine.
>

This is true for maybe all programs that use alike communication
method between main application and its plugins. I encountered another
example with D-Bus. The host architecture side listens on a D-Bus
session, and "MA: same" plugins installed in other architecture (i386
for me) can communicate with the amd64 one and works perfectly fine.

(My example are fcitx-frontend-* and fcitx-module-dbus in Sid.)

> I don't think that's the case.  Consider something like fakeroot.  The
> fakeroot binary itself may be any architecture, because its function
> is to set up a socket and be a server for children and set an
> LD_PRELOAD and so forth.  But the libfakeroot.so must be available for
> all configured architectures so that the LD_PRELOAD works no matter
> what architecture(s') binaries end up running.
>
> So you would have:
>
>   Package: fakeroot
>   Multi-Arch: foreign
>   Depends: libfakeroot
>
>   Package: libfakeroot
>   Multi-Arch: all
>
> and it would have to mean "install libfakeroot for all configured
> architectures".  If libfakeroot were m-a:same then it would mean
> "install libfakeroot for the arch whose fakeroot we picked" which is
> wrong.
>

I second this proposal, but with the doubt about making it a "Depends"
on other co-installed architectures. It might be rather irrelevant on
fakeroot, such an "important" package. But when a user decide to
install something on his primary architecture, and wanted to keep his
other co-installed minimal to do some other stuff, forcing them
installing a bunch of things isn't kind.

Making it works like "Recommends" can be more friendly. And yes, this
way has its shortcomings, but seems to be saner.

-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w662+6o1wx_s-iibkyfezbl3btt7213go7wwwugatd...@mail.gmail.com

Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

[Aron Xu]

On Sun, Feb 12, 2012 at 08:00, Carsten Hey  wrote:
> * Aron Xu [2012-02-09 01:22 +0800]:
>> Some packages come with data files that endianness matters, and many
>> of them are large enough to split into a separate arch:all package if
>> endianness were not something to care about. ...
>
> Debian Policy, begin of section 5.6.8:
> | Depending on context and the control file used, the Architecture field
> | can include the following sets of values:
> |  * A unique single word identifying a Debian machine architecture as
> |    described in Architecture specification strings, Section 11.1.
> |  * An architecture wildcard identifying a set of Debian machine
> |    architectures, see Architecture wildcards, Section 11.1.1. any
> |    matches all Debian machine architectures and is the most frequently
> |    used.
> |  * all, which indicates an architecture-independent package.
> |  * source, which indicates a source package.
>
> Possible addition to solve your problem:
>   * littleendian[1], which indicates a package that is installable on
>     all little endian architectures.
>   * bigendian[1], which indicates a package that is installable on
>     all big endian architectures.
>

I agree this will help a lot, and the endians may be shortened as "le"
and "be". But there's still file collision if maintainer doesn't
install them in different paths, but that's another story.

debian-policy people, would you like to take this idea? What's the
steps to make this (possibly) happen?


-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6zX=2_u9qgswi-sno+axxskr4fpk4au1n7cbxtkjd...@mail.gmail.com

Re: Endianness of data files in MultiArch

[Aron Xu]

On Sat, Feb 11, 2012 at 09:36, Russ Allbery  wrote:
> Aron Xu  writes:
>
>> This trick is broken. Dpkg doesn't have similar features like `rpm -V`
>> at present, which verifies if files on disk are identical to what was
>> installed.
>
> That's what debsums does.
>

Thanks for updating me!



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4jj--_sdcj6on91phueqpfgc_+f07l4sb-hnws7yz...@mail.gmail.com

Re: Endianness of data files in MultiArch

[Aron Xu]

On Sat, Feb 11, 2012 at 00:14, Osamu Aoki  wrote:
> [...]
>
> Just think any phrase data with its content size in 16bit integer.
>
> I have bigger example :-)
>
> ipadic: Uncompressed size: 44.5 M
>
> This one, I made them arch:any to build many binary packages.  Similar
> packages use install time conversion trick to keep them "arch: all" but
> this install takes time.
>

This trick is broken. Dpkg doesn't have similar features like `rpm -V`
at present, which verifies if files on disk are identical to what was
installed. I believe it's useful and will land in dpkg someday (but
don't ask me for patch now...). By coverting data files at user's
install, it breaks when the package manager verifies the file's
integrity. I prefer to use more mirror space to doing such thing if I
have to choose between them, which is the current status.

> [...]
>
> I think PO files cases are manageable.  They can use one endianess for
> all platform.
>
> But for any other generic special purpose natural language processing
> code, it is impossible to force upstream to complicates code to use
> particular endianness.
>

Agreed.

>> So unless the program is restarted for every input (which would be the
>> first thing to eliminate to improve responsiveness) there shouldn't be a
>> problem with "fixing" this. It just means extra work you might not be
>> willing (or have time) to invest.
>
> If we are ready to rewite core of such code, you are right.  But if we
> simply accept upstream code design, we will endup making multiple of
> such semi-arch depended data in archive as arch: any.
>
> Osamu

IMHO it's really bad to maintain such a delta between Debian and upstream.

-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4a8yy1udldhzhewdsuz3rdjqek208vgmply1ntxyy...@mail.gmail.com

Re: Endianness of data files in MultiArch

[Aron Xu]

On Fri, Feb 10, 2012 at 19:59, Goswin von Brederlow  wrote:
> Aron Xu  writes:
>
>> Sorry, the thread was broken and I saw your reply just now.
>>
>> On Thu, Feb 9, 2012 at 16:23, Jan Hauke Rahm  wrote:
>>> On Thu, Feb 09, 2012 at 01:58:28AM +0800, Aron Xu wrote:
>>>>
>>>> This is valid for most-used applications/formats like gettext, images
>>>> that are designed to behave in this way, but on the contrary there are
>>>> upstream that don't like to see such impact, especially due to the
>>>> complexity and performance impact.
>>>>
>>>> Currently I am using arch:any for data files which aren't be affected
>>>> with multiarch, i.e. not "same" or "foreign". For endianness-critical
>>>> data that is required to make a library working, I have to force them
>>>> to be installed into /usr/lib//$package/data/ and mark them
>>>> as "Multiarch: same", this is sufficient to avoid breakage, but again
>>>> it consumes a lot of space on mirror.
>>>
>>> Actually, what is "a lot" here? I mean, how many libraries are there
>>> containing endianness-critical data and how big are the actual files?
>>> Not that I'm any kind of expert, but this solution sounds reasonable to
>>> me.
>>>
>>> Hauke
>>>
>>
>> As far as I know, there isn't too many libraries known to have
>> endianness-critical data, but there might be landmines because the
>> maintainer just aren't aware about it.
>>
>> I have the chance to notice this problem because my team maintain
>> several stack of input methods, which usually need to deal with
>> linguistic data. [1]
>>
>> For me here is a library named libpinyin at hand to package, which has
>> some data files of ~7.5MiB size after gzip -9 (the total size of this
>> library is no more than 9MiB after gzip -9). We have 14 architectures
>> on ftp-master, so the data file eats up 105MiB, while if we find some
>> way to have only one copy for be/le, it'll only use 15MiB. And think
>> about when it get released as a stable, a new copy of those data is
>> making their way to the archive when new version get uploaded to
>> unstable.
>>
>> Such concern is also valid to other endianness-critical data that are
>> not bothered with Multi-Arch at present, we need to make them arch:any
>> and in the end they are eating more and more space.
>>
>> [1] Performance is critical for these applications, this doesn't mean
>> it consumes a lot of CPU percentage, but it must response very quickly
>> to user's input - do some complex calculations to split a sentence
>> into words and find out a list of most related suggestions, which
>> needs to query from 10^5 ~ 10^6 lines of data several times to
>> complete such an action. There was project tried to use something like
>> SQLite3 but the performance is a bit frustrating, so they have now
>> decided not to care about that but just design data format that can
>> fit for their requirements.
>> --
>> Regards,
>> Aron Xu
>
> It doesn't sound like the data is to big to fit into ram and it sounds
> like the overhead to fetch data from disk on demand would slow you
> down. So there seems to be no reason to have architecture independent
> data on disk and convert it to the right endianess on startup. Sure
> startup time would increase a bit but running time would remain
> unafected.
>

Well, bear in mind that the size is for compressed data. Decompressed
data are usually even larger, their properties on
compressing/decompressing are more like plain texts, so by
decompressing the 7.5MiB data, you get 22MiB on hard disk.

22MiB seems to be not large enough to not fit into RAM, but I'll
explain why it won't. Usually an input method framework carries many
different input methods (it's easier to understand them as different
algorithms), and users are able to switch them on the fly, by a mouse
click or keyboard shortcut. Different input methods have different
data, so by having three installed (this number is below the average),
usually it needs more than 50MiB data.

Hmm, 50MiB seems still not large enough. Linguist data distributed in
a free license are rare compared to the ones provided with non-free
license, and usually their quality and amount is lower/smaller than
non-free ones. Users can download those data (free to download and
use, but not distributable), and use tools provided by input method to
covert the format. This results into 10^6 lines of data, nearly 100MiB
in size. This time it looks rational to not 

Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

[Aron Xu]

Sorry, the thread was broken and I saw your reply just now.

On Thu, Feb 9, 2012 at 16:23, Jan Hauke Rahm  wrote:
> On Thu, Feb 09, 2012 at 01:58:28AM +0800, Aron Xu wrote:
>>
>> This is valid for most-used applications/formats like gettext, images
>> that are designed to behave in this way, but on the contrary there are
>> upstream that don't like to see such impact, especially due to the
>> complexity and performance impact.
>>
>> Currently I am using arch:any for data files which aren't be affected
>> with multiarch, i.e. not "same" or "foreign". For endianness-critical
>> data that is required to make a library working, I have to force them
>> to be installed into /usr/lib//$package/data/ and mark them
>> as "Multiarch: same", this is sufficient to avoid breakage, but again
>> it consumes a lot of space on mirror.
>
> Actually, what is "a lot" here? I mean, how many libraries are there
> containing endianness-critical data and how big are the actual files?
> Not that I'm any kind of expert, but this solution sounds reasonable to
> me.
>
> Hauke
>

As far as I know, there isn't too many libraries known to have
endianness-critical data, but there might be landmines because the
maintainer just aren't aware about it.

I have the chance to notice this problem because my team maintain
several stack of input methods, which usually need to deal with
linguistic data. [1]

For me here is a library named libpinyin at hand to package, which has
some data files of ~7.5MiB size after gzip -9 (the total size of this
library is no more than 9MiB after gzip -9). We have 14 architectures
on ftp-master, so the data file eats up 105MiB, while if we find some
way to have only one copy for be/le, it'll only use 15MiB. And think
about when it get released as a stable, a new copy of those data is
making their way to the archive when new version get uploaded to
unstable.

Such concern is also valid to other endianness-critical data that are
not bothered with Multi-Arch at present, we need to make them arch:any
and in the end they are eating more and more space.

[1] Performance is critical for these applications, this doesn't mean
it consumes a lot of CPU percentage, but it must response very quickly
to user's input - do some complex calculations to split a sentence
into words and find out a list of most related suggestions, which
needs to query from 10^5 ~ 10^6 lines of data several times to
complete such an action. There was project tried to use something like
SQLite3 but the performance is a bit frustrating, so they have now
decided not to care about that but just design data format that can
fit for their requirements.
-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6qiM6VB_2iegzKMFx=tv+ert6lqely6naoqfpaco-...@mail.gmail.com

Re: Endianness of data files in MultiArch

[Aron Xu]

On Thu, Feb 9, 2012 at 20:52, Goswin von Brederlow  wrote:
>
> It should be possible to build a converter or generator that can output
> either endianess. So you could have a single arch:all package with both
> /usr/share/$package/data/{be,le} in it or to generate the right
> endianness on install. That way the "performance impact" argument is non
> existant.
>

Yes, it's "possible", but it requires additional work for both
upstream/debian maintainer to care the case a lot. IMHO this idea is
not very constructive for finding a better solution than the current
way.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w66hu3l_nyr9egmjbtdq4kyr8issahc2hungtgq0p4...@mail.gmail.com

Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

[Aron Xu]

On Thu, Feb 9, 2012 at 01:35, Simon McVittie  wrote:
> On 08/02/12 17:22, Aron Xu wrote:
>> Some packages come with data files that endianness matters, and many
>> of them are large enough to split into a separate arch:all package if
>> endianness were not something to care about. AFAIK some maintainers
>> are not aware of endianness issues in their packages and then just
>> ignored it (not sure how many, but if any of them are discovered it
>> should lead to RC bug).
>
> Hopefully Jakub Wilk's automatic checks for conflicting files
> <http://people.debian.org/~jwilk/multi-arch/> will already be picking
> this up, in cases where the less-used-endianness architectures aren't
> broken already.
>
> If the less-used-endianness architectures are already broken, that's
> also a bug (potentially an RC one), just like code that compiles but
> doesn't work on a particular endianness due to other assumptions - and
> if nobody has noticed it yet, presumably the package doesn't have any
> users (or regression tests) on those architectures.
>

Or some of them just gave up because it is "less-used" architecture.

>> It would be great to have some mechanism to
>> handle such kind of problems in Debian, to avoid forcing those data to
>> be placed into arch:any package.
>
> If the right endianness is critical: libfoo:i386 Depends:
> libfoo-data-le, libfoo:powerpc Depends: libfoo-data-be, both data
> packages arch:all, data files in /usr/share/foo/le and /usr/share/foo/be
> respectively?
>

This looks not very nice, because we need to maintain a list of
architectures in debian/control, and when new architectures are added
the package is potentially broken.

Also, arch:all packages are usually generated by the uploading DD on
one architecture, mostly amd64 and i386 today, how can he managed to
generate be data files if he doesn't have access to such a machine?
Adding an option to the data generator/parser and make it able to
generate be/le data on any architecture seems not to be a reasonable
approach.

> Or just make sure the data has an endianness marker, and enhance the
> reading package to do the right byteswapping based on the endianness
> marker - e.g. this has been discussed for gettext, which ended up just
> writing out the same endianness on all platforms. Many formats
> (particularly those that originated on Windows) are always
> little-endian, and big-endian platforms reading them just take the minor
> performance hit; formats that respect "network byte order" have the
> opposite situation.
>

This is valid for most-used applications/formats like gettext, images
that are designed to behave in this way, but on the contrary there are
upstream that don't like to see such impact, especially due to the
complexity and performance impact.

Currently I am using arch:any for data files which aren't be affected
with multiarch, i.e. not "same" or "foreign". For endianness-critical
data that is required to make a library working, I have to force them
to be installed into /usr/lib//$package/data/ and mark them
as "Multiarch: same", this is sufficient to avoid breakage, but again
it consumes a lot of space on mirror.

I thought about something like /usr/share/$package/data/{be,le} in
arch:all, but appears to be not a reasonable solution because we need
to modify the data generator/parser.

-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6s+itap8usgjaqf86mffypaop+qjodetjhdyumb7a...@mail.gmail.com

Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

[Aron Xu]

I want to speak up about endianness of data files, this is a
suggestion but not a flaw which I just want to discover the
possibility of improvement to current status by the chance of
implementing Multi-Arch in Debian.

Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all package if
endianness were not something to care about. AFAIK some maintainers
are not aware of endianness issues in their packages and then just
ignored it (not sure how many, but if any of them are discovered it
should lead to RC bug). It would be great to have some mechanism to
handle such kind of problems in Debian, to avoid forcing those data to
be placed into arch:any package.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w494xg1bwj3lr5rqnjrgrcung-e6igqb+xt6bdygpr...@mail.gmail.com

Re: Removing web server dependencies from web apps

[Aron Xu]

On Fri, Jan 6, 2012 at 16:34, Neil Williams  wrote:
> On Fri, 06 Jan 2012 15:56:37 +0800
> Thomas Goirand  wrote:
>
>> The issue is that most PHP packages in Debian have dependencies on web
>> servers, most of the time with something like this:
>>
>> Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi
>
> Sounds like the situation for which equivs was designed.
>
>> Remember that a strong dependency is *forcing* users to install things,
>
> Not quite. A strong dependency requires that something with that name
> is installed - it can just as easily be an empty package which just
> matches the name. Put that package into your chroots and the problems
> disappear.
>

Disagrees. Debian can't require all users/administrators of a package
to learn how to
*make your own empty package* when the dependency is actually
unnecessary. It that
were me, I'll rebuild the webapp package and remove whatever I don't
like, which is
not reasonable for common users either.

I support to downgrade those Depends to Recommends.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4pCnUUUCw+13aJHLtQ-ceut=qtzz7vk9nbq+3hud1...@mail.gmail.com

Re: zfs-fuse in debian

[Aron Xu]

Hi Dániel,

2011/10/25 József Dániel :
> Hello,
> Quick question. I see you maintain zfs-fuse.
> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
> reason to this, or just lack of time?
> Since zfs-fuse upstream is under extremely heavy development, I have the
> feeling that any risks created by adopting the latest stable release should
> be small compared to the known errors it fixes, so I'm planning to build
> myself a 0.7.0 package by cannibalizing the 0.6.9-1 source pkg in squeeze.
> Do you think the debian patchfile for 0.6.9-1 will apply cleanly to upstream
> 0.7.0? Does it do any deeper code fixes?
> Thanks a lot!
> Daniel

zfs-fuse has been orphaned at Oct 16th, and later Asias He expressed
his interest in adopting the package.[1]

After a quick look at the two versions of package, the old patch won't
work for 0.7.0-1, you may want to try the one prepared by Asias He at
your own risk. Use the following command to get the source and
debian.tar.gz:
dget -x 
http://mentors.debian.net/debian/pool/main/z/zfs-fuse/zfs-fuse_0.7.0-1.dsc

This version of zfs-fuse isn't a part of unstable/experimental, it may
damage your system and data. OK, you have been warned. I tried to
build it, and it won't build on i386, but builds fine on amd64. But I
haven't tried whether it works as expected.

[1]http://bugs.debian.org/637988

-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4ln-gsehwfqf1ivjkz+qz8twtnfglxgn5wbytomq9...@mail.gmail.com

Re: [dd-list] Please use Architecture: linux-any

[Aron Xu]

On Sat, Aug 20, 2011 at 07:11, Samuel Thibault  wrote:
> Hello,
>
> Just a heads-up about Architecture: linux-any. The dd-list below is
> a (non-exhaustive!) list of packages that kfreebsd/hurd maintainers
> believe are candidates for using it in their debian/control file,
> because they are probably not to be ported to non-Linux systems, due to
> strong Linux dependency.
>
> Could people below consider using
>
> Architecture: linux-any
>
> instead of
>
> Architecture: any
>
> in their next upload?  That would help us cleaning the Not-For-Us manual
> list.
>
> Thanks,
> Samuel
>
> [...]
>
> Debian Chinese Team 
>   zhcon
>

zhcon works on FreeBSD 7.x, and before 8.x is out the upstream was
dead. I tried to port it to kfreebsd with some progress, but still not
build/work perfectly. The software still has considerable large user
base, so I would like to continue maintain it for a while.

-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4jd=UE2OcZQ=w6hmp+r9mry2erpxsv8jh+kxfkdql...@mail.gmail.com

Bug #632655: O: conky -- highly configurable system monitor

[Aron Xu]

severity 632655 normal
retitle 632655 'O: conky -- highly configurable system monitor'
reassign 632655 wnpp
thanks

As stated in Bug #628997, #632653, #632654, #632655, the maintainer of
conky package is giving up all his packages in Debian, I hereby orphan
this package.

Package: conky
Priority: optional
Section: contrib/utils
Description: highly configurable system monitor (transitional package)
 Conky is a system monitor that can display just about anything, either
on your root desktop or
 in its own window. Conky has many built-in objects, as well as the
ability to execute external
 programs or scripts (either external or through built-in lua support).
Homepage: http://conky.sourceforge.net/



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1c7363.5050...@gmail.com

Bug #628997: O: gecko-mediaplayer -- Multimedia plug-in for Gecko browsers

[Aron Xu]

severity 628997 normal
retitle 628997 'O: gecko-mediaplayer -- Multimedia plug-in for Gecko
browsers'
reassign 628997 wnpp
thanks

As stated in Bug #628997, #632653, #632654, #632655, the maintainer of
gecko-mediaplayer package is giving up all his packages in Debian, I
hereby orphan this package.

The description of gecko-mediaplayer is:

Gecko Media Player is a browser plug-in that uses GNOME MPlayer and
Mplayer to play media in a browser. It uses the NS4 API and is therefore
compatible with all NS4 derived browsers: Iceweasel, Firefox, Iceape,
Epiphany, Galeon, Midbrowser, Xulrunner, etc.

It is the modern replacement for mplayerplug-in (from the same author).



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1c7166.2060...@gmail.com

Re: Whether should grub2 write MBR automatic

[Aron Xu]

On Wed, Jun 22, 2011 at 12:07, Ben Hutchings  wrote:
>
> 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?
>

grub-pc will write MBR every time when triggered, and grub-pc-bin will
not update grub entry after the kernel is updated. - It is weird when
you have grub installed to an alternative place, then you upgrade a
package and it write MBR regardless what you have chosen before. Write
MBR when it is being installed for the first time is the right way,
but it should not force user to write MBR when he has said no.




-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktim-7mbjpcwbpotp1engpf+9bbu...@mail.gmail.com

Re: Alioth status update, take 3

[Aron Xu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011年05月24日 15:17, Iain Lane wrote:
> 
> In addition to what has already been mentioned: doesn't look like ldap
> replication is working, so I can't use my shiny new DD account:
> [...]
>

Alioth does not use the official password database, so I don't think
directly connect to it would work. New DDs need to request a new
password for their Alioth account. (See Alioth FAQ[1] Section 1.4 & 1.5)

But this does not work either because the account syncing script might
be broken now. When requesting to reset the password, it gives an error
claiming the account does not exist.


[1]http://wiki.debian.org/Alioth/FAQ
- --
Regards,
Aron Xu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN22blAAoJEEmrPP2rYrC43GcIAK5OuZ7RGOCPQKcc/8nNsUgF
ily4wE1Xy0WYLEh1GnHyYRmqCc70MKQcZ3Tewt3h0Qnpjr43sBKzaoXMBDqGlqGK
yvVRADIQPM50pn5fx/h953ZQ4TzoPsJJWXnJZtQAhF63HDjDX42BAB3QcX5JEl6e
iLwsAZ2PJMPRQtmgM/6c2D6daBEC3XYVAAFxTF557uVMH1TaxwlgZuGJOCwGVwgo
GX8DocpAFd2iAbxFzM2rYHlSKLD358tigI2JvtqAGPLiWay2l9HaOV+nMmcne021
+apyH/HDmTST0GTlXAdInyZKey0zX1awtBMbCRXOv5pSYIvi9/Pn/SJqOy+2ihc=
=ZLrK
-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/4ddb66e6.90...@gmail.com

Re: Potential memory leaks reported by Valgrind against some frequently used commands

[Aron Xu]

On Tue, Mar 1, 2011 at 19:54, Olaf van der Spek  wrote:
> 2011/3/1 ximalaya :
>> I notice that, valgrind reports memory leaks against some frequently used
>> commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps
>> -ef, ls -latr, top, etc.
>
> For short-running processes that's generally not a problem.
> --
> Olaf
>

It would be good if we fix them, :)

-- 
Regards,
Aron Xu


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

Bug#613640: ITP: ucimf-chewing - chewing input method wrapper for ucimf

[Aron Xu]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: IME Packaging Team 

   Package name: ucimf-sunpinyin
  Version: 0.2
Upstream Author: Mat 
  URL: http://code.google.com/p/ucimf
 License: GPL
Description: chewing input method wrapper for ucimf

-- 
Regards,
Aron Xu



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

Bug#612045: ITP: ucimf-sunpinyin -- sunpinyin input method wrapper for ucimf

[Aron Xu]

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

   Package name: ucimf-sunpinyin
  Version: 0.2
Upstream Author: Mat 
  URL: http://code.google.com/p/ucimf
 License: GPL
Description: sunpinyin input method wrapper for ucimf

-- 
Regards,
Aron Xu



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=ckzmj5ztcgeymtmmjqm_zhudi-dkwh-r4a...@mail.gmail.com

Re: Bug #608185: btrfs-tools: balance tree action should be only triggered by root

[Aron Xu]

On Tue, Dec 28, 2010 at 21:53, Aron Xu  wrote:
> Package: btrfs-tools
> Version: 0.19+20100601-3, 0.19+20101101-1
> Severity: serious
>
> Balance tree action of btrfs command should be limited to only root
> user, because it may cause data corrupt and usually result in an
> uninterruptible process which is causing a heavy I/O load (the process
> may keep runing for a long time because the action is not a easy deal).
>
> Run the following command as a non-root user will also start the balance
> tree action ( / is btrfs here, with ext4 /boot):
> $ btrfs filesystem balance /
>
> I think this problem will cause serious issues if somebody uses it in
> a production system (though it is really not recommended), so I give it
> an RC severity. If you think it should be changed, feel free to do it.
>
> What's more, I'm not sure whether this should be a bug in the Linux kernel,
> because such action is actually performed by using system calls. If I
> try to make a snapshot in a directory by a user who does not have the
> access, it will generate an error like this:
> $ pwd
> /home
> $ whoami
> aron
> $ btrfs subvolume snapshot . backhome
> Create a snapshot of '.' in './backhome'
> ERROR: cannot snapshot '.'
>

CCing debian-devel.


-- 
Regards,
Aron Xu


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

Re: using perl in preinst script

[Aron Xu]

On Tue, Dec 28, 2010 at 00:32, Rahul Amaram
 wrote:
> Hi Neil,
> Thanks for the response. I didn't intend to work on this update as per my
> leisure. I greatly admire the Debian release team for the effort they put
> in, in trying to make Debian a great experience to the end users. As I've
> already told you, I am new and therefore didn't know of the deep-freeze of
> Squeeze. Or else I would have definitely worked on it earlier itself.
>
> Anyway, coming back to the solution. This is what I plan to do. Kindly
> provide any necessary feedback.
>
> 1. Stop the server in preinst and if necessary copy the current
> configuration file to a temporary location.
> 2. In postinst, write python code to check if NSS directory service is being
> used (by parsing the configuration file) and if so take the appropriate
> action. Once this is done, delete the temporary copy of configuration file.
>
> Also I believe for this, python needn't be added to Pre-Depends but only to
> Depends.
>

I still think adding python to Depends only because a maintainer
script needs it is costing too much, if the application itself doesn't
need python at all.

-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinvco8vf+ns3k1+6kbxgz2corze9arx4_ojc...@mail.gmail.com

Re: How to create a soft link with quilt

[Aron Xu]

On Mon, Nov 29, 2010 at 19:39, liang  wrote:
> Hi, All,
>
> When using 3.0 (quilt) format to package a debian package, I found it
> is impossible to keep soft link with quilt, This is my procedure:
>
> $ quilt new add-celt051-link-to-libcelt.patch
> Patch add-celt051-link-to-libcelt.patch is now on top
> $ quilt add celt051
> File celt051 added to patch add-celt051-link-to-libcelt.patch
> $ ln -s celt-0.5.1.3/libcelt celt051
> $ quilt refresh
> diff: celt051/null: No such file or directory
> Nothing in patch add-celt051-link-to-libcelt.patch
> $
>
> libcelt is a directory under celt-0.5.1.3, I want create a symbol link
> celt051 point to it.
>
> How can I achieve this result?
>
> Thanks and Reguards,
> --
> Liang Guo
> http://bluestone.cublog.cn
>
>

You may want to use a maintainer script to create/remove the link.


-- 
Regards,
Aron Xu


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

Re: Bug#605009: serious performance regression with ext4

[Aron Xu]

Low performance with Btrfs as well, :(

(Even Btrfs is not supported in squeeze, I think this could help on
digging whether it is a more generic problem than EXT4 only.)

-- 
Regards,
Aron Xu


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

Bug#604023: ITP: fcitx-sunpinyin - sunpinyin engine for fcitx

[Aron Xu]

Package: wnpp
Severity: wishlist
Reporter: IME Packaging Team 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: fcitx-sunpinyin
  Version : 0.1.1
* URL : http://code.google.com/p/fcitx
* License : GPL-3+
  Programming Lang: C++
  Description : sunpinyin engine for fcitx

-- 
Regards,
Aron Xu


signature.asc
Description: Digital signature

Bug#604022: ITP: fcitx-config - graphic fcitx configuration tool

[Aron Xu]

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

* Package name: fcitx-config
  Version : 0.1.3
* URL : http://code.google.com/p/fcitx
* License : GPL-3+
  Programming Lang: C
  Description : graphic fcitx configuration tool


-- 
Regards,
Aron Xu


signature.asc
Description: Digital signature

Bug#600901: ITP: ho22bus - English word reciting helper program

[Aron Xu]

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

 * Package name: ho22bus
   Version : 0.8.5
   Upstream Author : YunQiang Su 
 * URL : http://code.google.com/p/ho22bus/
 * Licenses: GPL-3
   Programming Lang: C/C++
   Description :
ho22bus is basicly a fork of the died reciteword project,
the name is a short form of honorificabilitudinitatibus,
which is a hard word for reciting.
.
This program has beautiful look with skin support, it could
be used to track to whole path of your reciting English words.

-- 
Regards,
Aron Xu


signature.asc
Description: Digital signature

Bug#598000: ITP: openfeiton - open source implemention of fetion protocol client

[Aron Xu]

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

 * Package name: openfetion
   Version : 1.9
   Upstream Author : levin108 
 * URL : http://basiccoder.com/openfetion
 * Licenses: GPL with OpenSSL exception
   Programming Lang: C
   Description :
openfetion is a fetion client for Linux based on GTK+2.0, using
Fetion  
Protocol Version 4.
. 
It supports most useful functions of China Mobile Fetion, more
important, it's small and fast, and is better in look.

-- 
Regards,
Aron Xu


signature.asc
Description: Digital signature

Bug#597396: ITP: pidgin-gmchess - pidgin integration with gmchess

[Aron Xu]

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

* Package name: pidgin-gmchess
  Version : 0.02
  Upstream Author : lerosua 
* URL : http://code.google.com/p/gmchess/
* Licenses: GPL
  Programming Lang: C
  Description :
pidgin-gmchess is a plugin for pidgin which provides
integration with gmchess.
.
It enables players of gmchess play Chinese chess
(Xiangqi) over the Internet with pidgin.

-- 
Regards,
Aron Xu


signature.asc
Description: Digital signature

Bug#585952: ITP: gnome-paint - simple, easy to use paint program for GNOME

[Aron Xu]

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

Package name: gnome-paint
Version: 0.3
Upstream Author: Rogério Ferro do Nascimento 
URL: http://code.google.com/p/gnome-paint/
License: GPL-3
Description: simple, easy to use paint program for GNOME



--
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/aanlktil7-e-rmncacrkixs-fmumrp85wgbezbi_4y...@mail.gmail.com

Bug#574256: ITP: pygccxml - specialized XML reader reads the output from gccxml

[Aron Xu]

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

Package name: pygccxml
Version: 1.0.0
Upstream Author: Roman Yakovenko 
URL: http://www.language-binding.net/pygccxml/pygccxml.html
License: Boost Software License - Version 1.0
 Permission is hereby granted, free of charge, to any person or organization
 obtaining a copy of the software and accompanying documentation covered by
 this license (the "Software") to use, reproduce, display, distribute,
 execute, and transmit the Software, and to prepare derivative works of the
 Software, and to permit third-parties to whom the Software is furnished to
 do so, all subject to the following:

 The copyright notices in the Software and this entire statement, including
 the above license grant, this restriction and the following disclaimer,
 must be included in all copies of the Software, in whole or in part, and
 all derivative works of the Software, unless such copies or derivative
 works are solely in the form of machine-executable object code generated by
 a source language processor.

 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
 SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
 FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
 ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 DEALINGS IN THE SOFTWARE.
Description: specialized XML reader reads the output from gccxml



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

Bug#570202: ITP: ucimf-openvanilla - openvanilla input method collection for ucimf

[Aron Xu]

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

Package name: ucimf-openvanilla
Version: 2.10.5
Upstream Author: Mat 
URL: http://code.google.com/p/ucimf
License: GPL
Description: openvanilla input method collection for ucimf



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

Bug#570200: ITP: openvanilla-modules - moudules of openvanilla input method

[Aron Xu]

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

Package name: openvanilla-modules
Version: 0.8.0.14
Upstream Author: Mat 
URL: http://code.google.com/p/ucimf
License: GPL
Description: moudules of openvanilla input method



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

Bug#567248: ITP: fbterm-ucimf -- input method interface for fbterm

[Aron Xu]

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

Package name: fbterm-ucimf
Version: 0.2.6
Upstream Author: Mat 
URL: http://code.google.com/p/ucimf
License: GPL
Description: input method interface for fbterm




signature.asc
Description: OpenPGP digital signature

Bug#567247: ITP: libucimf -- 2.2.9

[Aron Xu]

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

Package name: libucimf
Version:
Upstream Author: Mat 
URL: http://code.google.com/p/ucimf
License: GPL
Description: Unicode console input method framework
Provide an input method framework for unicode console use.



signature.asc
Description: OpenPGP digital signature

Bug#563368: ITP: gwrite -- GTK+ based simple HTML5 editor

[Aron Xu]

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

--- Please fill out the fields below. ---

   Package name: gwrite
Version: 0.1.1
Upstream Author: Jiahua Huang 
URL: http://code.google.com/p/gwrite/
License: LGPL v3+
Description: gWrite is a simple GTK+ HTML5 editor, the user
interface is similar to Wordpad. It aims to be lighter than OOWrite &
OOWeb, and to be as useful as them.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org