Re: Node.js and it's future in debian

[Russ Allbery]

Aníbal Monsalve Salazar  writes:
> On Fri, Apr 27, 2012 at 07:14:04PM -0700, Russ Allbery wrote:

>> In an ideal world, *neither* application would be using "node", since
>> it's a very generic name, but the reality is that people go off and do
>> things without paying attention to our naming policy and sometimes the
>> really popular ones get away with stomping on namespace just because
>> they're popular.

> Contrast that with the positive actitude of the NFS developers of CITI
> at UMichi when heimdal-dev and libgssapi-dev both contained
> /usr/lib/libgssapi.a [1]. They went to the trouble of renaming libgssapi
> to libgssglue.

Indeed, and I'm very grateful for that.  But realistically that was also a
lot easier than renaming Node.js's interpreter, and I think the CITI folks
did actually know that was coming.  The conflict had already been pointed
out in the Kerberos community and had been discussed prior to it coming up
here.  But more significantly that library was essentially used only by
NFS, so only a few clients had to change and the renaming was fairly
straightforward.

Node.js is at this point another matter; it's the topic of books,
widespread use independent of the upstream developers, and lots of
articles and Internet documentation with a life of its own.  A quick
Google search comes up with tons of indepedent sites telling people to run
programs with "node ".  That makes renaming a much more
difficult prospect.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqas35ag@windlord.stanford.edu

Re: Node.js and it's future in debian

[Aníbal Monsalve Salazar]

On Fri, Apr 27, 2012 at 07:14:04PM -0700, Russ Allbery wrote:
>Carl Fürstenberg  writes:
>
>>As I'm not a hamradio user, I'm off course biased towards letting
>>nodejs having the "node" binary and let it pass to testing. But we
>>must find a solution to this, as nodejs is getting more and more used,
>>and developers are forced to install nodejs from source to be able to
>>use it instead of install it via the package manager.
>
>This increasingly feels like the same situation as Git: yes, another
>utility was first, but the usage of one is a tiny fraction of the usage
>of the other, and people expecting to use a common package expect it to
>be available under that name and think poorly of Debian when it doesn't
>just work.
>
>In an ideal world, *neither* application would be using "node", since
>it's a very generic name, but the reality is that people go off and do
>things without paying attention to our naming policy and sometimes the
>really popular ones get away with stomping on namespace just because
>they're popular.

Contrast that with the positive actitude of the NFS developers of CITI
at UMichi when heimdal-dev and libgssapi-dev both contained
/usr/lib/libgssapi.a [1]. They went to the trouble of renaming libgssapi to
libgssglue.

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


-- 
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/20120428025806.ga7...@master.debian.org

MIA check: Jan Christoph Nordholz

[Dmitry Smirnov]

Dear all,

I'm looking for information regarding last known activity of 

   Jan Christoph Nordholz 

who appears to be totally inactive for over two years. (He is not a DD/DM and 
all his packages were sponsored). 

My particular concern is about 'autofs5' package which was NMU'ed twice since 
last maintainer update in August 2009.

I intend to adopt/take over the 'autofs5' package.

Petter, you sponsored last maintainer's upload back in 2009 - do you happen to 
hear from Jan lately?

Thanks.

All the best,
Dmitry.

P.S. Jan's packages overview page:
http://qa.debian.org/developer.php?login=he...@pool.math.tu-berlin.de


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

Re: Node.js and it's future in debian

[Russ Allbery]

Carl Fürstenberg  writes:

> As I'm not a hamradio user, I'm off course biased towards letting nodejs
> having the "node" binary and let it pass to testing. But we must find a
> solution to this, as nodejs is getting more and more used, and
> developers are forced to install nodejs from source to be able to use it
> instead of install it via the package manager.

This increasingly feels like the same situation as Git: yes, another
utility was first, but the usage of one is a tiny fraction of the usage of
the other, and people expecting to use a common package expect it to be
available under that name and think poorly of Debian when it doesn't just
work.

In an ideal world, *neither* application would be using "node", since it's
a very generic name, but the reality is that people go off and do things
without paying attention to our naming policy and sometimes the really
popular ones get away with stomping on namespace just because they're
popular.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehr87gcz@windlord.stanford.edu

Node.js and it's future in debian

[Carl Fürstenberg]

Hello,

