Re: Bug#618965: libetpan15: Breaks build system on Debian Sid

> On Sun, 20 Mar 2011 09:35:40 +0300 > > "Nikita V. Youshchenko" wrote: > > *) libetpan15 is linked against libdb4.8, but libetpan-dev depends on > > libdb5.1-dev > > This is a real issue since building packages against libetpan15 pulls > in a dependen

Re: Bug#618965: libetpan15: Breaks build system on Debian Sid

[CCing -devel because there are several questions below] > Package: libetpan15 > Version: 1.0-3 > Severity: critical > Justification: breaks unrelated software > > Installing libetpan15(-dev) causes libdb-4.8 libdb-4.7 libdb-4.6 to be > removed since libetpan depends on libdb-5.1. libdb5.1-dev can

Re: Forwarding bugs upstream

Hi After reading this thread, I've got a strange thought. So teams maintaining important projects in Debian can't handle the load caused by bug report stream. Large presentange of bugs actually as upstream bugs. If so, upstream should be interested in that information non less than in any oth

Re: Forwarding bugs upstream

> I understand that maintainers' time is limited and that forwarding bugs > is not an enjoyable task. But I also understand that having a BTS > account for the upstream BTS of each of the 2405 packages I have > installed on my laptop (not to mention my other machines) is simply not > practical. I

Security implication of using force-reload instead of restart ?

Hi I've just noticed that on libapache2-mod-php5 package upgrade, apache server was not restartted (but only HUPed because of force-reload called from libapache2-mod-php5 postinst) Doesn't this mean that running apache has still old version of php module loaded, so it still is vulnerable to is

runit package changes /etc/inittab ?

While we are on topic. Maintainer scripts of runit package modify /etc/inittab Although looks like /etc/inittab is not owned by any package, so policy is not violated, this IMO still looks strange in debian context. Is modifying /etc/inittab from postinst ok for random debian package these day

Re: Source code

> On Mon, Jan 03, 2011 at 04:55:52PM -0800, Don Armstrong wrote: > > On Tue, 04 Jan 2011, Stephen Grant Brown wrote: > > > I would like to install dpkg under Windows Vista. > > > > This is almost certainly going to be an exercise in pain. > > For building it, maybe, but not for getting it prebuilt.

Re: Full install/removal/upgrade test results available

> > I checked for cimg-dev in > > > > http://people.debian.org/~lucas/logs/2010/11/17/cimg-dev.log > > > > and found only one hint of a failure when it says: > > > > -- New version is unstable version: FAILED (UNINSTALLED != 1.3.9-1) > > > > but from reasing the log I can not find any hint for this

Re: Confused by .la file removal vs static linking support

> > > > > Static linking is resolved by providing a foo.pc file so that > > > > > "pkg-config --static --libs foo" is all that's needed to find > > > > > the right libs. > > > > > > > > This does not clarify the question about dependences. > > > > > > It does, because foo.pc won't work without its

Re: Confused by .la file removal vs static linking support

> I wouldn't > necessarily downgrade the -dev package dependencies: often they are > there not only for the static lib, but also because your library's > includes will #include files from other libs it depends on, so all > users of your -dev package may need the depended-upon -devs. So it > will d

Re: Confused by .la file removal vs static linking support

