On 14/06/2024 18:24, Andreas Metzler wrote:
On 2024-06-14 Gürkan Myczko wrote:
[...]
Have never done mass bug filings, any easy way, preferably something copy
pastable,
non-interactive.
Hej,
How about mass-bug(1) in devscripts?
Also set a user/usertag when doing an MBF in order to have a n
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, [EMAIL PROTECTED],
[EMAIL PROTECTED]
* Package name: bzr-eclipse
Version : 0.0.17
Upstream Author : Guillermo González <[EMAIL PROTECTED]>
* URL or Web page : http://bazaar-vcs.org/BzrEclipse
* License
Hi,
Mikhail Gusarov wrote:
> Gentlemen,
>
> I'm going to package tool called Sphinx (http://sphinx.pocoo.org/) -
> documentation generator for Python projects.
>
> In ITP (#474782) I chose package name to be 'python-sphinx', however
> then the package will be thought as containing just python mo
Raphael Hertzog wrote:
> And the fact that he sends one mail per e-mail instead of one mail per
> package makes it even better (far less annoying).
Agreed, specially for people or teams who maintain lots of packages.
Raphael, would it be possible for you to do the same with DEHS mails?
Thanks,
E
Raphael Geissert wrote:
> Emilio Pozuelo Monfort wrote:
>
>> Raphael Hertzog wrote:
>>> And the fact that he sends one mail per e-mail instead of one mail per
>>> package makes it even better (far less annoying).
>> Agreed, specially for people or
Martin Pitt wrote:
> Please change your packages accordingly. I'll start filing bugs in a
> few months, when the bulk of packages is hopefully fixed already.
>
> Thank you in advance!
>
> Martin
>
>
> List of affected (binary) packages, per maintainer:
>
> Debian GNOME Maintainers <[EMAIL
Josselin Mouette wrote:
> This is easy to do by advance. If your library builds with
> -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED
> -DGTK_DISABLE_DEPRECATED, it will only require minor changes to work
> with GTK+ 3.
Plus -DGDK_PIXBUF_DISABLE_DEPRECATED
Cheers,
Emilio
signature.asc
Descrip
Ludovic Brenta wrote:
> So, my understanting was correct then: gtk-extra2 will FTBFS only when you
> remove GTK+2 from Debian, not when you introduce GTK+3.
Yes, but that will also mean package using gtk-extra2 will not be able to link
to gtk3, which is what Neil was saying IIUC.
> Joss, can you
Ludovic Brenta wrote:
> OK, I think that explains it. Here is what I propose:
>
> - I will adopt the package gtk+extra and maintain it in Debian for as long as
> GTK+2 is in Debian and libgtkada2 needs it.
> - I will not update the package to use GTK+3.
> - I will prominently mark the package as
Neil Williams wrote:
> On Tue, 30 Jun 2009 14:30:41 +0200
> Ludovic Brenta wrote:
>> - I will prominently mark the package as deprecated and discourage
>> new packages from using it. As part of this I will move the package
>> to main/oldlibs.
>
> A note in the description is one way but are there
Hi folks,
I proposed [1] a GSoC project this spring which was accepted, and I'm thus
working on getting automatic debug packages into Debian.
The reasons for this are, among others, that adding -dbg packages to thousands
of packages doesn't scale, that they bloat the archive and mirrors, and the
Paul Wise wrote:
> I note that you plan to modify the helper tools
> (debhelper/cdbs/yada/etc). I think that you will get better coverage
> by modifying dpkg-dev instead. Have you not considered that option or
> am I missing a disadvantage of it?
I tried to think in another level that would cover
Michael Banck wrote:
> Maybe it is reasonable to expect the package gets built on the buildd?
> AIUI, this is the way Debian is heading anyway.
>
> So while it is not required to build a .deb via dpkg-buildpackage; .debs
> distributed by Debian will be at some point.
I saw some complaints in debi
Manoj Srivastava wrote:
> I think that we would need a clear policy of what packages are
> expected to do as well. Policy does not mandate that helper packages be
> used in Debian packages, and we can't suddenly start mandating that
> they be used.
I think you misunderstood it. The arch
Raphael Hertzog wrote:
> Hello,
>
> one more turn for this DEP, after all. Recent changes are not numerous
> but there are some.
>
> Current version: http://dep.debian.net/deps/dep3/
Would it be possible to make Origin optional if Bug is present? I feel that when
Description and Bug are present,
Manoj Srivastava wrote:
> We do not want to have different helper package start inventing
> a helper specific way of building ddebs, with no clear standard tha
> they are following.
> While archive coverage is nice, ensuring that a ddeb is
> properly defined, and that all the
Stefano Zacchiroli wrote:
> On Wed, Jul 29, 2009 at 02:18:49PM +0200, Emilio Pozuelo Monfort wrote:
>> I've written down the details in the wiki [2], and I'll appreciate
>> it if you could give some feeback. I don't want to trash this
>> completely though, so no
Charles Plessy wrote:
> I see that .bzip2 and .lzma are also supported compression methods for the 3.0
> (native) format as well as for the binary packages. But I do not think it
> would
> be useful to add zip to this list. It seems to me that the only thing needed
> is
> the capacity to unpack t
Julien BLACHE wrote:
> Luk Claes wrote:
>
> Hi,
>
>> There will be a Build-Arch field or some other way to make sure the
>> arch:all packages can be built reliably.
>
> How will this work wrt non-Linux ports?
>
> If you declare Build-Arch: i386, and that means the package should be
> built onl
[ Moving to debian-policy ]
Manoj Srivastava wrote:
> On Fri, Jul 31 2009, Emilio Pozuelo Monfort wrote:
>
>> Manoj Srivastava wrote:
>>> We do not want to have different helper package start inventing
>>> a helper specific way of building ddebs, with n
Manoj Srivastava wrote:
> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>> which is short since the format is basically that of .debs). Do we
>> really need this to be documented in
Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 09:46:49PM +0100, Roger Leigh wrote:
>> Reading through this thread, I don't see a compelling reason for using
>> a .ddeb extension given that they are just regular .debs, nor for
>> keeping the packages separate from the main archive (if the size of
Josselin Mouette wrote:
> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>> Except you have not indicated how you (or debhelper) is going to
>> intercept ld to add the requisite arguments.
>
> http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html
Also see ht
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Josselin Mouette wrote:
>
>> Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
>>> Hmm. I see very little benefit here. Firstly, to use build id,
>>> you have to intercept the upstream build system and add --build-id
>>> (and p
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Josselin Mouette wrote:
>
>> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>>> Except you have not indicated how you (or debhelper) is going to
>>> intercept ld to add the requisite arguments.
>> http://lists.debian.org/debi
Manoj Srivastava wrote:
> Hi,
>
> All right. Having been educated about the new build-id
> mechanism, I think there is not reason for policy to prohibit either
> approach, or to settle on one or the other.
>
> To recap:
> 1) packages with detached debugging symbols should be na
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Emilio Pozuelo Monfort wrote:
>> Manoj Srivastava wrote:
>>> Can you point ot me the disadvantage of continuing to use what
>>> dh_strip does now?
>> It can still be used, but you will miss the advantages o
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Russ Allbery wrote:
>
>> Emilio Pozuelo Monfort writes:
>>> Manoj Srivastava wrote:
>>>> To recap:
>>>> 1) packages with detached debugging symbols should be named
>>>> ${p
Russ Allbery wrote:
>> Having them in the Binary section in the .dsc and Binary and Description
>> in the .changes files would mean modifying
>> dpkg-buildpackage/dpkg-genchanges for ddebs not listed in
>> debian/control. However listing them in Files and Checksum-* in the
>> .changes requires no c
Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>> Russ Allbery wrote:
>
>>> It sounds like listing them only in *.changes but not in *.dsc or
>>> debian/control may be the easiest approach.
>> Indeed, for the automatic-not-listed-in-debian-control
Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>
>> You can build a .ddeb manually, yes. However for some cases
>> (e.g. packages using debhelper and building ELF binaries) a .ddeb will
>> be automatically created (if none is created manually) and detached
>>
Russ Allbery wrote:
> Josselin Mouette writes:
>> If we use build IDs (and this has quite some advantages, like being able
>> to do more than just dump the ddebs on a repository), this can lead to
>> having the same detached debugging symbols in two binary packages, since
>> sometimes a binary is
Josselin Mouette wrote:
> Emilio Pozuelo Monfort
>scribes
> Python Applications Packaging Team
>scribes (U)
Fixed in trunk.
Cheers,
Emilio
signature.asc
Description: OpenPGP digital signature
Josselin Mouette wrote:
> Hi,
>
> the question in the subject may sound a bit naive, but I’m starting to
> wonder why we still set the Standards-Version in package control files.
>
> AIUI, this header is here to indicate which version of the policy the
> package is supposed to conform to. This wa
Roger Leigh wrote:
> On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
>> Quantity of .ddebs:
>> Usually there should only be one .ddeb per source. Of course there are
>> always exceptions from the rule, so Maintainers may chose to have one
>> per binary package. This should only be ta
Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>> Roger Leigh wrote:
>
>>> This fails to address the rather valid concern brought up about having
>>> different versions of libraries and binaries installed from the same
>>> source package. Havin
Russ Allbery wrote:
> Hm, that's interesting, but I suspect that few enough of our users will be
> able to use such a thing that we shouldn't let that influence any other
> design choices. Most shares are not going to be able to be mounted
> through firewalls, for example, so that form of the debu
Manoj Srivastava wrote:
> On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote:
>
>
>> There will still be a repository with all the .ddebs.
>
> And aptitude and dpkg will know how to install ddebs, somehow?
> and synaptic, etc?
Yes, dpkg, apt-get, aptitu
Julien Cristau wrote:
> On Thu, Aug 13, 2009 at 02:58:45 +0200, Emilio Pozuelo Monfort wrote:
>
>> If that bothers you, you can use the share we plan to provide.
>>
> I'd like to still be able to debug offline, thank you very much. So far
> you've avoided answe
Roger Leigh wrote:
> On Thu, Aug 13, 2009 at 02:58:45AM +0200, Emilio Pozuelo Monfort wrote:
>> Roger Leigh wrote:
>>> This fails to address the rather valid concern brought up about
>>> having different versions of libraries and binaries installed
>>> from
Eugene V. Lyubimkin wrote:
> Hello thread! /me puts on a package manager developer hat.
>
> Sorry, I haven't read the whole thread, it's huge.
>
> I think that diversion of debug packages out of current deb format is a
> completely wrong direction. Do you want to teach all tools that get some inf
Russ Allbery wrote:
> https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It does
> use *.ddeb. There isn't any clear statement about how *.ddeb packages
> differ from *.deb packages. It looks like, by and large, they don't,
> except they may not need to contain the same set of thin
Russ Allbery wrote:
> The only lingering concern that I have about a share is how it plays with
> the files installed on your system via package. Can gdb be pointed to
> multiple different debug information stores at different paths? Mounting
> a remote share over top of /usr/lib/debug obviously
Holger Levsen wrote:
> Hi,
>
> for some packages the piuparts upgrade test failed because dpkg detected a
> conffile as being modified and then prompted the user for an action. As there
> is no user input, this fails. But this is not the real problem, the real
> problem is that this prompt show
Andreas Barth wrote:
> Updated the list and put it on http://alius.ayous.org/~aba/la-view.txt
> and updated in () the packages that depend on the current package.
Can you also create a dd-list list?
Thanks,
Emilio
signature.asc
Description: OpenPGP digital signature
Charles Plessy wrote:
> Here is my current plan:
>
> - Open a RC bug on samtools to prevent testing migration.
> - Upload a new samtools package where -fPIC is enabled.
> - Upload libbio-samtools-perl to NEW.
> - Open a RC bug on libbio-samtools-perl prevent testing migration
>after it is
Wouter Verhelst wrote:
> I know it is fancy and modern to think that Debian native packages
> should only be used for things that are specific to the Debian
> infrastructure, but there is nothing in policy that requires that, and
> indeed several packages (including, e.g., offlineimap) are distribu
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 mean, is a situation when after library package upgrade local
Steve Langasek wrote:
> And if the symbols in question were exported in a header (else how did
> mplayer come to depend on them?),
The package could have defined the prototype before using it. That's a real live
scenario, see e.g. #542216 (hopefully it's not very frequent...).
Emilio
signature
Hi,
Matthias Klose wrote:
> Both libreadline-dev (>= 6.0) and libreadline6-dev are now available in
> unstable and testing. If possible, please replace the libreadline5-dev
> build dependency with libreadline-dev, so that in future changes of the
> libreadline soname binNMU's can be used for this
Hans-J. Ullrich wrote:
> Dear developers,
>
> I would like to suggest a new idea, which might improve the system.
>
> Problem: Whenever I upgrade to a new kernelversion, or there are new versions
> of kernel-modules or other packages, which are only available in source-code,
> it is necessary
Package: wnpp
Severity: wishlist
Owner: Emilio Pozuelo Monfort
* Package name: eog-plugins
Version : 2.28.0
Upstream Author : Lucas Rocha
* URL : http://live.gnome.org/EyeOfGnome/Plugins
* License : GPL2+
Programming Lang: C, Python
Description : set
Manoj Srivastava wrote:
> And that, I think, may serve as a guiding criteria for whether
> one should make a package native or not. With my native packages
> (kernel-package, ucf, and devotee), I do not _have_ an upstrem process,
> nor an upstream "distribution" or tarball; and thus ther
Stefano Zacchiroli wrote:
> On Tue, Sep 22, 2009 at 12:36:09PM +0200, Josselin Mouette wrote:
>> Done, omitting a reported false positive and a few packages fixed in the
>> meantime.
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org;tag=python2.6
>
> Thanks.
>
>
Russ Allbery wrote:
> I wonder what's up with all the Gstreamer and Npp fields.
Those are used to find the needed package for autocodec installation when you
try to reproduce a package with a missing decoder/encoder/whatever (package
gnome-codec-install).
Cheers,
Emilio
signature.asc
Descripti
Goswin von Brederlow wrote:
> Russ Allbery writes:
>
>> Goswin von Brederlow writes:
>>
>>> Dpkg has the ability to vanish empty packages. A dummy package should
>>> be completly empty and not even contain a /usr/share/doc/.
>> Such a package is explicitly forbidden by Debian Policy. You need t
Barry deFreese wrote:
> My personal feeling is that we either need to remove it or fix it up.
>
> Any thoughts?
Given its status, I'm all for removing it.
Cheers,
Emilio
signature.asc
Description: OpenPGP digital signature
Hi Steffen,
Steffen Joeris wrote:
> Thanks to Kees, I have prepared a list of packages (below) that are still
> using the deprecated functions.
Can you post a dd-list? Your list doesn't include uploaders so it's easy to miss
team maintained packages.
Thanks,
Emilio
signature.asc
Description:
Dominic Hargreaves wrote:
> Not only that, but weak-library-dev-dependency and
> not-binnmuable-all-depends-any seem to be fighting! The latter suggests
> Depends: arch_any (>= ${source:Version}), arch_any (<< ${source:Version}.1~)
> which triggers the former...
>
> What's correct in this case?
Y
Steve Langasek wrote:
> On Wed, Nov 04, 2009 at 01:15:57AM +0100, Joerg Jaspert wrote:
>>> E: ftp-master: section-is-dh_make-template
>>> Sections in source packages have minimal impact; the section that matters is
>>> the one specified in the archive override. There's no reason that the
>>> inval
Joerg Jaspert wrote:
> On 11921 March 1977, Steve Langasek wrote:
>> E: ftp-master: debian-rules-is-symlink
>> Not a requirement that's derived from Policy at all. If you think this is
>> important to require for all packages due to the side effect on lintian's
>> ability to do further checking, p
Dmitry E. Oboukhov wrote:
> reassign 554694 qt4-qmake
> retitle 554694 qt4-qmake generates a makefile which is incompatible with
> binutils-gold
> thanks
>
> Hi, Peter.
>
> Goldendict are built by qt4-qmake. I think that You should report
> about such projects in qt4-qmake package, because just
Hello,
Luk Claes wrote:
> Hi
>
> Currently there are 4 rather big transitions going on, none of which is
> ready to transition. Following are the things that currently are an
> issue or that show why the 4 transitions are coupled:
[...]
> - gnome-main-menu should use libslab otherwise it preven
Hi,
Jakub Wilk wrote:
> I am going to file a few dozens of bugs against packages that are embedding
> copies of Python modules; more specifically:
> - modules available as separate Debian packages: argparse, beautifulsoup,
> clientform, coherence, configobj, elementtree, feedparser, mechanize,
> p
Benjamin Drung wrote:
> Hi,
>
> I got some FTBFS with binutils-gold bug reports. How can I build my
> packages using binutils-gold? What do I have to change for that?
Just install it and then build your package (it diverts the linker so you just
need to install it).
Cheers,
Emilio
signature.a
Thomas Goirand wrote:
> Steve Langasek wrote:
>> In this scenario, with Recommends installed by default (the only sane
>> model), the vast majority of metapackage dependencies are moved from Depends
>> to Recommends, so you can remove those Recommends manually without forcing
>> removal of the meta
Jari Aalto wrote:
> In latest lintian, a message was added that warned about missing
>
> debian/REAADME.source
>
> in order to document the used patch system (dpatch, quilt etc.). It
> could have been be argued that this information were already available
> in the manual pages.
That's why #5
> Debian GNOME Maintainers <[EMAIL PROTECTED]>
>libgda3 (U)
libgda3 has been fixed in unstable with high urgency. Needs unblocking.
> Debian Python Modules Team <[EMAIL PROTECTED]>
>matplotlib
Seems to be fixed in t-p-u, but hasn't migrated to testing yet. [1] says
"Unblock request by lu
Package: wnpp
Severity: wishlist
Owner: Emilio Pozuelo Monfort <[EMAIL PROTECTED]>
* Package name: seahorse-plugins
Version : 2.24.1
Upstream Author : Jacob Perkins <[EMAIL PROTECTED]>
Jose Carlos Garcia Sogo <[EMAIL PROTECTED]>
Eugene V. Lyubimkin wrote:
> Michelle Konzack wrote:
>> ..because I do not use GNOME and KDE and it does not suck several
>> 100 MByte of useless GNOME and KDE libs!
> 'evince-gtk' package pulls much less dependencies, I am using it with XFCE.
Since 2.24 (which is in experimental) the evinc
Romain Beauxis wrote:
> Le Wednesday 03 December 2008 12:07:51 Cyril Brulebois, vous avez écrit :
>> Romain Beauxis <[EMAIL PROTECTED]> (03/12/2008):
>>> I've always wondered why it is not possible to add meta information to
>>> an upload.
>>> […]
>>> In these cases, it would be nice to add an anno
Package: wnpp
Severity: wishlist
Owner: Emilio Pozuelo Monfort
* Package name: libproxy
Version : 0.2.3
Upstream Author : Nathaniel McCallum
Alex Panait
* URL : http://code.google.com/p/libproxy/
* License : LGPL
Programming
Hi Florian,
Thanks for your concerns. I appreciate it.
Florian Weimer wrote:
> Not enabling WPAD with DNS devolution goes a long way towards dealing
> with this mess.
Would you be fine if libproxy disabled WPAD by default? I think libproxy's
developers are willing to do that, according to [1].
Nikita V. Youshchenko wrote:
> Hi
Hello,
> 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
Hi Florian, and sorry for the long delay.
Florian Weimer wrote:
> Well, it's not my package, so you don't have to listen to me. I'm
> also not speaking for the security team.
Oh, should you have said that before, I'd have ignored all your comments :P
> But I appreciate your
> efforts to address
Sandro Tosi wrote:
> On Fri, Jan 9, 2009 at 10:52, Don Armstrong wrote:
>> Actually, if you're interested in maintaining it, I'd be happy to see
>> it deployed on the master BTS server. I suppose it can live on merkel
>> for the time being until you're ready to migrate it, but having it
>> under t
racker is now at
bugzilla.gnome.org. Unmarked as forwarded as I couldn't find a relevant bug in
the GNOME bugzilla.
>scrollkeeper (U)
Fixed by James Vega.
>update-manager
> Emilio Pozuelo Monfort
>update-manager (U)
> E: pkg=update-manager, bug=415376, msg=Par
Ondrej Certik wrote:
> This whohas command is awesome, great job!
Yes. And the openSUSE URLs suck!
Emilio
signature.asc
Description: OpenPGP digital signature
Paul Wise wrote:
> On Sun, Jan 25, 2009 at 9:37 AM, Emilio Pozuelo Monfort
> wrote:
>> Ondrej Certik wrote:
>>> This whohas command is awesome, great job!
>> Yes. And the openSUSE URLs suck!
>
> Please file a bug. I'm surprised you sent that mail instead
Luis Rodrigo Gallardo Cruz wrote:
> tag 446050 help
> thanks
>
> The current version of liferea in Debian unstable (1.4.3-1), as well
> as the latest upstream version (1.4.5) fail if used together with
> libsqlite3-0 from experimental (3.5.1-1). The program works correctly
> with the versions in t
On 17/01/10 22:57, Jonas Smedegaard wrote:
Hi fellow developers,
I am worried if perhaps Paul Dwerryhouse is
Missing In Action.
Have you tried to contact him directly? If not, try to do so, and if he doesn't
answer in some time, notify the MIA team.
Cheers,
Emilio
--
To UNSUBSCRIBE, emai
On 07/02/10 21:30, Ana Guerrero wrote:
>> Debian Qt/KDE Maintainers
>>kdeartwork
>>kdebindings
>>kdeedu
>>kdepim
>>
>
> These are all metapackages.
> BTW, I wonder why you listed only those from KDE and not for example
> kdegames that is similar (KDE metapackage installing all th
ño Mendoza
jigzo
A Mennucc1
mplayer (U)
waili
Martin Meredith
w3cam
Andreas Metzler
enblend-enfuse (U)
hugin (U)
libpano13 (U)
sdop
Samuel Mimram
xmoto (U)
Loic Minier
gst-plugins-good0.10 (U)
libquicktime (U)
libwmf
Kartik Mistry
ayttm
Steffen Moelle
On 22/02/10 15:54, jida...@jidanni.org wrote:
> Many executables in .../sbin have their man pages in section 1 instead
> of section 8.
>
> Perhaps a piuparts like script could comb over the apt-file search
> results to target them.
This could rather be a lintian check.
Emilio
--
To UNSUBSCRI
On 02/03/10 11:05, Raphael Hertzog wrote:
> On Wed, 11 Nov 2009, Stefano Zacchiroli wrote:
>> What is the stance of dpkg-dev maintainers on this?
>
> I think it's ok. But some more feedback would be welcome, CCing -devel for
> this.
The substvars approach sounds good to me. I think I'd use it qui
On 07/03/10 19:06, Jonathan Yu wrote:
> Who is using arch-perl?
>
> 1. It has many reverse-dependencies
> Reverse Depends:
> axp
> archzoom
> archway
> axp
> archzoom
> archway
Well, those are repeated so they are not that many.
Maybe you can remove those three packages together with
On 09/04/10 10:05, Toni Mueller wrote:
> I suggest that updates to taxbird and its dependencies are provided via
> volatile.
Why do you mail -devel and not taxb...@p.d.o or the maintainer or the bts?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscrib
On 03/05/10 10:46, Tollef Fog Heen wrote:
> ]] Mikhail Gusarov
> | And GNOME developers insistance (so applications developers may
> | blindly include gtk+2.0.pc and get all the stack).
>
> Yes, historical baggage, basically.
Sorry I don't know what you're talking about. If you can explain it I'
Hi,
On 11/05/10 10:13, Reinhard Tartler wrote:
> [1] http://experimental.ftbfs.de/chromium-browser (unavailable at time
> of writing)
Experimental is now on buildd.d.o, see
https://buildd.debian.org/status/package.php?p=chromium-browser&suite=experimental
Cheers,
Emilio
--
To UNSUBSCRIBE,
On 25/05/10 23:45, Petter Reinholdtsen wrote:
> What about reverting this change in dash until after Squeeze is
> released? Now seem like a bad time to make thousand of packages in
> Debian fail to build from source. :)
See bug #582952.
Emilio
--
To UNSUBSCRIBE, email to debian-devel-requ...@
On 25/05/10 23:13, Raphael Geissert wrote:
> Normally I would process the results and file the bug reports myself but I
> don't have and won't have time to do it any time soon. I've already tried to
> find some time yesterday and today to work on checkbashisms to come up with
> bug
> fixes[4],
On 26/05/10 08:07, Lucas Nussbaum wrote:
> On 25/05/10 at 23:10 +0100, Neil Williams wrote:
>> 124 source packages. Bad, but not as crazy as 1,540.
>>
>> (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a
>> stretch.)
>
> No. 124 is the number of packages that failed to build.
On 26/05/10 13:14, Lucas Nussbaum wrote:
> On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote:
>> Right. That's exactly why I suggested debdiffing the resulting binary
>> packages
>> from a new and an old dash.
>
> Are you volunteering? :-)
No. I
On 14/06/10 09:36, Raphael Hertzog wrote:
> I hope we can find maintainers for all those. Should they be maintained
> within the Debian Gnome team ?
No. They are not GNOME modules and we're already quite loaded.
Cheers,
Emilio
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
w
On 16/08/10 02:01, Russ Allbery wrote:
> gregor herrmann writes:
>
>> Among the contents are e.g. ~20.000 lines saying:
>> (firefox-bin:28026): Gdk-WARNING **: XID collision, trouble ahead
>
> I tracked this down at one point and decided that this was the fault of
> Adobe's Flash player rath
On 18/08/10 11:15, Goswin von Brederlow wrote:
> The checks
> in glib seem good enough to handle such cases sanely so maybe the glib
> could be shut up about them for stable releases (or where users just
> don't care). Maybe something like setting GLIB_BE_SILENT or so if
> recompiling the lib silen
On 18/08/10 14:53, Peter Miller wrote:
> So have gtk_assert (or whatever it is) actually call abort() and make
> the offending applications crash, so the offending developers *have* to
> fix them. But until you do that, give me a way to Shut Them Off, and
> without silencing *real* error messages,
Package: wnpp
Severity: wishlist
Owner: Emilio Pozuelo Monfort
* Package name: gsettings-desktop-schemas
Version : 0.1.1
Upstream Author : Vincent Untz
Ryan Lortie
* URL : http://download.gnome.org/sources/gsettings-desktop-schemas/
* License
Package: wnpp
Severity: wishlist
Owner: Emilio Pozuelo Monfort
* Package name: glib-networking
Version : 2.27.4
* URL : http://www.gnome.org/
* License : LGPL 2+
Programming Lang: C
Description : network-related giomodules for GLib
This package
On 14/02/11 17:36, Joachim Breitner wrote:
> Also, for link-monitor-applet, I need to find out whether gob2 needs to
> be updated. But it seems that GTK-3 still uses GLib-2, so this might
> work.
There's no GLib 3.
Emilio
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
1 - 100 of 281 matches
Mail list logo