There has been an log struggle between the nodejs package and the node
package, which is still unresolved (bug #611698 for example) And I
wonder now what the future should look like.

To summarize the problem:
* the nodejs upstream binary is called "node", and the upstream
developers have refused to change it's binary name to nodejs for
debian;
* The the hamradio package "node" shipping a binary called "node", and
as it's so old, the developers argue that the package must ship a
binary called "node" or breakage will occur.
* The reason the nodejs developers want to ship the binary as "node"
is because all programs written for nodejs all has /usr/bin/node in
it's shebang
* the nodejs package are not allowed to conflict on the node package
just because the binary name is the same

As I'm not a hamradio user, I'm off course biased towards letting
nodejs having the "node" binary and let it pass to testing. But we
must find a solution to this, as nodejs is getting more and more used,
and developers are forced to install nodejs from source to be able to
use it instead of install it via the package manager.

Regards,

Carl Fürstenberg


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

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO Vers la  fin de l'après-midi du vendredi 27  avril 2012, vers 16:29,
Svante Signell  disait :

> Apparently it can today ... with init scripts, which _new_ features will
> be brought in for the _boot_ process. udev takes care of the events,
> already today, right? More secure boot, faster boot (coreboot), better
> debugging, simple ways of logging the boot massages, etc? Don't talk
> about plug-and-p{r}ay, that is not interesting for _boot_: Found new
> hardware, eh?

But that's the whole point : new hardware pops up while booting. See for
example a server that will need  a 3G connection. The 3G connection will
be done  by some  classic USB key.  When the  USB key is  detected, udev
triggers a script  asking the USB key (which defaults  to a mass storage
device) to  switch to  "modem mode".   Once it becomes  a modem,  the 3G
connection  can be initialized.   Turning the  USB key  into a  modem is
taking   some  time.   The   USB  key   will  be   "disconnected",  then
"reconnected". SO, "found new  hardware".  ifupdown scripts were already
run and filed with "interface not found".

udev can run simple actions when a device appears but cannot run a chain
of dependencies  (start the  3G connection, run  some daemon  that needs
Internet  which in  turn  will trigger  some  client to  this daemon  to
run). The solution is an event-based init. We want a reliable boot.

We are in 2012 and if a non-essential daemon blocks the boot (no working
network), we have no way to get a getty to be run.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


pgpzoo4HbRtjy.pgp
Description: PGP signature

Re: devotee (debian vote engine): predictable RNG allows recovery of secret monikers

[Henrique de Moraes Holschuh]

On Thu, 26 Apr 2012, Timo Weingärtner wrote:
> 2012-04-26, 23:23:54 Timo Juhani wrote:
> > Raphael Geissert  writes:
> > > print hmac_sha1_hex($v, $m);
> > 
> > Yeah that sounds promising. Now we just need to fix the code that tries
> > to randomize the order of entries in the tally.
> 
> Is that randomization really needed? Why not just sort based on the hashes?

Please just short he HMAC output, you won't leak any more data that way,
and it actually makes the output more usable...

Also, unless there is a strong reason not to, please consider using
hmac_sha256_hex().

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120427225009.ga17...@khazad-dum.debian.net

Re: libbitcoin

[Fernando Lemos]

Hi,

On Fri, Apr 27, 2012 at 2:36 PM, Amir Taaki  wrote:
> Anyway, sorry if this sounds presumptious but if anyone can make a package 
> then contact me and I'll collaborate and make whatever changes are needed to 
> get it to work with Debian. I did make an effort before asking for help, but 
> I'm mostly familiar with upstream processes.

Please refrain from posting requests or announcements like this to
debian-devel in the future.

We have a process for requesting software to be packaged for Debian
(RFPs), please read the following:

http://www.debian.org/devel/wnpp/

Regards,


--
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/canvyna_4jonwq5ghiytak5d66-8yuuhj2-sojpdw86lwypr...@mail.gmail.com

Re: libbitcoin

[Amir Taaki]

> Interesting!

> 
> Is it related to libcoin? https://github.com/ceptacle/libcoin

Nope. libcoin is a fairly recent new project. libbitcoin is older.

> Does it (unlike Bitcoin) work on bigendian architectures?

Yes it works on big-endian architectures. Also Bitcoin is MIT licensed, whereas 
this is GPL.

> I can help you, but am already involved in way too many packages[1] so 
> would prefer that you (or others) stay in the loop and participate in 
> the ongoing maintainance of the packaging.

I'd be willing to help engage and maintain the package, and work with the 
author of the package. I've got to make the software accessible to developers 
(as it is a library) so I'll do my best to help the Debian developers.

> Are you also considering packaging some of those projects that use this 
> library?

Yes, eventually. I really like this project Electrum: 
http://ecdsa.org/electrum/ - I think it has massive potential in the future. 
Compared to other Bitcoin clients, there is no blockchain download and yet it 
remains secure. So it fixes the biggest usability problems existing currently 
with Bitcoin. However to get these projects working, the first step is to get 
their core dependencies out there. Electrum has mainstream appeal.

Another cool project using libbitcoin is subvertx which is a handy set of 
command line tools for working with Bitcoin. The ImageMagick of Bitcoin. Things 
like create private keys, download the blockchain into an SQL database, 
construct transactions and dump them offline to stdout, read from pipe and send 
raw transaction dump to network, examine private keys for addresses, check 
balances against the blockchain, ... .etc all these low level advanced 
commands. However it's not a priority since the usage is pretty niche, but I 
have a personal bias for anything command line :)

First step: libbitcoin.


-- 
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/1335554978.18213.yahoomail...@web121001.mail.ne1.yahoo.com

Re: libbitcoin

[Jonas Smedegaard]

