Re: .la file status and hint to clear the dependency_libs field

On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote: > Comments welcome, but foremost I'd like a mass effort to clear the > remaining dependency_libs fields! :-) Am I right in thinking that this is the process people should follow? if depended-on: if dependency_libs: clear the depe

Re: consolekit makes trouble

On Sun, 29 May 2011 at 10:08:23 +0200, Hans-J. Ullrich wrote: > kdm: :0[21175]: Cannot open ConsoleKit session: Unable to open session: > Failed > to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Succes Reinstall the package that owns that file (which is "dbus"). If that doesn't h

Re: .la file status and hint to clear the dependency_libs field

On Mon, 30 May 2011 at 12:23:35 +0200, Vincent Lefevre wrote: > They are at least read by libtool. For instance, when building MPFR > (as a normal user): [...] > Either the information provided by /usr/lib/libgmp.la is important > and this file should be kept, or libtool should not attempt to read

Re: distinguish between "core" and "main"?

On Sun, 05 Jun 2011 at 08:29:03 +0200, Harald Dunkel wrote: > All these APIs and dynamic libraries are meant to provide backward > compatibility. You're asking for forward compatibility, though: making applications in testing/main limit themselves to only doing things which already worked in stabl

Re: Short question how to avoid creating one of two binary packages from source

of any) > > Depends: ... > > No, but "linux-any kfreebsd-any" might work. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec -- Simon Pa

Re: first put the packages in place, then afterwards the index files

ich is pushed). The problem is that ftp-chi should be pushed from ftp-osl, but there is a big delay (2 hours) between them, at least during the last sync: http://ftp-chi.osuosl.org/debian/project/trace/ Problem notified to OSUOSL, and mirror removed from rotation. Thanks for the report. -- Sim

Re: apt-get update MD5Sum mismatch

ou please report such issues to debian-mirrors ? Dear MSU admins, please update your ftpsync version, see http://www.debian.org/mirror/ftpmirror#how Best regards. -- Simon Paillard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Troub

Re: Multiarch in Debian unstable

On Mon, 27 Jun 2011 at 15:31:24 +0200, Vincent Lefevre wrote: > Related to that, will Linux support fat binaries[*] one day? I doubt it; but multiarch doesn't make them any more problematic. > If this is possible, where should they be installed, and how > libraries would be searched in a consiste

Re: Multiarch and D-Bus

On Fri, 01 Jul 2011 at 09:39:54 +0200, Josselin Mouette wrote: > Before we start to work on some packages, I’d like to ask if someone has > checked whether D-Bus is multiarch-safe. Said otherwise, is it possible > to use a D-Bus interface over another architecture? D-Bus is machine-word-size-neutr

Re: Multiarch and D-Bus

On Fri, 01 Jul 2011 at 09:01:04 +0100, Simon McVittie wrote: > Foreign-endian messages are always *meant* to have worked To clarify that a bit: messages can have either endianness, but libdbus will deal with that transparently, and always give library users data in native endianness (byteswapp

Re: Multiarch and D-Bus

On Fri, 01 Jul 2011 at 10:06:34 +0200, Bastien ROUCARIES wrote: > Even dark corner like double endianess ? Doubles are byteswapped in exactly the same way as int64, I hope that's correct everywhere? (dbus/dbus-marshal-byteswap.c around line 73.) To be more specific: D-Bus assumes that doubles are

Re: Multiarch and D-Bus

On Fri, 01 Jul 2011 at 10:54:12 +0200, Aurelien Jarno wrote: > We used to have the ARM old-ABI architecture using mixed-endianness, but > we don't have this architecture anymore (replaced by armel). D-Bus interop for doubles was always broken on ARM old-ABI, then, and nobody noticed :-( The curre

Re: apt-get update MD5Sum mismatch

On Thu, Jul 07, 2011 at 07:49:24AM +0800, jida...@jidanni.org wrote: > >>>>> "SP" == Simon Paillard writes: > SP> Jidanni, could you please report such issues to debian-mirrors ? > OK, but nobody sees it there, > http://lists.debian.org/debian-mirrors/20

Re: problem http://packages.debian.org/sid/biomaj

ure) > > > Can someone drive me to the correct person to contact? The website footer itself :-) ? "To report a problem with the web site, e-mail debian-...@lists.debian.org." -- Simon Paillard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subje