> On Sun, May 2, 2010 at 15:30:37 +0400, Nikita V. Youshchenko wrote: > > > On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote: > > > > (To actually statically link without the .la (or with an .la > > > > 'mangled' to empty

Re: Confused by .la file removal vs static linking support

> On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote: > > (To actually statically link without the .la (or with an .la 'mangled' > > to empty the dependency_libs field) largely amounts to reconstructing > > the information that was in the .la originally. That should be > > sufficient disin

Confused by .la file removal vs static linking support

Hi I maintain a library package, libetpan. I'm going to unload a new version, and, among other things, I was going to remove .la file, per release-goal In http://ftp-master.debian.org/~aba/la/current.txt, package is listed as 'libetpan: dependency_libs', so I thoughty I just need to remove .la

Re: Bits from the Release Team: What should go into squeeze?

> > From a current point of view squeeze will release with kernel 2.6.32 This is not very good, since .32 is skipped by -rt people, so us who need realtime kernel, won't be able just to add a patch to distribution kernel, but instead will have to use different upstream version. -- To UNSUBSCR

Re: Debian Mobile -- Debian GNU/Linux for mobile devices

> On ven., 2010-02-19 at 11:21 +0100, Michael Banck wrote: > > Maybe Nokia could be convinced to open up some/most of the Maemo5 apps > > once Maemo6/Meego is out; AIUI, not opening up the UI apps was an > > initial decision that has been at least partly rethought internally > > since. > > See http

Re: Debian Mobile -- Debian GNU/Linux for mobile devices

> Hi, > > Is anyone interested in starting a Debian Mobile project, probably as a > Debian Pure Blend? > > Goals: > - Provide an environment for handheld and netbook devices > + example: the Nokia N900 Interestingly, is it possible to create a mix between current n900 packages and debian,

Re: [MeeGo-dev] Debian Mobile -- Debian GNU/Linux for mobile devices

> > Of course work should happen upstream as most as possible. But as > > upstream will use rpm, our part is repackaging. > > It should be possible to work in the manner you have proposed without > problems. I am a great believer in the power of the community to resolve > any potential issues which

Re: [MeeGo-dev] Debian Mobile -- Debian GNU/Linux for mobile devices

> > Am Mittwoch, den 17.02.2010, 17:20 +0100 schrieb Raphael Hertzog: > > > On Wed, 17 Feb 2010, Julian Andres Klode wrote: > > > > Is anyone interested in starting a Debian Mobile project, probably > > > > as a Debian Pure Blend? > > Count me in. Me too. -- To UNSUBSCRIBE, email to debian-deve

Re: FOP: Objects for Formatting Objects ?

> *However*, do note that in the XML source files, there are comments such > as: > > > > > Thus you should carefully examine the licenses of each file. > may also be > useful. Perhaps that is because of technical, not legal, issues? -- T

Re: Xen support on Squeeze

> We have had to carry that patch without any upstream support (or sharing > with Novell, which eventually released SLES 11 with 2.6.27). As a > result, the xen-flavour kernels for lenny are very buggy, particularly > for domains with multiple vCPUs (though that *may* be fixed now). Unfortunately

Re: relocation error: ABI change?

> ... or by application having broken dependency information ... application package I mean -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: relocation error: ABI change?

> Hi, > If you see en error message like this one (from [1]): > > qutecom: relocation error: /usr/lib/qutecom/libphapi.so: symbol > CRYPTO_malloc_debug_init, version OPENSSL_0.9.8 not defined in file > libcrypto.so.0.9.8 with link time reference > > does it mean than openssl changed ABI without an

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

> > How to handle that case, if not putting private library as-is to > > /usr/lib ? > > > > Move it to /usr/lib/packagename, and use rpath on binaries? debian > > tries to avoid rpath AFAIK ... > > Just because we hunt down stupid rpath cases doesn’t mean there aren’t > valid uses for it. And this

Re: NMU question

> Dear Nikita, > > it is difficult to judge since you did not give the package name. > Nevertheless, the combination of RC bug left unfixed and signs of > obsolescence (package-uses-deprecated-debhelper-compat-version) suggests > that the maintainer might be MIA. If nobody wants to maintain this >

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

> On Mon, Nov 23, 2009 at 12:05:28PM +0100, Josselin Mouette wrote: > > Le lundi 23 novembre 2009 à 14:00 +0300, Nikita V. Youshchenko a > > > > écrit : > > > > > I found that adding missing call to dh_makeshlibs does not fix > > > > > the issue

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

> On Mon, Nov 23, 2009 at 13:33:17 +0300, Nikita V. Youshchenko wrote: > > Hi > > > > I tried to prepare and NMU to fix an RC bug #553111, which is > > postinst-must-call-ldconfig. > > > > I found that adding missing call to dh_makeshlibs does not fix th

Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig

Hi I tried to prepare and NMU to fix an RC bug #553111, which is postinst-must-call-ldconfig. I found that adding missing call to dh_makeshlibs does not fix the issue, because package installs a private shared library to /usr/lib/libxxx.so, and dh_makeshlibs does not add call to ldconfig to po

NMU question

Hi I've just met an uninstallable package with 3-week-old RC bug, caused by soname change of one of dependences. This bug could be fixed by a simple rebuild - I've checked if package builds against today's sid - yes it does. I've never done an NMU before, but this looks like a case to try :)

Re: library-related policy question

> On Sun, Sep 6, 2009 at 12:50:59 +0200, Emilio Pozuelo Monfort wrote: > > Nikita V. Youshchenko wrote: > > > Hi > > > > > > Is there an statement in Debian Policy that explicitly requires > > > higher version of a shared library package to be &g

Re: library-related policy question

> Nikita V. Youshchenko wrote: > > Hi > > > > Is there an statement in Debian Policy that explicitly requires higher > > version of a shared library package to be backwards-binary-compatible > > with previous versions of the same package? > > > > I me

library-related policy question

Hi Is there an statement in Debian Policy that explicitly requires higher version of a shared library package to be backwards-binary-compatible with previous versions of the same package? I mean, is a situation when after library package upgrade local binaries stops working because of missing

dcut

Hi I've got an interrupted upload to ftp.upload.debian.org, leaving stale files in the queue. I tried to clean up those using dcut -kyo...@debian.org rm stale_files but that was silently ignored. I was then able to remove stale files by setting DEBEMAIL and DEBFULLNAME and then running 'dcut

Upload to experimental closes bugs in BTS?

Hello. I've just uploaded a package to experimental, using standard Closes: XX syntax in changelog. In past, that caused bug XX to be just tagges as fixed in experimental. This time, the bug was closed. Why? signature.asc Description: This is a digitally signed message part.

Re: too many conflicts/replaces

> 2008/4/7, Nikita V. Youshchenko <[EMAIL PROTECTED]>: > > > 2008/4/4, Nikita V. Youshchenko <[EMAIL PROTECTED]>: > > > > Martin Schr?der wrote: > > > > > I'm trying to create a package that will when installed > > > &

Re: too many conflicts/replaces

> 2008/4/4, Nikita V. Youshchenko <[EMAIL PROTECTED]>: > > Martin Schr?der wrote: > > > I'm trying to create a package that will when installed > > > automatically replace all TeX packages on the system with our > > > version of TeX. > >

Re: too many conflicts/replaces

Martin Schr?der wrote: > Hi, > I'm trying to create a package that will when installed automatically > replace all TeX packages on the system with our version of TeX. > Unfortunately (in this case) the debian TeX system consists of more > than 10 packages so a naive approach via Conflicts/Replaces

Re: conditional dependency?

> On Mon, Feb 25, 2008 at 10:56:09PM +0300, Nikita V. Youshchenko wrote: > >> I maintain libetpan package, which build-depends on libcurl4-gnutls-dev. >> Resulting library package dependency is calculated using >> ${shlib:Depends}, however libdev package dependency on &

Re: conditional dependency?

> On Mon, Feb 25, 2008 at 11:48:21PM +0300, Nikita V. Youshchenko wrote: > > > > While it is easy for build-dependency (just use > > > > libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here > > > > with libdev package dependency. It should de

Re: conditional dependency?

> > While it is easy for build-dependency (just use libcurl4-gnutls-dev | > > libcurl3-gnutls-dev), I see a problem here with libdev package > > dependency. It should depend not on libcurl4-gnutls-dev | > > libcurl3-gnutls-dev, but on exact one that was actually used when > > building package. > >

conditional dependency?

Hi I maintain libetpan package, which build-depends on libcurl4-gnutls-dev. Resulting library package dependency is calculated using ${shlib:Depends}, however libdev package dependency on libcurl4-gnutls-dev is manually written in debian/control file. The build package dependency is valuable si

Re: -Wl,--as-needed considered possibly harmful

> Ok, let's consider another very simple case: > libshout allows to perform streaming of speex, vorbis, and theora formats. > > Hence, when asking for the libs to link with, you got -lspeex and -ltheora > since it's needed to cover all build cases. > > However, most of the applications don't need

Re: gcc compilation error with abs() affects sarge, etch, lenny, sid

> Today I saw a thread on the linux-kernel list [1] about a gcc compilation > issue that affects _all_ gcc versions in Debian after gcc-2.95. > I've filed bugs reports: > #452108 (gcc-4.2); #452113 (gcc-4.1); #452114 (gcc-3.3); #452115 (gcc-3.4) > > The issue is that in some cases a negative con

Re: pbuilder build with passing -sa option

> I use eg. > > pdebuild --configfile ~/debian/stable-pbuilderrc --debbuildopts '-sa > -v1.5-1' > > when doing backports. Hmm... Which version of pbuilder supports spaces in --debbuildopts properly? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Co

Re: dpkg-shlibdeps and private libraries

> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment > variable apparently defined by the openoffice startup script/program No. $ORIGIN is dynamic linker feature, it is expanded to the directory where executable resides. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a

Re: How to detect if inside a buildd chroot

Sebastian Dr?ge wrote: > Hi, > does somebody know about a solution to check whether one runs in a > buildd chroot or not? I need this to prevent hal from starting in buildd > chroots (via invoke-rc.d from postinst) as it breaks there because of > several reasons, including no /sys mounted. Maybe

Re: update-initramfs -k all -u

> Hi, > > I maintain uswsusp. It is a package that relies on a binary on the > initramfs that will start the resume process. This binary (and some > other stuff) get installed via an update-initramfs call in the postinst. > On some updates, the new binary that suspends the system is > incompatib

Re: pbuilder + local backports question

> On Sun, Apr 29, 2007, Nikita V. Youshchenko wrote: >> pbuilder-satisfybuilddeps is not smart enough to try packages from >> repository with lower pin-priority, even if build-depends is versioned. >> It just installs default version, without any notice. > > Comple

pbuilder + local backports question

Hello. I'm trying to use pbuilder to build some local backports (from post-etch to etch). In most cases, I want all build-deps to be installed from etch. However, sometimes some particular packages are wanted from other repository (where previously build backports are located). This should be

Re: Linux/Debian documentation suggestion

> The "man" and "info" documentation should (with time) be included in > the package. Why should I search the net for command documentations? > The system should supply the right documentation. Feel free to file a bug against each package that does not provide proper documentation. -- To UNSUBS

Re: Shouldn't [EMAIL PROTECTED] be more liberal on accepting mail?

> This one time, at band camp, Nikita V. Youshchenko said: >> Looks like with current setup, [EMAIL PROTECTED] does not accept >> mail from domain that does not exist for the outside world. >> >> This looks suboptimal for me: why not accept all mail that looks like a

Shouldn't [EMAIL PROTECTED] be more liberal on accepting mail?

Looks like with current setup, [EMAIL PROTECTED] does not accept mail from domain that does not exist for the outside world. This looks suboptimal for me: why not accept all mail that looks like a popcon report? I know that it is possible to do local setup such as mail will look more legitimat

Bug#413156: ITP: libgeo-ip-perl -- Perl bindings for GeoIP library

Package: wnpp Severity: wishlist Owner: "Nikita V. Youshchenko" <[EMAIL PROTECTED]> * Package name: libgeo-ip-perl Version : 1.27-1 Upstream Author : MaxMind LLC * URL : http://www.maxmind.com/ * License : GPL/Artistic Programming Lang: Pe

Re: What is available at early userspace?

> > And in the current situation, udev is *the* package that, by > > installing it's default configuration files, injects references to > > non-resolvable-locally users and groups into early stage of boot. > > Wrong. Your expectations to what is allowed to be > non-resolvable-locally are not in sy

Re: Bug#412989: udev startup script prints a lot of errors when ldap is used

reopen 412989 thanks > > I think that correct solution for the issue is to make udev package to > > create (in local /etc/groups) all missing groups referenced in it's > > default configuration files. > > I don't. > If you believe that some users or groups need to be unconditionally > created plea

On maintainers not responding to bugs

Hello. What do people look on the following idea: not allow packages to migrate from sid to testing if they have unanswered bug reports with severity >= normal? I guess it may be difficult to analyse automatically what is 'unanswered' (because there could be follow-ups by submitter and other

possible problem with ftp.us.debian.org

Hello. Since some time I noticed that after some executions of 'apt-get update' I'm getting 'md5sum mismatch errors'. I've just tracked this thing down. My apt setup used apt-cacher, whith 3 mirrors configured: ftp.de.deban.org, ftp.uk.debian.org and ftp.us.debian.org [probably this is default

umask-dependent debian/rules

Hello people. I would like to ask, is it considered a bug or not, if debian/rules implicitly depends on umask 022 (and produces packages with broken file permissions if umask is more strict). E.g. see #399058. If this is considered a bug, I guess it may be a subject for mass bug-filing... Ni

Re: block device served over network connections

> Are there any other packages I should be looking at to make this happen? > > If not, maybe this is something that should be considered by some people > who care as network based block storage is getting more common. With NBD, > AOE, and ISCSI (and others I am sure), I don't think that each packa

Two questions on package quality

Hello people. I was asked to sponsor a package upload. I am in doubt on tho following issues, so I/m asking debian-devel for comments. 1. Upstream does not provide a manual page for the binary. Packager decided to add binary-without-manpage to lintian override file, and Tag: no-manual-for-bin

RFC: initramfs-tools postinst causes system inconsistency?

l for futher discussion. > On Sun, 26 Nov 2006, Nikita V. Youshchenko wrote: > > Looks line postinst script of initramfs-tools package just runs > > 'update-initramfs -u' > > yes and it will stay like this. > > > This looks to update initramfs image for one

Re: On including 64-bit libs in 32-bit packages (see #344104)

> Am Samstag 21 Oktober 2006 11:49 schrieb Nikita V. Youshchenko: >> Question is - does Debian i386 currently support running on 64-bit >> binaries if hardware supports it? > > _and_ if the kernel supports it. > >> Linux blacky 2.6.18-1-k7 #1 SMP Fri Sep 29 17:06

On including 64-bit libs in 32-bit packages (see #344104)

Question is - does Debian i386 currently support running on 64-bit binaries if hardware supports it? Just checked: $ apt-get install libc6-dev-amd64 ... $ gcc -m64 -o hello hello.c $ ./hello bash: ./hello: cannot execute binary file $ cat /proc/cpuinfo ... model name : AMD Athlon(tm) 64 X2

Re: gfdl gcc documentation packages for non-free: update

> Nikita V. Youshchenko writes: > > Hello. > > > > I've updated gcc-4.1 documentation packages (Section: non-free/doc). > > Packages are no longer debian-native, also several issues have been > > fixed. > > > > Also, I've created gcc-doc-defa

gfdl gcc documentation packages for non-free: update

Hello. I've updated gcc-4.1 documentation packages (Section: non-free/doc). Packages are no longer debian-native, also several issues have been fixed. Also, I've created gcc-doc-defaults package (Section: contrib/doc) that builds gcc-doc, cpp-doc, gfortran-doc and treelang-doc packages with pro

Re: gcc-4.1 [gfdl] documentation packages for non-free

> On Sun, Sep 17, 2006 at 12:06:02AM +0400, Nikita V. Youshchenko wrote: > > I've created gcc-4.1-doc-non-dfsg package, intended for non-free. This > > package builds several binary packages (cpp-4.1-doc, gcc-4.1-doc, > > gfortran-4.1-doc, tree;ang-4.1-doc), that contain

gcc-4.1 [gfdl] documentation packages for non-free

Hello. I'm one of those people beaten by recent removal of gcc documentation. Both myself and people to whom I recommend Debian, *need* gcc documentation to be available in the system. So I had four options: - start a new flamewar on the issue, - stop to use Debian (and to recomment it), - inst

Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package

> El domingo, 18 de junio de 2006 a las 22:03:32 -0500, Ron Johnson > escrib?a: > >> When I tried to install it as root (using "su -" from an xterm >> window), it complained about not being able to find DISPLAY. Unlike >> Sun Java & Macromedia Flash, it uses a GUI installer. > > I've found "s

Re: Move to python 2.4 / Changing the packaging style for python packages

>Binary dependent >extensions are put for all supported python versions into the >same python-foo package. So these packages are going to depend on all supported python versions, making impossible to remove old python versions from user's systems? pgp8TX0wkQDNo.pgp Description: PGP

Re: debdelta

> The command 'debdelta-upgrade' is meant to be run between 'apt-get > update' and 'apt-get upgrade'; it downloads .debdelta files and > recreate the new .deb files from them; always using the *installed* old > version of the .deb, and not the old .deb file itself. Is it safe - e.g. in case of

Re: Bug#367853: libdb transition policy?

> Have fun with updating the library, it won't affect depending packages. > :) Some times are that easy to solve, you know? Ok, will upload today :) pgpHAIvddyz9K.pgp Description: PGP signature

Re: libdb transition policy?

> * Andreas Barth: > > Why that? It would only affect packages that (correctly or wrongly) > > also depend on libdb4.2. (And libdb4.2 unfortunatly doesn't have > > versioning, otherwise, it wouldn't be any issue; lidb4.3 and libdb4.4 > > are better in that regard.) > > Berkeley DB 4.2 was compiled

libetpan 0.45-2 was built on m68k but not went to archive?

Hello. I just found that my package, libetpan, was not updated for m68k. [1] states that it is out of date on m68k. But [2] states that latest version was successfully built on m68k long ago - on Apr17. What's going on? Whom to contact on this issue? Nikita [1] http://bjorn.haxx.se/debian/test

libdb transition policy? (Was: Re: Bug#367853: libetpan: Please consider transitioning to libdb4.4)

[CCing to -devel and to people who maintain packages that depend on libetpan] > Package: libetpan > Severity: wishlist > > > Hi, > currently several versions of the berkeley db libraries are used in the > archive: libdb[4.2,4.3,4.4]. > Please consider upgrading to libdb4.4 in order to ship etch w

Re: libdb transition policy?

> * Nikita V. Youshchenko: > > However, if I will build library against libdb4.4 instead of > > libdb4.2, this will probably break any binaries built against the > > library - both packaged and local. > > What kind of interface does libetpan expose? Based on the packag

Re: Accepted scrollkeeper 0.3.14-10.1 (source i386)

> Changes: > scrollkeeper (0.3.14-10.1) unstable; urgency=low > . >* Non-maintainer upload. >* Foo. > Files: Wonderful changelog :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cross-compiling Debian packages

> Would you be so kind to post undeted patches to these bugs? s/undeted /updated :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cross-compiling Debian packages

> I hope that my patches (#357629, #357658 > , #357661 > ) are proper enough:-) This is incomplete: not only libgcc does not provide -dcv1, but libstdc++ and -dev and -dbg. Would you be so kind to post undeted patches

Re: cross-compiling Debian packages

> >You have too old version of libgcc1-arm-cross, that does not provide > >libgcc1-arm-dcv1 (and, btw, installs to /usr/arm-linux/) > > No, that's not true. It does install into /usr/arm-linux-gnu. > I got this one from the latest gcc sources > (4.0.2-9). And it still does not provide libgcc1-ar

Re: cross-compiling Debian packages

> I think I know now what the problem is, see below... > > On Thu, Mar 16, 2006 at 07:35:41PM +0300, Nikita V. Youshchenko wrote: > > > As you see, I get depends with -dcv1 suffix as well as -cross > > > suffix. > > > > Yes, it's exactly what it shoul

Re: cross-compiling Debian packages

> > As you see, I get depends with -dcv1 suffix as well as -cross suffix. Yes, it's exactly what it should do. Each package xxx-arm-cross package created with dpkg-cross >= 1.26 will Provide: xxx-arm-dcv1. In your case, this will not allow libc6-arm-cross created by older dpkg-cross to satisfy d

Re: cross-compiling Debian packages

> Libary locations and library search paths. dpkg-cross and every other > crosscompiling solution moves libraries to unexpected locations. You no > longer can "just apt-get" the target arch libs you need. This is > managable as long as you stick with autoconf -based software, but you'll > go nuts w

Re: cross-compiling Debian packages

> > > >You may look at dpkg-cross ... > > I did, and I'm using it, thanks:-) > > What is the deal BTW with that new rewrite_dependencies (as of 1.26) > producing bogus names with > -dcv1 suffix? I had to comment 2 lines out of dpkg-cross script to make > it work for libgpm for instance... It's ver

Re: cross-compiling Debian packages

> I have devoted some time cross-compiling a number of essential packages, > with glibc-based, > uclibc-based and dietlibc-based ARM and MIPS toolchains and found all of > that not a huge > problem at all, given that "debian/rules" is provisioned with proper > calls to --host (as described > by the

Re: State of gcc 2.95 use in Debian unstable

> Debian is not rushing to drop gcc 2.95, but in the long run, it's > inevitable. Or, to put it in your words, there is a business case for > dropping gcc 2.95 support in etch. If current debian maintainer(s) don't want to maintain gcc-2.95 any longer, they should probably orphan it, just like any

Re: State of gcc 2.95 use in Debian unstable

>> > The need for gcc-2.95 usually means the source code is broken (in C99 >> > terms) and should be fixed. Do you have an example of an use case where >> > this is unfeasible, and which is important enough to justify continued >> > maintenance of gcc 2.95? >> >> Device driver development for embe

Re: State of gcc 2.95 use in Debian unstable

> Dave Carrigan wrote: >> On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: >> >> > this makes it IMHO a plausible release goal to get rid of 2.95 >> > maintenance for etch. >> >> No it is not. Just because debian packages don't use 2.95 doesn't mean >> that end users have the same

Re: i386-uclibc debian

> I'm now working on discovering the best order to build the 87 needed > source packages to get a base+buildessential set for debootstrap. I believe this should be done on normal debian host, using dpkg-cross's 'dpkg-buildpackage -a'. As of it's current state, it won't work. But it could be made t

Re: i386-uclibc debian

Hello > How is the effort going > (http://lists.debian.org/debian-devel/2005/09/msg01362.html)? Pity I've read about this only now :( Making support for such additional 'archs', targeting mainly uclibc archs, is *the* direction where I was going to move with dpkg-cross and debian cross-toolcha

Re: fresh blood gets congested: long way to become DD

> Awaiting AM assignment 140 days > Awaiting DAM Approval184 days I'm already waiting for DAM approval for almost 6 months, and I'm ready to wait more (after all, there is a psyhological difference between a day and a month, but not between 6 and 12 months). The only thing that makes me fee

Re: Use volatile?

> On Sun, Jul 31, 2005 at 11:10:04PM +0400, Nikita V. Youshchenko wrote: >> As it is being currently discussed on debian-security [1], security >> team has hard times supporting mozilla family of packages, because of >> unfriendly upstream policy - they don't want

Re: RFC: allow new upstream into stable when it's the only way to fix security issues.

> On Sun, 2005-07-31 at 23:10 +0400, Nikita V. Youshchenko wrote: > > (3) allow new upstream into stable. > > But, how would be the proposed process for this software? > > I mean, should they also have some kind of grace period after uploading > to unstable? Would it ent

RFC: allow new upstream into stable when it's the only way to fix security issues.

Hello. As it is being currently discussed on debian-security [1], security team has hard times supporting mozilla family of packages, because of unfriendly upstream policy - they don't want to isolate security fixes from a large changesets of new upstream releases. And given the huge size of t

Bug#320387: ITP: pyicq-t -- ICQ Transport for Jabber, implemented with Python and Twisted

Package: wnpp Severity: wishlist Owner: "Nikita V. Youshchenko" <[EMAIL PROTECTED]> * Package name: pyicq-t Version : 0.6-1 Upstream Author : Daniel Henninger <[EMAIL PROTECTED]> * URL : http://pyicq-t.blathersource.org/ * License : GPL

Re: libxml++2.10

> Hi Nikita, > > Am Donnerstag, den 28.07.2005, 12:04 +0400 schrieb Nikita V. > > Youshchenko: > > > I talked to upstream and they > > > said, the ABI broke during the development unintentionally, but we > > > should better stick to libxml++2.6-2.10.0

Re: libxml++2.10

> > For one of our internal projects, libxml++2.6 was too old. > > So I've created a package for libxml++2.10, using debian/ dir for the > > latest libxml++2.6 package. > > I packaged it for Ubuntu - libxml++2.6 and libxml++2.10 were never > designed to be installable parallely. I believe my packa

libxml++2.10

Hello. For one of our internal projects, libxml++2.6 was too old. So I've created a package for libxml++2.10, using debian/ dir for the latest libxml++2.6 package. Upstream source looked somewhat inconsistent. I had to change '2.6' to '2.10' in many files and rerun autotools to make package bui

Re: The BTS and bug subscriptions

>> As in once you confirmed one subscription the next one doesn't ask >> anymore? Sort of greylisting? >> >> Sounds good. > > It should always ask for confirmation unless someone has specifically > made the decision that they don't want to have to opt-in. Maybe it should honour subscription requ

Keyboard lockup after X startup; possible cause

Hello. Several people probably faced the problem that after initial system bootup, and startup of *dm, keyboard does not work. Suggested workaround was to add implicit 'vtX' parameter to X server command line in Xservers file. I've never seen an explanation of what is actually hapenning, and wh

Re: Updating dpkg-cross: file moving question

> - tree at old location may become inconsistent (if x depends on y, > x-arch-cross is generated by new dpkg-cross, and y-arch-cross is > generated by old dpkg-cross), I meant 'y depends on x'. pgpIcwjCKqUZO.pgp Description: PGP signature

Re: Updating dpkg-cross: file moving question

> The question is - how to process existing cross-compile environment, > created by earlier versions of dpkg-cross. > > I am thinking to make the following trick. In postinst of new > dpkg-cross, it will check for /usr/arm-linux, /usr/powerpc-linux/, and > other places where packages created by ear

  1   2   >