On 12-04-27 at 10:36am, Amir Taaki wrote:
> I have a project which I've been continuously working on for 1 year 
> now since May 2011 ( http://gitorious.org/libbitcoin?page=17 ). It is 
> used in a number of projects like Electrum ( 
> http://ecdsa.org/electrum/ ) or as backend software for websites ( 
> https://intersango.com/ ). Intersango is the largest exchange in the 
> UK, and 2nd largest worldwide so libbitcoin is being used in a 
> production environment.
> 
> 
> It is a C++ Bitcoin library (rewrote from scratch) with an 
> asynchronous toolkit based design. It has Python bindings and is at 
> its 1.0 release.
> Website: http://libbitcoin.org/
> Documentation/tutorials: http://libbitcoin.org/doc.html
> There are packages for Gentoo and Parabola/ArchLinux.
> 
> 
> I made a simple Ubuntu package: http://gitorious.org/libbitcoin/distpkg
> I then have been trying to create a Debian package to get it into the 
> repos, however the entire process for creating shared library packages 
> is immensely complex going by these guides:
> http://www.debian.org/doc/manuals/maint-guide/
> 
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> 
> Anyway, sorry if this sounds presumptious but if anyone can make a 
> package then contact me and I'll collaborate and make whatever changes 
> are needed to get it to work with Debian. I did make an effort before 
> asking for help, but I'm mostly familiar with upstream processes.
> The license is AGPL with a lesser clause (I worked with Stallman and 
> Aaron Williamson of the SFLC to create this license).

Interesting!

Is it related to libcoin? https://github.com/ceptacle/libcoin

Does it (unlike Bitcoin) work on bigendian architectures?


I can help you, but am already involved in way too many packages[1] so 
would prefer that you (or others) stay in the loop and participate in 
the ongoing maintainance of the packaging.

Are you also considering packaging some of those projects that use this 
library?


 - Jonas

[1] http://qa.debian.org/developer.php?login=d...@jones.dk&comaint=yes

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: thttpd

[Gunnar Wolf]

Russ Allbery dijo [Thu, Apr 26, 2012 at 09:06:36AM -0700]:
> nginx seems to be the one everyone is using these days, but there are tons
> of web servers in Debian.
> 
> grep-aptavail -F Provides -s Package,Description httpd
> 
> returns aolserver4-daemon, boa, bozohttpd, cherokee, lighttpd, mathopd,
> micro-httpd, mini-httpd, monkey, webfs, and yaws in addition to nginx (and
> of course Apache), as well as some other stuff that looks more
> specialized.

Now that this has been brought to the d-devel attention: I have been
so far the Cherokee maintainer. Sadly, I sent out a RFA in November,
and filed a removal request a couple of days ago.

Cherokee is a very lean, very agile webserver, with a great helper for
managing configuration in a user-friendly way. I would not like to see
it be dropped from Debian, but cannot devote time to maintaining it
anymore.

So, this message goes as a final help call: If you are interested in
picking up Cherokee and maintaining it, I'll be most delighted to
explain some of its bits.

Greetings,


signature.asc
Description: Digital signature

libbitcoin

[Amir Taaki]

Hi,

I have a project which I've been continuously working on for 1 year now since 
May 2011 ( http://gitorious.org/libbitcoin?page=17 ). It is used in a number of 
projects like Electrum ( http://ecdsa.org/electrum/ ) or as backend software 
for websites ( https://intersango.com/ ). Intersango is the largest exchange in 
the UK, and 2nd largest worldwide so libbitcoin is being used in a production 
environment.


It is a C++ Bitcoin library (rewrote from scratch) with an asynchronous toolkit 
based design. It has Python bindings and is at its 1.0 release.
Website: http://libbitcoin.org/
Documentation/tutorials: http://libbitcoin.org/doc.html
There are packages for Gentoo and Parabola/ArchLinux.


I made a simple Ubuntu package: http://gitorious.org/libbitcoin/distpkg
I then have been trying to create a Debian package to get it into the repos, 
however the entire process for creating shared library packages is immensely 
complex going by these guides:
http://www.debian.org/doc/manuals/maint-guide/

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Anyway, sorry if this sounds presumptious but if anyone can make a package then 
contact me and I'll collaborate and make whatever changes are needed to get it 
to work with Debian. I did make an effort before asking for help, but I'm 
mostly familiar with upstream processes.


---

Install instructions
---


There is nothing unusual or funny 
about the setup. It is just a normal autotools build system with no 
special modifications or hacks.

 $ sudo apt-get install build-essential autoconf libtool libboost1.48-all-dev 
libdb++-dev libprotobuf-dev libcurl4-openssl-dev git
 $ git clone git://gitorious.org/libbitcoin/libbitcoin.git
 $ cd libbitcoin
 $ autoreconf -i
 $ ./configure --enable-bdb
 $ make
 $ sudo make install
A pkg-config is provided:

$ pkg-config --cflags --libs libbitcoin
-std=gnu++0x -DBDB_ENABLED -I/home/genjix/usr/include  -L/home/genjix/usr/lib 
-lbitcoin -lboost_thread -lboost_system -lboost_regex -lboost_filesystem 
-lpthread -lprotobuf -ldb_cxx -lcurl


The license is AGPL with a lesser clause (I worked with Stallman and Aaron 
Williamson of the SFLC to create this license).



--
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/1335548172.33536.yahoomail...@web121004.mail.ne1.yahoo.com

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Martin Wuertele 

> * Josselin Mouette  [2012-04-27 09:53]:
> 
> > Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
> > > > Yes of course, because event-driven init systems have *always* been
> > > > *only* about mounting USB devices. 
> > > 
> > > Then explain the _real_ reasons for having an event driven boot system!
> > 
> > BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
> 
> That's a reason for udev/mdev, however I still fail to see why this
> results in the requirement for an event based boot process. 

A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
mounted and /srv/somewhere comes off iscsi, which means it requires
networking to be up, which means network drivers loaded, etc.  So the
event «network driver loaded» causes ifup to be spawned, which causes
$network to be satisfied which causes the iscsi daemons to be started
which causes mount to be called.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87haw584g9@qurzaw.varnish-software.com

Re: RFC: OpenRC as Init System for Debian

[Chris Knadle]

On Friday, April 27, 2012 03:54:51, Roger Leigh wrote:
> On Fri, Apr 27, 2012 at 05:18:35AM +0200, Michael Biebl wrote:
> > This is getting OT and a better question for debian-user, so this will
> > be my last post regarding this issue.
> > 
> > On 27.04.2012 04:34, Chris Knadle wrote:
> > > AFAICT I really want the 'quiet' linux command line parameter, and to
> > > reconfigure the console output of systemd somehow.
> > 
> > man 1 systemd :
> > 
> > Try adding "systemd.show_status=true systemd.sysv_console=true" to your
> > kernel command line. This is basically having the same effect for
> > systemd as removing the "quiet" kernel command line option.
> 
> Is this the default?

?  I'm having trouble figuring out what it would mean if I answered "no".

> Or do we need an additional "silent" option so that systemd can behave
> similarly to the existing stuff when passed the "quiet" option?
> 
> Roger

I don't think a 'silent' option is required.



Grub defaults to passing 'quiet' to the kernel, and no systemd options.  
Installing the systemd package does not change the options passed to the 
kernel, and AFAIK cannot for Policy reasons.

When the 'quiet' option is passed to the kernel, systemd picks this up and 
sets systemd.show_status=false and systemd.sysv_console=false.  [The default 
for both of these is 'true' if the 'quiet' option is not present.]  The result 
is that no daemon startup messages are sent to the console during bootup when 
the 'quiet' option is used, unless these settings are chagned via passing the 
additional kernel boot options described in the previous email above *after* 
the 'quiet' option.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

Re: RFC: OpenRC as Init System for Debian

[Svante Signell]

On Fri, 2012-04-27 at 16:29 +0200, Svante Signell wrote:
> On Fri, 2012-04-27 at 09:54 +0200, Josselin Mouette wrote:

> > > And why is udev classified as important, what's the use of that on
> > > servers?
> > 
> > Because Linux, in its current architecture, won’t work correctly without
> > it.

To clarify: The text below is written with the assumption that udev is
used, but with init scripts used for boot.

> Apparently it can today ... with init scripts, which _new_ features will
> be brought in for the _boot_ process. udev takes care of the events,
> already today, right? More secure boot, faster boot (coreboot), better
> debugging, simple ways of logging the boot massages, etc? Don't talk
> about plug-and-p{r}ay, that is not interesting for _boot_: Found new
> hardware, eh?
> 
> BTW: When boots is asynchronous, who is sorting the boot messages to be
> readable afterwords, or is this taken care of by the now so famous tools
> systemd and upstart. 
> 
> Yes, next step will to install these packages and do some evaluation
> comparison, nobody has done that yet, or?

It might be so that Linux does not work properly without udev/mdev, what
a pity for people who don't want it.


-- 
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/1335537347.1152.251.ca...@s1499.it.kth.se

Re: RFC: OpenRC as Init System for Debian

[Svante Signell]

On Fri, 2012-04-27 at 09:54 +0200, Josselin Mouette wrote:
> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
...
> This must have been explained HUNDREDS of times in the endless threads
> full of stupid messages from stupid dumbasses who don’t understand a
> thing about init systems but don’t want their precious, idiotic, buggy
> init scripts to go away.

Please calm down, and refrain from calling people names, that is not
polite!

> > Finding new hardware for example can be related to software like hwdata.
> > And why is udev classified as important, what's the use of that on
> > servers?
> 
> Because Linux, in its current architecture, won’t work correctly without
> it.

Apparently it can today ... with init scripts, which _new_ features will
be brought in for the _boot_ process. udev takes care of the events,
already today, right? More secure boot, faster boot (coreboot), better
debugging, simple ways of logging the boot massages, etc? Don't talk
about plug-and-p{r}ay, that is not interesting for _boot_: Found new
hardware, eh?

BTW: When boots is asynchronous, who is sorting the boot messages to be
readable afterwords, or is this taken care of by the now so famous tools
systemd and upstart. 

Yes, next step will to install these packages and do some evaluation
comparison, nobody has done that yet, or?


-- 
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/1335536942.1152.247.ca...@s1499.it.kth.se

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 architectures, do we really want to hard code which
architecture to depend on which package manually?

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.

-- 
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://list

Re: Bug#670603: ITP: php-mdb2 -- a merge of the PEAR DB and Metabase php database abstraction layers

[Thomas Goirand]

On 04/27/2012 06:52 PM, Philipp Kern wrote:
> On Fri, Apr 27, 2012 at 04:44:24PM +0800, Thomas Goirand wrote:
>> * Package name: php-mdb2
>>   Version : 2.5.0b3
> 
> php-mdb2 is already in Debian.

I know.

>> This is a request from people packaging "ownCloud".
> 
> So why do they need to request this?

Because of a miss-communication. They didn't, they did request for
MDB2_Schema, and I thought they also requested MDB2.

It's a bit too late, I've uploaded a new version, but it doesn't mater
much, as:
- The package is team maintained anyway, so old maintainers, who by the
way didn't work on the package since 2009, already agreed by saying they
want to do team maintenance.
- The package was outdated and should have been using pkg-php-tools

So I'm sorry for what I did, (in fact, I thought that I checked on it,
like I did for MDB2_Schema, but it seems I didn't... :/) but the result
isn't that bad (there's only a loss of the changelog, which I will
recover and rewrite correctly).

Thomas


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

Re: thttpd

[Oleg]

On Fri, Apr 27, 2012 at 03:08:44PM +0400, Michael Tokarev wrote:
> On 27.04.2012 14:49, Oleg wrote:
> > On Fri, Apr 27, 2012 at 01:34:52PM +0400, Michael Tokarev wrote:
> 
> >> Heck.  Thank you for reminder.  I was looking at something to
> >> replace bozohttpd I use (because it is just too buggy), but
> > 
> >   What bugs does it have?
> 
> $ dmesg | grep bozo
> bozohttpd[11878]: segfault at 0 ip 0804ec82 sp bfb42080 error 4 in 
> bozohttpd[8048000+e000]
> bozohttpd[4060]: segfault at 0 ip 0804ec82 sp bfb0ccb0 error 4 in 
> bozohttpd[8048000+e000]
> bozohttpd[32687]: segfault at 0 ip 0804ec82 sp bff0bed0 error 4 in 
> bozohttpd[8048000+e000]
> bozohttpd[32744]: segfault at 0 ip 0804ec82 sp bff5a470 error 4 in 
> bozohttpd[8048000+e000]
> bozohttpd[32745]: segfault at 0 ip 0804ec82 sp bfdc1f70 error 4 in 
> bozohttpd[8048000+e000]
> bozohttpd[388]: segfault at 0 ip 0804ec82 sp bfded6b0 error 4 in 
> bozohttpd[8048000+e000]
> bozohttpd[409]: segfault at 0 ip 0804ec82 sp bfa359c0 error 4
> bozohttpd[411]: segfault at 0 ip 0804ec82 sp bfaff4e0 error 4 in 
> bozohttpd[8048000+e000]
> bozohttpd[412]: segfault at 0 ip 0804ec82 sp bfbde780 error 4 in 
> bozohttpd[8048000+e000]

  Wow. This is seriously. I think i will not use it :-).


-- 
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/20120427113419.GA1858@localhost

[MailServer Notification]Content Filtering Notification

[Administrator]

This email has violated the DATA LEAKAGE PREVENTION (UK).
and Quarantine entire message has been taken on 4/27/2012 2:09:29 PM.
Message details:
Server: HEMATIT
Sender: patr...@gentoo.org;
Recipient: debian-devel@lists.debian.org;
Subject: Re: RFC: OpenRC as Init System for Debian 


-- 
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/3584a09e94b540519c4a4b055f07e...@dpt.gov.tr

[MailServer Notification]Content Filtering Notification

[Administrator]

This email has violated the DATA LEAKAGE PREVENTION (UK).
and Quarantine entire message has been taken on 4/27/2012 2:01:40 PM.
Message details:
Server: HEMATIT
Sender: m...@debian.org;
Recipient: debian-devel@lists.debian.org;
Subject: Re: RFC: OpenRC as Init System for Debian 


-- 
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/fb13add3712b4bc08024164519138...@dpt.gov.tr

Re: RFC: OpenRC as Init System for Debian

[Jon Dowland]

On Fri, Apr 27, 2012 at 12:12:00PM +1000, Russell Coker wrote:
> Fortunately udev allows us to assign static names for Ethernet devices.  This 
> means that if you have an existing eth0 which is being used and then add 
> another Ethernet card you don't have eth0 become eth1 and then deny logins 
> (which is annoying for a server without a monitor).  It also means that if 
> the 
> hardware that provides eth0 dies you don't have eth1 become eth0 and then 
> have 
> no match of interface and IP address to allow logins.

Also, I'm fairly sure udev does this by default in Debian, so the first
interface to get eth0 (identified by MAC address) gets eth0 afterwards, no
matter what order things come up.


-- 
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/20120427111717.GB16137@debian

Re: RFC: OpenRC as Init System for Debian

[Patrick Lauer]

On 04/27/12 18:50, Martin Wuertele wrote:
> * Josselin Mouette  [2012-04-27 09:53]:
> 
>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
 Yes of course, because event-driven init systems have *always* been
 *only* about mounting USB devices. 
>>>
>>> Then explain the _real_ reasons for having an event driven boot system!
>>
>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
> 
> That's a reason for udev/mdev, however I still fail to see why this
> results in the requirement for an event based boot process. 

Especially as your device manager can trigger services, so you already
have the mechanism for an event-driven system, what's missing then is
only policy ...

> 
> Could you enlighten me please.
> 
> Kind regards,
> Martin
> 
> 


-- 
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/4f9a7e1f.8060...@gentoo.org

Re: thttpd

[Michael Tokarev]

On 27.04.2012 14:49, Oleg wrote:
> On Fri, Apr 27, 2012 at 01:34:52PM +0400, Michael Tokarev wrote:

>> Heck.  Thank you for reminder.  I was looking at something to
>> replace bozohttpd I use (because it is just too buggy), but
> 
>   What bugs does it have?

$ dmesg | grep bozo
bozohttpd[11878]: segfault at 0 ip 0804ec82 sp bfb42080 error 4 in 
bozohttpd[8048000+e000]
bozohttpd[4060]: segfault at 0 ip 0804ec82 sp bfb0ccb0 error 4 in 
bozohttpd[8048000+e000]
bozohttpd[32687]: segfault at 0 ip 0804ec82 sp bff0bed0 error 4 in 
bozohttpd[8048000+e000]
bozohttpd[32744]: segfault at 0 ip 0804ec82 sp bff5a470 error 4 in 
bozohttpd[8048000+e000]
bozohttpd[32745]: segfault at 0 ip 0804ec82 sp bfdc1f70 error 4 in 
bozohttpd[8048000+e000]
bozohttpd[388]: segfault at 0 ip 0804ec82 sp bfded6b0 error 4 in 
bozohttpd[8048000+e000]
bozohttpd[409]: segfault at 0 ip 0804ec82 sp bfa359c0 error 4
bozohttpd[411]: segfault at 0 ip 0804ec82 sp bfaff4e0 error 4 in 
bozohttpd[8048000+e000]
bozohttpd[412]: segfault at 0 ip 0804ec82 sp bfbde780 error 4 in 
bozohttpd[8048000+e000]
...



-- 
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/4f9a7e3c.4040...@msgid.tls.msk.ru

Re: RFC: OpenRC as Init System for Debian

[Martin Wuertele]

* Josselin Mouette  [2012-04-27 09:53]:

> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
> > > Yes of course, because event-driven init systems have *always* been
> > > *only* about mounting USB devices. 
> > 
> > Then explain the _real_ reasons for having an event driven boot system!
> 
> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.

That's a reason for udev/mdev, however I still fail to see why this
results in the requirement for an event based boot process. 

Could you enlighten me please.

Kind regards,
Martin


--
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/20120427105045.gm31...@anguilla.debian.or.at

Re: thttpd

[Oleg]

On Fri, Apr 27, 2012 at 01:34:52PM +0400, Michael Tokarev wrote:
> On 27.04.2012 00:17, Chow Loong Jin wrote:
> > On 27/04/2012 02:59, Oleg wrote:
> >>   Yes, i'm searching a tiny httpd for an embedded system with cgi support 
> >> and
> >> possibly with http basic authentication support.
> >>   Thank you. I didn't know about busybox httpd.
> > 
> > No problem. busybox httpd supports CGI (just throw scripts into cgi-bin), 
> > but it
> > looks like Debian's busybox isn't built with CGI support. You could probably
> > file a bug for this. I submitted a patch to Ubuntu to enable it early last 
> > year.
> > HTTP basic authentication is also supported by busybox.
> 
> Heck.  Thank you for reminder.  I was looking at something to
> replace bozohttpd I use (because it is just too buggy), but

  What bugs does it have?


-- 
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/20120427104903.GB11872@localhost

Re: wine-unstable in Debian

[Philipp Kern]

On Fri, Apr 27, 2012 at 10:44:08AM +0200, Stefano Zacchiroli wrote:
> Right. Although we should be clear on what should happen with the
> patches in the BTS. Otherwise people wouldn't know how (and if) they can
> help, and that uncertainty would be a shame. Is the issue with the
> binNMUs a reason not to apply, possibly via NMUs, the patches Goswin has
> mentioned in his reply to my other message in this thread?

No, of course not.  But it then shifts the burden on other people to provide an
installable ia32-libs for wheezy.  That's all I'm saying.

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp KernDebian Developer
: :' :  http://philkern.de Stable Release Manager
`. `'   xmpp:p...@0x539.de Wanna-Build Admin
  `-finger pkern/k...@db.debian.org


signature.asc
Description: Digital signature

Re: Bug#670603: ITP: php-mdb2 -- a merge of the PEAR DB and Metabase php database abstraction layers

[Philipp Kern]

On Fri, Apr 27, 2012 at 04:44:24PM +0800, Thomas Goirand wrote:
> * Package name: php-mdb2
>   Version : 2.5.0b3

php-mdb2 is already in Debian.

> This is a request from people packaging "ownCloud".

So why do they need to request this?

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp KernDebian Developer
: :' :  http://philkern.de Stable Release Manager
`. `'   xmpp:p...@0x539.de Wanna-Build Admin
  `-finger pkern/k...@db.debian.org


signature.asc
Description: Digital signature

Re: thttpd

[Oleg]

On Fri, Apr 27, 2012 at 03:46:06PM +0800, Paul Wise wrote:
> 2012/4/27 Oleg :
> 
> >  No, i'm writing cgi with C for performance reasons and i wonder why
> > http://sourceforge.net/projects/libctemplate/ is not in debian repository
> > yet :-).
> 
> http://packages.debian.org/search?keywords=libctemplate

  This is not the same. libctemplate from sf.net inspired by perl
HTML::Template module and follow it syntax and so on.


-- 
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/20120427104349.GA11872@localhost

Re: wine-unstable in Debian

[Simon McVittie]

On 27/04/12 09:38, Goswin von Brederlow wrote:
> Steve Langasek filed patches
> for all the packages Ubuntu needed as multiarch. Look for the patches in:
> 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=multiarch-de...@lists.alioth.debian.org;tag=multiarch

It seems that the multiarch tag has not been applied completely
consistently; those bugs include some which are about the "first wave"
of multiarch (co-installable shared libraries, e.g. #637576), but also
some which are about multiarch -dev packages (#666760, #648621).

If the Ubuntu MultiarchSpec is to be believed, -dev packages are
explicitly out-of-scope for the first wave of multiarch; but there's
also been considerable interest in multiarch -dev packages too, mainly
from ARM/Linaro people.

I think it would be useful to separate the two, and prioritize the first.

S


-- 
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/4f9a77f5.9000...@debian.org

Re: Plans to (re-)include cgroups in wheezy?

[Michael Hanke]

On Thu, Apr 26, 2012 at 04:28:03PM -0400, Jon Bernard wrote:
> If Condor is still reasonably usable without support for cgroups via 
> libcgroup,
> I would go that route -- at least in the short term.  Several of libcgroup's
> problems are fairly complex, I'm doing all that I can given the time that I 
> have
> to get things sorted.  If anyone has input or would like to contribute, please
> do so.  I'm more that willing to collaborate.

Yes, Condor is functional without cgroups. It just can't use cgroups
anymore. I'll drop this dependency temporarily, and reenable it whenever
the dust has settled.

If you can offer a list of things that need to be done in order to get
cgroups back into wheezy, I might be able to identify some aspects that
I could help with -- even without any practical cgroups experience so
far.


Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
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/20120427103047.GB8529@meiner

Bug#670611: ITP: php-xml-dtd -- parsing of DTD files and DTD validation of XML files

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: php-xml-dtd
  Version : 0.5.2
  Upstream Author : Tomas V.V.Cox , Igor Feghali 

* URL : http://pear.php.net/package/XML_DTD
* License : BSD
  Programming Lang: PHP
  Description : parsing of DTD files and DTD validation of XML files

Parsing of DTD files and DTD validation of XML files.
The XML validation is done with the php sax parser, the xml extension, it
does not use the domxml extension.

Currently supports most of the current XML spec, including entities,
elements and attributes. Some uncommon parts of the spec may still be
unsupported.

This is a dependency of php-mdb2-schema, itself needed by OwnCloud.



-- 
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/20120427101737.7444.67069.report...@buzig.gplhost.com

Re: thttpd

[Michael Tokarev]

On 27.04.2012 00:17, Chow Loong Jin wrote:
> On 27/04/2012 02:59, Oleg wrote:
>>   Yes, i'm searching a tiny httpd for an embedded system with cgi support and
>> possibly with http basic authentication support.
>>   Thank you. I didn't know about busybox httpd.
> 
> No problem. busybox httpd supports CGI (just throw scripts into cgi-bin), but 
> it
> looks like Debian's busybox isn't built with CGI support. You could probably
> file a bug for this. I submitted a patch to Ubuntu to enable it early last 
> year.
> HTTP basic authentication is also supported by busybox.

Heck.  Thank you for reminder.  I was looking at something to
replace bozohttpd I use (because it is just too buggy), but
I forgot about busybox, which I maintain these days! :)
And it has exactly things I need - simple, inetd mode and
trivial cgi-bin support.

And indeed, there are a few bugreports against busybox about
missing httpd features which I'd like to address.

/me goes off to enable some stuff in busybox...


-- 
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/4f9a683c.1080...@msgid.tls.msk.ru

Bug#670605: RFP: libjs-jquery-jqplot -- jQuery Plotting Plugin

[Roman V. Nikolaev]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-javascript-de...@lists.alioth.debian.org

   Package name: libjs-jquery-jqplot
Version: 1.0.0b2_r1012
Upstream Author: Chris Leonello 
URL: http://www.jqplot.com
License: GPL, MIT
Description: jQuery Plotting Plugin
jqPlot is a plotting and charting plugin for the jQuery Javascript framework.
jqPlot produces beautiful line, bar and pie charts with many features:
Numerous chart style options.
Date axes with customizable formatting.
Up to 9 Y axes.
Rotated axis text.
Automatic trend line computation.
Tooltips and data point highlighting.
Sensible defaults for ease of use.


-- 

 Roman V. Nikolaev

mail:rshadowa...@gmail.com
jabber:  rsha...@jabber.org
icq: 198-364-657
site:http://www.rshadow.ru



-- 
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/4f9a5db0.6090...@gmail.com

Bug#670604: ITP: php-mdb2-schema -- enables users to maintain RDBMS independant schema

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: php-mdb2-schema
  Version : 0.8.5
  Upstream Author : Lukas Smith 
* URL : http://pear.php.net/package/MDB2_Schema
* License : BSD
  Programming Lang: PHP
  Description : enables users to maintain RDBMS independant schema

PEAR::MDB2_Schema enables users to maintain RDBMS independant schema
files in XML that can be used to create, alter and drop database entities
and insert data into a database. Reverse engineering database schemas from
existing databases is also supported. The format is compatible with both
PEAR::MDB and Metabase.

This is a RFP from the people packaging "ownCloud" and who needs that
dependency.



-- 
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/20120427084728.4879.70599.report...@buzig.gplhost.com

Bug#670603: ITP: php-mdb2 -- a merge of the PEAR DB and Metabase php database abstraction layers

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: php-mdb2
  Version : 2.5.0b3
  Upstream Author : Lukas Smith 
* URL : http://pear.php.net/package/MDB2
* License : BSD
  Programming Lang: PHP
  Description : a merge of the PEAR DB and Metabase php database 
abstraction layers

Provides a common API for all supported RDBMS. The main difference to most
other DB abstraction packages is that MDB2 goes much further to ensure
portability. MDB2 provides most of its many features optionally that
can be used to construct portable SQL statements:
* Object-Oriented API
* A DSN (data source name) or array format for specifying database servers
* Datatype abstraction and on demand datatype conversion
* Various optional fetch modes to fix portability issues
* Portable error codes
* Sequential and non sequential row fetching as well as bulk fetching
* Ability to make buffered and unbuffered queries
* Ordered array and associative array for the fetched rows
* Prepare/execute (bind) named and unnamed placeholder emulation
* Sequence/autoincrement emulation
* Replace emulation
* Limited sub select emulation
* Row limit emulation
* Transactions/savepoint support
* Large Object support
* Index/Unique Key/Primary Key support
* Pattern matching abstraction
* Module framework to load advanced functionality on demand
* Ability to read the information schema
* RDBMS management methods (creating, dropping, altering)
* Reverse engineering schemas from an existing database
* SQL function call abstraction
* Full integration into the PEAR Framework
* PHPDoc API documentation

This is a request from people packaging "ownCloud".



-- 
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/20120427084424.4788.57059.report...@buzig.gplhost.com

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

[Goswin von Brederlow]

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.

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


-- 
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/87d36ta7ff.fsf@frosties.localnet

Re: wine-unstable in Debian

[Stefano Zacchiroli]

On Fri, Apr 27, 2012 at 10:28:04AM +0200, Philipp Kern wrote:
> > And yes, that is not yet ready so any people pitching in and getting a
> > library package multiarchified will help. The patches are in the BTS,
> > they just need to be applied.
> 
> Except that we still have problems with essential tools like binNMUs.  
> Problems
> Ubuntu didn't have when converting their ia32-libs.

Right. Although we should be clear on what should happen with the
patches in the BTS. Otherwise people wouldn't know how (and if) they can
help, and that uncertainty would be a shame. Is the issue with the
binNMUs a reason not to apply, possibly via NMUs, the patches Goswin has
mentioned in his reply to my other message in this thread?

Thanks for clarifying,
Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: wine-unstable in Debian

[Philipp Kern]

On Fri, Apr 27, 2012 at 12:41:58AM +0200, Goswin von Brederlow wrote:
> The plan for wheezy is that ia32-libs goes away. At least that it will
> be just a transitional package that depends on the :i386 packages.
> 
> And yes, that is not yet ready so any people pitching in and getting a
> library package multiarchified will help. The patches are in the BTS,
> they just need to be applied.

Except that we still have problems with essential tools like binNMUs.  Problems
Ubuntu didn't have when converting their ia32-libs.

Kind regards
Philipp Kern 


signature.asc
Description: Digital signature

Re: wine-unstable in Debian

[Goswin von Brederlow]

Stefano Zacchiroli  writes:

> On Fri, Apr 27, 2012 at 12:41:58AM +0200, Goswin von Brederlow wrote:
>> The plan for wheezy is that ia32-libs goes away. At least that it will
>> be just a transitional package that depends on the :i386 packages.
>> 
>> And yes, that is not yet ready so any people pitching in and getting a
>> library package multiarchified will help. The patches are in the BTS,
>> they just need to be applied.
>
> Sorry if this has been posted already, but is there a usertag link
> tracking the bug report and patches you mention, i.e. those needed to
> make ia32-libs go away?

Not specifically for Debians ia32-libs but Steve Langasek filed patches
for all the packages Ubuntu needed as multiarch. Look for the patches in:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=multiarch-de...@lists.alioth.debian.org;tag=multiarch

MfG
Goswin


-- 
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/87haw5a7sx.fsf@frosties.localnet

Re: RFC: OpenRC as Init System for Debian

[Roger Leigh]

On Fri, Apr 27, 2012 at 05:18:35AM +0200, Michael Biebl wrote:
> This is getting OT and a better question for debian-user, so this will
> be my last post regarding this issue.
> 
> On 27.04.2012 04:34, Chris Knadle wrote:
> > AFAICT I really want the 'quiet' linux command line parameter, and to 
> > reconfigure the console output of systemd somehow.
> 
> man 1 systemd :
> 
> Try adding "systemd.show_status=true systemd.sysv_console=true" to your
> kernel command line. This is basically having the same effect for
> systemd as removing the "quiet" kernel command line option.

Is this the default?  Or do we need an additional "silent" option
so that systemd can behave similarly to the existing stuff when
passed the "quiet" option?


Roger
-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120427075451.ge28...@codelibre.net

Re: RFC: OpenRC as Init System for Debian

[Josselin Mouette]

Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
> > Yes of course, because event-driven init systems have *always* been
> > *only* about mounting USB devices. 
> 
> Then explain the _real_ reasons for having an event driven boot system!

BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
Full stop.
End of story.
Bye bye.

This must have been explained HUNDREDS of times in the endless threads
full of stupid messages from stupid dumbasses who don’t understand a
thing about init systems but don’t want their precious, idiotic, buggy
init scripts to go away.

> Finding new hardware for example can be related to software like hwdata.
> And why is udev classified as important, what's the use of that on
> servers?

Because Linux, in its current architecture, won’t work correctly without
it.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1335513264.3615.667.camel@pi0307572

Re: thttpd

[Paul Wise]

2012/4/27 Oleg :

>  No, i'm writing cgi with C for performance reasons and i wonder why
> http://sourceforge.net/projects/libctemplate/ is not in debian repository
> yet :-).

http://packages.debian.org/search?keywords=libctemplate

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: wine-unstable in Debian

[Stefano Zacchiroli]

On Fri, Apr 27, 2012 at 12:41:58AM +0200, Goswin von Brederlow wrote:
> The plan for wheezy is that ia32-libs goes away. At least that it will
> be just a transitional package that depends on the :i386 packages.
> 
> And yes, that is not yet ready so any people pitching in and getting a
> library package multiarchified will help. The patches are in the BTS,
> they just need to be applied.

Sorry if this has been posted already, but is there a usertag link
tracking the bug report and patches you mention, i.e. those needed to
make ia32-libs go away?

-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: thttpd

[Oleg]

On Fri, Apr 27, 2012 at 04:17:26AM +0800, Chow Loong Jin wrote:
> On 27/04/2012 02:59, Oleg wrote:
> >   Yes, i'm searching a tiny httpd for an embedded system with cgi support 
> > and
> > possibly with http basic authentication support.
> >   Thank you. I didn't know about busybox httpd.
> 
> No problem. busybox httpd supports CGI (just throw scripts into cgi-bin), but 
> it
> looks like Debian's busybox isn't built with CGI support. You could probably
> file a bug for this. I submitted a patch to Ubuntu to enable it early last 
> year.
> HTTP basic authentication is also supported by busybox.

  I think, i can rebuild deb by myself in any case.

> And if you're thinking of writing CGI shell scripts, you might be interested 
> in
> haserl.

  No, i'm writing cgi with C for performance reasons and i wonder why 
http://sourceforge.net/projects/libctemplate/ is not in debian repository
yet :-).
  haserl is great! May be i will use it.

  Thanks.


-- 
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/20120427073744.GA29494@localhost