Re: Bug#633795: ITP: evolution-tray -- Plugin for Evolution to put it in notification area

On Thu, 14 Jul 2011 at 11:05:53 +0200, Arno Töll wrote: > I can't believe Gnome 3 > wouldn't support older legacy tray widgets though, I'd assume it would, > similar to KDE 4, supports older tray widgets through some legacy wrapping. GNOME 3 has a freedesktop-compatible notification area ("tray")

Re: How Debian Deals with Data

On Sat, 16 Jul 2011 at 01:31:21 +0200, Arno Töll wrote: > On 16.07.2011 00:20, Christopher Baines wrote: > > The actual package would just contain the rules and checksums for the > > files it tries to fetch, but not the data itself > > just as a random alternative idea (where other people may judg

Re: A few observations about systemd

On Mon, 18 Jul 2011 at 10:30:15 +0100, Jon Dowland wrote: > I don't suppose it would be worth maintaining a patch-set in Debian to support > other OSs: In a hypothetical future where systemd was the default init system > for Debian, it's probably less work to support multiple init systems and let >

Re: A few observations about systemd

On Mon, 18 Jul 2011 at 12:34:52 +0200, Federico Di Gregorio wrote: > Wasn't "universal" as in "runs everywhere" (i.e., on a lot of archs) vs > as "runs everything" (when a Debian GNU/WinNT?). I've always understood "the universal OS" to mean "all-purpose" and/or "for everyone". There's currently n

Re: help with git

On Thu, 21 Jul 2011 at 19:16:50 +0200, Julien Valroff wrote: > When running this type of config, how do you avoid pushing the upstream > tags to the debian repository? To push individual tags, use "git push origin 1.2-3" or something, instead of "git push --tags". To get rid of the upstream tags

Re: A few observations about systemd

On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote: > even init.d has a documented (and what's > more, actually *working*) implementation of not starting daemons at > boot. It's called 'remove the *** symlink'. If you remove them, they'll be recreated by the next upgrade; the right w

Bug#636081: ITP: prayerwheel -- Tibetan prayer wheel

Package: wnpp Severity: wishlist Owner: Simon Kainz * Package name: prayerwheel Version : 0.0.1 Upstream Author : Simon Kainz * URL : http://dharma-haven.org/tibetan/prayer-wheel.htm * License : Public Domain Programming Lang: none Description

Re: Introduction of a "lock" group

On Tue, 16 Aug 2011 at 11:19:05 -0500, Peter Samuelson wrote: > But for those who think it's annoying to have > to put 3 separate steps in your init script 'start' section (mkdir -p, > chown, chmod), I'd like to point out that you may as well just use > install -d, and do it all in one step. ... a

Re: *-config programs and multi-arch

On Thu, 15 Sep 2011 at 16:53:26 +0900, Miles Bader wrote: > Tollef Fog Heen writes: > > Your cross-toolchain is supposed to set up a symlink from > > /usr/bin/$triplet-pkg-config to /usr/share/pkg-config-crosswrapper which > > will then DTRT. That's the idea at least, I haven't actually tested >

Re: *-config programs and multi-arch

On Thu, 15 Sep 2011 at 19:52:01 +0900, Miles Bader wrote: > of course since there isn't an "x86_64-w64-mingw32-pkg-config" > program, instead it just uses the normal pkg-config That's the missing piece of the puzzle: some sort of cross-toolchain package (which doesn't exist yet in Debian - but nei

Re: Could the multiarch wiki page be explicit about pkgconfig files?

On Mon, 19 Sep 2011 at 19:01:04 +0200, Josselin Mouette wrote: > Le lundi 19 septembre 2011 à 12:52 -0400, Ted Ts'o a écrit : > > OK, how about /usr/lib//debug/sbin/e2fsck? > > > > I just checked and gdb doesn't find the debugging symbols if I drop the > > debug files under /usr/lib/. What is th

Re: Proxy compliance and assistance.

On Wed, 21 Sep 2011 at 14:13:31 -0500, Mike Mestnik wrote: > I'd like to start a movement to verify and assist projects/packages > with the proper deployment of software that supports proxies. In GLib-based applications, connecting using GSocketClient while having glib-networking installed will au

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

On Thu, 22 Sep 2011 at 15:34:31 +0200, Jérémy Lal wrote: > node-which finds the first instance of a specified executable > in the PATH environment variable. How does this differ from: * the 'which' utility in debianutils (which is Essential: yes) * the 'which' builtin in shells that have copied

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

On Thu, 22 Sep 2011 at 16:50:43 +0200, Jérémy Lal wrote: > By no means it is a replacement to existing 'which' tools, and no executable > would be provided, only a library file. Please use a short description that makes it look like a library rather than calling it "a utility", then (or a module o

Re: RE : Re: Proxy compliance and assistance.

On Thu, 22 Sep 2011 at 18:31:46 +0200, Bastien ROUCARIES wrote: > See libproxy package > Le 22 sept. 2011 12:10, "Simon McVittie" a écrit : > In GLib-based applications, connecting using GSocketClient while having > glib-networking installed will automatically use a confi

Re: Eliminating bash scripts?

On Wed, 28 Sep 2011 at 13:01:45 +0200, Thomas Hood wrote: > * The package then has fewer dependencies > * ... and can then be installed on a system without bash. This doesn't help Debian directly, but it may help upstreams to be portable to operating systems with a reason to use a non-bash shell -

Re: Bug#643669: ITP: pp-popularity-contest -- PredictProtein popularity contest

On Wed, 28 Sep 2011 at 16:38:11 +0200, Laszlo Kajan wrote: > Without the funding received based on the usage statistics you contribute by > installing this package none of the packages on Debian could have been made > available to you at no cost. I'm pretty sure that's not true. None of the Predic

Re: systemd, fstab, noauto and nofail

On 20/11/14 19:06, Noel Torres wrote: > On Thursday, 20 de November de 2014 17:53:27 Marco d'Itri escribió: >> On Nov 20, Sam Hartman wrote: >>> The first issue (fstab now fatally blocks boot) is something the systemd >>> maintainers have considered (as I understand it) and rejected. >> >> The beh

Architectures where unaligned access is (not) OK?

A couple of questions for people who know low-level things: * Of Debian's architectures (official and otherwise), which ones are known/defined/designed to be OK with unaligned accesses from user-space, and which ones (can be configured to) crash or give wrong answers? * Would it be safer to

Re: init system policy

On 21/11/14 14:04, Philip Hands wrote: > A quick glance at the manual leads me to try: > > systemctl disable gdm3 > > (and ... gdm, and a few other things) -- none of which work. Display managers are unusual here; they're an exception to the usual "enabledness" stuff. Normally, a service is e

Re: init system policy

On 21/11/14 17:07, Philip Hands wrote: > Is there any way this isn't going to be an enormous surprise to people > that are used to the way that Debian usually treats /etc? I do get your point; editing the (underlying file for the) .service is unnecessary and undesirable for systemd, and if you bli

Re: Architectures where unaligned access is (not) OK?

On 21/11/14 13:21, Thorsten Glaser wrote: > On Fri, 21 Nov 2014, Simon McVittie wrote: >> failing to start up on armel due to unaligned memory accesses. lzo2 has >> a cpp macro, LZO_CFG_NO_UNALIGNED which can be defined to stop it doing >> "clever" things with casti

Re: systemd, fstab, noauto and nofail

On 22/11/14 17:01, Russ Allbery wrote: > I think it's going to be pretty rare to have a system that > has /lib and /etc mounted but can't start ssh. In theory, that's possible > with a split / and /usr, but as we've discussed in other threads, that's > an extremely unusual configuration these days

Re: systemd, fstab, noauto and nofail

On 22/11/14 19:54, Matthias Klumpp wrote: > (Maybe systemd has smarter methods for that case which I don't know of) I think RequiresMountsFor is what you're looking for. ConditionFileExists is not the right thing here: the Condition* family more or less means "if the condition is absent, behave a

Re: Architectures where unaligned access is (not) OK?

On 21/11/14 13:31, Bernhard R. Link wrote: > Otherwise that memory > might afterwards be regarded as lzo_memops_TU2_struct lzo_memops_TU2_struct is declared with __attribute__((__may_alias__)), so actually the right thing should be happening WRT aliasing in this case. On 21/11/14 13:21, Thorsten

Re: Architectures where unaligned access is (not) OK?

On 23/11/14 17:55, Simon McVittie wrote: > Unfortunately, on my x86-64 laptop, my patched liblzo2 with > -DLZO_CFG_NO_UNALIGNED on all architectures seems to be half as fast as > the unpatched one [...] > I'm trying out a slightly different approach: keeping the unaligned > acc

Re: Architectures where unaligned access is (not) OK?

On 23/11/14 22:30, Julian Taylor wrote: > what works well is just replacing the offending memory loads with the > memcpy call. As the size of the memcpy call is constant the compiler > will take care of emitting code appropriate for the platform. Ah, even better; the timing on x86-64 comes out the

Re: Architectures where unaligned access is (not) OK?

On 23/11/14 22:54, Ben Hutchings wrote: > in this function > > void copy_foo(struct foo *dst, const struct foo *src) > { > memcpy(dst, src, sizeof(*dst)); > } > > the compiler is still allowed to assume that src has the proper > alignment for struct foo and to opti

Re: Age of built packages to be part of the jessie release?

On 24/11/14 11:42, Svante Signell wrote: > A question remains (for me): > How to build a package in a clean jessie environment? Seems like the > buildds are using sbuild. Have a minimal jessie chroot with build-essential, and a minimum of supporting tools to help with setup (I use cdebootstrap --f

Re: systemd breaking display manager - no way to force?

On 21/11/14 00:45, Norbert Preining wrote: > so here we are, after the freeze, and systemd stubbornly rejects > to start lightdm, my default display manager, and in turn tries > to start lxdm, which does not work because it is not selected as > default display manager. (Bug reported to systemd alre

Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2

On 24/11/14 21:41, Gerrit Pape wrote: > Better than (2) would be to make the existence of /etc/inittab still > essential for jessie, by moving the corresponding code from > sysvinit-core into the essential init package. What do you think? If you go this route, I think initscripts might be a bette

Re: Technical committee acting in gross violation of the Debian constitution

lopment from emdebian.org. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1 iJwEAQECAAYFAlR4cmYACgkQ0sfeulffv7vPKwP+LfoVtVuR9tscjavkpP86A3lL 0ep9JouCVcKir/IYfL4Yl/hpmwMtqerak7KqhGvfLrPogB1VV19oBCC/pU0Cxr8e ud9CNY7J422dUocr7cD0FEFF7PrRrZHCQ7Jx+v+/y4WmeTg1p/5UGlGuPtEHn5ht PRVzMQFmvGfUAX

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

ill simply drop off the network. Other systems I have have serial consoles only, also configured via inittab. Installing systemd there will lock me out. I gladly support systemd as default for new installations, but I think upgrades should remain safe to install as far as possible. Simon -

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

decades. When an upgrade installs systemd, this machine will simply drop off the network. > I want to warn about non-standard inittab entries with a debconf notice, > but I have not started working on it yet. Excellent, thank you! Simon -BEGIN PGP SIGNATURE

Re: Embedded systems and systemd

Hi, On 29.11.2014 08:37, Tollef Fog Heen wrote: > I'm not Simon, but one valid argument I've heard is that embedded stuff > has a tendency to get stuck on old vendor kernels, something that > doesn't work so well when systemd uses newer kernel interfaces. Correct, and I

Re: Embedded systems and systemd

, similarly to the way Debian ports are run. That does mean that maintainers should integrate these patches, even if they personally feel that this is a pointless exercise, because to other people, it isn't. Debian has always been great at choosing "both" when presented w

Re: DE features dependent on Systemd

On 03/12/14 14:28, Bjørn Mork wrote: > Josselin Mouette writes: >> We are talking about the anti-feature of adding UID=1000 to the audio >> group in the installer. > > Are we? I was talking about making audio work for the first-user. I > see that as a feature. It's a trade-off between utility

Re: Please respect Freeze Policy

On 03/12/14 15:36, Sam Hartman wrote: > You assert that even for leaf packages we should not make changes > in unstable targeted beyond jessie. I can see an argument for that > prior to the important bug deadline. However, past that point, I don't > see value in avoiding changes to leaf packages

Re: DE features dependent on Systemd

On 03/12/14 14:46, Svante Signell wrote: > On Wed, 2014-12-03 at 14:25 +0100, Vincent Bernat wrote: >> The problem with those groups is that they are not fine grained >> enough. > > If more granularity is needed, what's hindering introduction of even > more groups: like an image group and splittin

Re: DE features dependent on Systemd

On 03/12/14 16:44, Ivan Shmakov wrote: > > We are talking about the anti-feature of adding UID=1000 to the audio > > group in the installer. > > BTW, what about adding that same user to the ‘sudo’ group (which > D-I does; or formerly did, IIRC)? Does Logind also take care of >

"general" bugs

l" for this (as debian-devel is subscribed to this pseudopackage), should we create a new package, or...? Simon signature.asc Description: OpenPGP digital signature

Re: Can/should we have an efi/efi-any platform architecture?

t waiting to happen? Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. As this is something that changes rather seldom, I think it would be overkill. Si

Re: Can/should we have an efi/efi-any platform architecture?

On 11/12/14 18:08, Leif Lindholm wrote: > The point is, when we add support for another architecture which > supports UEFI, there are a number of packages that you will want to > enable for that architecture. I've occasionally wished we had a way to make a requiring package conditionally built dep

Re: Can/should we have an efi/efi-any platform architecture?

On 12/12/14 10:40, Johannes Schauer wrote: > Secondly, what you are expressing with: > > valgrind-dev > > is that you do or do not depend on the package valgrind-dev depending on > whether or not "archfeature.valgrind" evaluates to true (however this is > resolved). Yes, but I think that's exac

Re: Can/should we have an efi/efi-any platform architecture?

On 12/12/14 11:09, Simon McVittie wrote: > but I'd rather have > > Build-Depends: ..., valgrind , ... Looking at BuildProfileSpec again, that would actually have to be valgrind to express (arch-where-valgrind-exists && !stage1). The idea is the same though. S --

debian-devel@lists.debian.org

On 12/12/14 11:48, Johannes Schauer wrote: > Debian build profiles can express what USE flags do for Gentoo. They're not quite the same purpose, because we build one binary package per architecture, not one set of installed binaries per installation. Continuing the db5.3 example, we should continu

Re: GUI Configuration tool for main Debian window managers

On 05/01/15 18:17, john Lutz wrote: > I was wondering how one would one go about building > a GUI tool to cover every imaginable setting via a GUI > interface for the majority of standard live and other installed > Debian distribtion? I'd provide a terminal emulator, a documentation browser, a dec

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

On 20/01/15 16:00, Vincent Lefevre wrote: > It would be great if the maintainer could *always* receive the mail > when mailing to nnn@, and not just under obscure conditions. For > instance, I've been told by some maintainers that if the bug is > reassigned, the maintainer doesn't receive the mail!

Re: move file to another package

debian-policy/ch-relationships.html#s-replaces and further explained at https://wiki.debian.org/PackageTransition Simon -BEGIN PGP SIGNATURE- Version: GnuPG v2 iJwEAQECAAYFAlTZDtsACgkQ0sfeulffv7teVgQAq5b9Vk7GLEPE7ehJ2e+csrH1 Z9AffT+CAEBtEV/CWKiwmh933CjtUp04Sb9bQeXUuL3qraP52GEXTK2mcl

Re: Should .a library contains non-reallocatable code?

ages with every upload. Simon signature.asc Description: OpenPGP digital signature

Re: moving to multiarch for packages with plugins

On 18/02/15 10:49, Dennis van Dok wrote: > I'm maintaining a framework package (lcmaps) with several plugins that > traditionally install under /usr/lib/lcmaps. With the move to debhelper > 9, the default for dh_auto_configure is to pass > --libdir=/usr/lib/x86_64-linux-gnu which changes the plugin

Re: moving to multiarch for packages with plugins

Breaks: plugin-a (<= 0.1-4), plugin-b (<= 1.4-3) with the current version of all known plugins, and leave that line in for at least one release, possibly adding new plugins or adjusting the version if a plugin ships another version without multiarch. Simon -- To UNSUBSCRIBE, email to d

Re: how to remove libsystemd0 from a live-running debian desktop system

f these changes back into Debian proper as configuration options, in order to reduce the overhead of derivatives. Simon signature.asc Description: OpenPGP digital signature

Re: Should .a library contains non-reallocatable code?

On 19/02/15 23:19, Jeff Epler wrote: > Here are two scenarios where building a static library (libfoo) with > -fPIC is desirable ... > I wonder whether these scenarios were considered when the Policy was > written. Conversely, when that part of the policy was written, 32-bit x86 was the major arch

Re: conflicts between Debian's and upstream's Debian package

On 20/02/15 14:25, Harald Dunkel wrote: > IMHO there should be a policy for the special case, that > there is a naming conflict between upstream's source or > binary packages, and the packages included in Debian. Whatever we might say on the subject in Debian policy, upstream-produced packages are

Re: Should .a library contains non-reallocatable code?

to use the shorter form. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v2 iJwEAQECAAYFAlTnhykACgkQ0sfeulffv7t9SQP/ciifpIJLcZcJh/rEM0+EnhmB S9zs1n5xK7pJLXF7rQG1NCTUWXipm6Pgaul1SJRmaURkizd7to1d9h1XvJJGGLno 9awHZstfKyrr/ukpuu6CifGHzhgiMemZ7QvZRnLT1lZVAF2YGREc0daQDQRwVLNT 8BPQnm4VYsXKUYtl

Re: Possibilities to merge some parts of some of the daemons-that-need-to-be-restarted checkers (was: Re: Bug#776628: ITP: needrestart-session -- [...])

On 22/02/15 18:54, Thomas Liske wrote: > [400-notify-send] > Looks for the DISPLAY/XAUTHORITY environment variables of the session > and uses notify-send from libnotify-bin (trying to use html tags for > some formatting). This hook is *realy* uggly! With D-Bus maintainer hat on: This is an anti-p

Re: Should .a library contains non-reallocatable code?

Hi, Am 22.02.2015 um 20:18 schrieb Bernhard R. Link: > echo 'int foo(void) {return 17;}' > foo.c This code just happens to not generate any data references, so none of the forbidden reloc types are emitted. Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.d

Re: Should .a library contains non-reallocatable code?

y/stub code for the VXI-11 protocol, and is completely generated with rpcgen). Simon signature.asc Description: OpenPGP digital signature

Re: Should .a library contains non-reallocatable code?

brary ? No, just one. If that package were to be a shared library, the required space in the Packages file would be similar to the size of the files installed by the package. IMO, that's not really a good trade-off. Simon signature.asc Description: OpenPGP digital signature

Re: Getting multiarch fixes unstuck

On 09/03/15 14:16, Francois Gouget wrote: > About a month ago I sent fixes to make a bunch of packages multiarch > compatible. You might have noticed that Debian has been in a freeze for the last 4 months: https://release.debian.org/jessie/freeze_policy.html Multiarch'ifying libraries for Debian

Bug#780203: general: Cannot have more than 2 desktops

quot;, and we have to be sure which one you mean, so please list the complete steps (after login) that are necessary to reproduce the problem. Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists

Bug#782464: general: access violation 7e9bc87f in module gdi32 dill read of address 00aiffo2

should receive copies of most of the conversation about this problem anyway, and the current state of the discussion can always be found at http://bugs.debian/org/782646 . Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/552ae781.60...@debian.org

Re: Bug#782448: ITP: telepathy-gabble-legacy -- Jabber/XMPP connection manager (legacy branch)

On 12/04/15 12:51, Jonas Smedegaard wrote: > * Package name: telepathy-gabble-legacy ... > NB! This is an older legacy branch of Gabble with Tubes API, requires > for use with Sugar. If you do not need Tubes API then you are strongly > recommended to instead use the regular telepathy-gabble

Re: Stetch goal: improvements to testing-proposed-updates / experimental?

On 29/04/15 08:02, Joerg Jaspert wrote: > On 13926 March 1977, Anthony Towns wrote: >> - during the freeze, uploads to unstable that bump sonames should be held >> for RM review (or that will otherwise prevent new uploads of other packages >> to unstable from being suitable for promotion to testin

Re: Upcoming mass-bug filing: GStreamer 0.10 removal

On 13/05/15 09:42, Sebastian Dröge wrote: > I'm planning to submit bug reports with RC severity against all packages > still depending on GStreamer 0.10 in the next days, unless there are any > objections. Perhaps wait for to go

Re: Copyright format “License” field: grant of license, license text?

xt is critical to determining the actual license of a package. Code under GPLv2 and GPLv2+ have different properties. I prefer to clarify that 'License:' is intended to hold the license grant text together with the license text itself (or a pointer for the common license texts). Alternatively, a 'Grant:' keyword? /Simon signature.asc Description: PGP signature

Re: Bits from the Stable Release Managers

On 25/05/15 18:24, Lisandro Damián Nicanor Pérez Meyer wrote: > On Sunday 24 May 2015 21:27:47 Adam D. Barratt wrote: > [snip] >> Due to the way that the archive manages uploads to proposed-updates, if >> you upload a .changes file which only includes source and >> architecture:all packages, please

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

On 27/05/15 18:41, Christoph Anton Mitterer wrote: > However, I hope ifupdown is going to live on. Or are there any plans to > replace Debian's native tool? I don't think ifupdown has been "Debian's native tool" for several years now. It is one among several available tools, and happens to be the

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

On 27/05/15 21:12, Christoph Anton Mitterer wrote: > On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote: >> I don't think ifupdown has been "Debian's native tool" for several years >> now. It is one among several available tools, and happens to be the only

Re: RFH: dropbear initramfs support

On 30/05/15 01:09, Guilhem Moulin wrote: > - Should [dropbear initramfs support] be included in src:dropbear? It would probably lead to easier maintenance if it was, if Gerrit is willing to either sponsor your uploads or give you DM upload rights - the initial move from "initramfs support is in

Re: Making a .deb file to be added into the debian repository.

only bugfixes are allowed so users can be sure that installing updates will not introduce new bugs. It is completely acceptable and normal for a package to be maintained by different people than the original authors as well, so as an author, you are not necessarily responsible for providing packag

Re: Bug#787739: ITP: plip -- fully automated protein-ligand interaction profiler

Hi, On 04.06.2015 17:21, Alexandre Mestiashvili wrote: > * Package name: plip This might be confusing to old people. PLIP is a protocol for transporting IP packets over the parallel port. Simon signature.asc Description: OpenPGP digital signature

Re: Bug#787739: ITP: plip -- fully automated protein-ligand interaction profiler

Yes, I also think it is probably okay -- I just wanted to mention that it might be confusing at first. Simon signature.asc Description: OpenPGP digital signature

Re: ppp plugins and dependencies

On 07/06/15 12:35, Chris Boot wrote: > On 07/06/15 11:49, Michael Biebl wrote: >> Shipping a .pc file upstream to get the correct plugin directory (and >> build flags) sounds like a useful addition. > > Upstream's build system is... archaic. It doesn't autotools and its > configure script is hand-

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

On 14/06/15 17:19, Felipe Sateler wrote: > I think either libgnutls-deb0-28 or libnettle6 should add a Breaks: > libnettle4[1], to ensure all related packages are upgraded in lockstep. This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level

Re: Lintian auto-reject changes

On 18/06/15 11:17, Matthias Klose wrote: > On 06/17/2015 11:17 PM, Joerg Jaspert wrote: >> Everything hitting "empty-binary-package" is a *nonfatal* reject now. > > How does this make packages better? By avoiding bugs like . Most packagers meant to package somethin

Re: Proposal v2: enable stateless persistant network interface names

On 25/06/15 23:14, Philipp Kern wrote: > On the other hand I'm more of a fan of actually naming > interfaces by their purpose or external labeling. Makes for even less > mental gymnastics. \-: You can still do this via manual configuration; as far as I understand it, nobody is proposing to take aw

Re: Status on ddeb support in Debian

On 30/06/15 07:34, Niels Thykier wrote: > On 2015-06-30 07:14, Paul Wise wrote: >> A lot of derivatives use reprepro, do you know how that will handle >> ddebs? Perhaps it should get a default filter to put ddebs into >> separate archive components? main/dbgsym etc. > > No, I do not concretely kno

Re: The Spirit of Free Software, or The Reality

his is something we cannot do. Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a7d511.4070...@debian.org

Re: GitHub “pull request ” is proprietary, incom patible with Git ‘requ est-pull ’

On 16/07/15 18:14, Ian Jackson wrote: > Can you point me at the server code, or configuration that handled > your push ? Documentation: https://ikiwiki.info/tips/untrusted_git_push/ Implementation (it's a pre-receive hook): http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki/Rece

Re: Bug#792903: ITP: hdump -- Hexadecimal and ASCII dumper for binary files

On 20/07/15 00:04, Paulo Kretcheu wrote: > Description : Hexadecimal and ASCII dumper for binary files Does this have significant advantages over these tools that are already in the archive and likely to be near-ubiquitous on GNU systems? * od -t x1 (part of coreutils, and a subset of its f

Re: Metapackage dependencies: "Depends" or "Recommends"?

On 28/07/15 13:08, Marvin Renich wrote: > There is no downside to using Recommends and no upside to using Depends > for metapackages. I don't think it's that simple; it comes down to a question of what the metapackage "means", which is a design question for its maintainer. For metapackages that a

Re: Metapackage dependencies: "Depends" or "Recommends"?

On 28/07/15 13:55, Paul Tagliamonte wrote: > Well, I have a personal "thing" about this - it strikes me as quirky to > not have a Depends, since those metapackages, without all of them, is > technically not satisfied. ... > I'd prefer to see metapackages use > Recommends for the things that should

Re: Ad-hoc survey of existing Debian git integration tools

On 29/07/15 15:00, Ian Jackson wrote: > Are you saying that your source packages contain things that your git > repositories don't ? This comes up occasionally, and I will say again > what I have said before: I think this is wrong. Perhaps it is; but if so, then any conventional Autotools project

Re: Ad-hoc survey of existing Debian git integration tools

On 29/07/15 13:48, Ian Jackson wrote: > I got the impression that gbp normally works with a patches-unapplied > tree. Is that correct ? If so then an additional gbp step may be > needed, to convert the tree to patches-applied. "gbp buildpackage" can work either way, but I think most gbp users co

<    5   6   7   8   9   10   11   12   13   14   >