Bug#887595: RFS: xft/2.3.2-1.1 [NMU]
Hi Hugh, On Thu, Jan 18, 2018 at 10:43:01 +, Hugh McMaster wrote: > Changes since the last upload: > * Non-maintainer upload. > * debian/control: > - Mark libxft-dev Multi-Arch: same (Closes: #884176). > IMO this is nothing that warrants a NMU, or an upload on its own. Cheers, Julien
Bug#856603: RFS: arc-theme/20170302-1
On Fri, Mar 31, 2017 at 16:57:18 +, Gianfranco Costamagna wrote: > Hello, > > > >> 3.22.9-1 is a whole new upstream release, with changes that actively break > >> unrelated packages. As you just mentioned, it does at least require themes > >> to be updated, and, as usual for GTK 3 new releases, probably a bunch of > >> gtk-3 using programs as well. > > > >That's not usual for point releases, in this case a bad change slipped > >through. > >That has been fixed in 3.22.9-3. > >That bug was introduced in 3.22.9, it doesn't affect 3.22.8. So no, nothing > >needs to go through tpu. > > > >BTW thanks for the notice about this regression. > > > so, now that 3.22.11 is going to go in testing... can we upload this one? > If something was not appropriate 2 months ago, it is even less so now... Cheers, Julien
Bug#790412: RFS: circus/0.12.0-1
On Thu, Jul 2, 2015 at 15:11:34 +0500, Andrey Rahmatullin wrote: On Thu, Jul 02, 2015 at 09:36:59AM +0200, David Douard wrote: Version : 0.12.0-1 I think the common practice is to bump the version after a ftp-team reject. Yes, but i've discussed this Julien (jcristau) and we thought it was simpler to keep the same version, since I've modified the Files-Excluded field of the debian/copyright (thus the orig tarball). I'm not sure what's the reasoning behind this. If the version was changed to 0.12.0+dfsg-1 then it would be OK. Maybe there is some misunderstanding here? The reasoning is it saves having to add versionmangle options in d/watch, and I didn't think the version number change was necessary as the previous version was never shipped. Cheers, Julien signature.asc Description: Digital signature
Re: qiime REMOVED from testing
On Tue, Jan 21, 2014 at 19:45:40 +0100, Andreas Tille wrote: Hi, I hope this is the correct list to ask this questions - if not please redirect me (and also please CC me in your reply). [debian-mentors in CC as well - may be some other people have a similar problem.] I know that qiime has a serious bug (#731190) where I was seeking for help six weeks ago with no real result. So I would have expected to become kicked from testing because of this bug which would be fine. However, it is kicked because of an old libffi dependency. I realised that it had in fact libffi6 (= 3.0.4) No, the version that got removed from testing depended on libffi5, which we got rid of. Cheers, Julien signature.asc Description: Digital signature
Bug#673096: Bug#675167: Bug#674850: RM: figlet -- RoQA; license which specifically excludes the right to re-distribute
On Thu, May 31, 2012 at 23:51:51 +0100, Jonathan McCrohan wrote: On 30/05/12 20:05, Julien Cristau wrote: There seems to be just about 0 creative content in that file. What exactly is the problem with it? Figlet 2.2.5 has just been released with the following changelog [1]. That doesn't seem to answer the above question. Cheers, Julien signature.asc Description: Digital signature
Bug#673096: Bug#674850: RM: figlet -- RoQA; license which specifically excludes the right to re-distribute
tag 675167 moreinfo kthxbye On Mon, May 28, 2012 at 08:58:07 +, Bart Martens wrote: Package: ftp.debian.org Severity: normal Please remove figlet 2.2.2-1 from unstable, testing, stable and oldstable. The package contains material that must not be distributed. One example is that the file fonts/8859-3.flc contains a license which specifically excludes the right to re-distribute. There seems to be just about 0 creative content in that file. What exactly is the problem with it? Cheers, Julien -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530190556.ga9...@radis.cristau.org
Re: RFS: libconfig (requires transition)
On Thu, Mar 1, 2012 at 02:34:51 +, Jonathan McCrohan wrote: As far as I can see, sitplus is the only package involved in other transitions. Once the opencv transition is over, am I ok so look for a sponsor to review and upload my package to unstable? Feel free to go ahead now. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#624991: Bug#652826: RFS: logkeys (fixing RC bugs)
Hi Vedran, On Thu, Jan 12, 2012 at 12:18:52 +0100, Vedran Furač wrote: On 12.01.2012 11:21, Alexander Reichle-Schmehl wrote: Hey, since you're DD, and I am not, would you be so kind and sponsor the upload? I am and I would be willing. Could you please provide a package also fixing that RC bug? I'll upload it as soon as I could test it, however so far logkeys fails for me with the following error message: Hey, ok, I'll prepare a package this weekend and let you know. That was a month ago. Any progress? Cheers, Julien signature.asc Description: Digital signature
Re: RFS: libconfig (requires transition)
On Sat, Feb 11, 2012 at 19:21:02 +, Jonathan McCrohan wrote: I have upload a new version of libconfig to mentors, with the following changelog: this change to debian/rules looks weird: - $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp + $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp install the loop around dh_makeshlibs looks kind of crazy too. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: libconfig (requires transition)
On Mon, Jan 30, 2012 at 23:08:17 +, Jonathan McCrohan wrote: This is my first upload which requires a transition, and I am unsure of what happens next. It seems common for packages to be uploaded to experimental for a time prior to the actual transistion to allow other maintainers update their packages accordingly. I was wondering will this be the case with this transition? For the record, we talked on irc, and Jonathan will upload a new version with the -dev package changed to experimental, so reverse deps can be tested against that. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: libconfig (requires transition)
On Sat, Jan 28, 2012 at 15:00:23 +, Jonathan McCrohan wrote: On 27/01/12 19:23, Julien Cristau wrote: On Fri, Jan 27, 2012 at 10:24:56 +, Jonathan McCrohan wrote: Julien Cristau jcris...@debian.org wrote: Please don't change the -dev package name. All of the packages except one have versioned Build-depends on libconfig8-dev. Surely this needs to be replaced with libconfig-dev or at least libconfig9-dev? No it doesn't? You can rename the -dev package to libconfig-dev if you want, but certainly don't *need* to, and if you do it, then it would be way better from our point of view to keep building libconfig8-dev as a transitional package until the reverse deps are updated, and to do that separately from the SONAME bump. If its ok, I'll leave the package as is. Sigh. To clarify, what is the process for this transition? Will the package be uploaded to experimental to allow me to report bug reports and patches against dependant packages? I'm not sure I understand what you're asking. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: libconfig (requires transition)
On Fri, Jan 27, 2012 at 10:24:56 +, Jonathan McCrohan wrote: Julien Cristau jcris...@debian.org wrote: Please don't change the -dev package name. All of the packages except one have versioned Build-depends on libconfig8-dev. Surely this needs to be replaced with libconfig-dev or at least libconfig9-dev? No it doesn't? You can rename the -dev package to libconfig-dev if you want, but certainly don't *need* to, and if you do it, then it would be way better from our point of view to keep building libconfig8-dev as a transitional package until the reverse deps are updated, and to do that separately from the SONAME bump. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: libconfig (requires transition)
On Fri, Jan 27, 2012 at 01:02:57 +, Jonathan McCrohan wrote: Hi Cyril, AFAICT the primary ABI change between these versions is that upstream has depreciated longs and replaced with ints in an effort to standardise lengths across platforms. Assuming updating the Build-depends field in debian/control (to reflect the new package name) is not counted as a source change: Please don't change the -dev package name. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#608220: RFS: hugs98 (NMU, RC bugfix)
On Mon, Jan 17, 2011 at 02:12:18 +0100, Cyril Brulebois wrote: Felix Geyer debfx-...@fobos.de (17/01/2011): I didn't realize that you were talking about the patch itself. Attaching it now. Thanks, sponsored. Thanks for spotting I failed to get it fixed in the first place, too. Unblocked. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: hugs98 (NMU, RC bugfix)
On Sun, Jan 16, 2011 at 16:19:11 -0400, David Bremner wrote: On Sun, 16 Jan 2011 18:08:13 +0100, Felix Geyer debfx-...@fobos.de wrote: I am looking for a sponsor for my NMU of the package hugs98. The upload would fix this RC bug: http://bugs.debian.org/608220 http://mentors.debian.net/debian/pool/main/h/hugs98/hugs98_98.200609.21-5.2.dsc Hi Felix; Please discuss with the release team (in CC) whether your upload is OK for squeeze. If they approve it I (or someone else) can sponsor the NMU. Release team: diffstat is big because autoconf rewrites all of configure. Other than that, the interesting change is --- hugs98-98.200609.21/debian/rules +++ hugs98-98.200609.21/debian/rules @@ -18,6 +18,9 @@ # This has to be exported to make some magic below work. export DH_OPTIONS +# Ensure that LDFLAGS is empty as the build system can't handle commas. +LDFLAGS := + CONFIG_DIRS := . packages/network/ packages/Cabal/tests/HSQL/ \ packages/ALUT/ packages/GLUT/ packages/OpenAL/ \ packages/OpenGL/ src/unix/ That doesn't seem to be the interesting change. Debian's dpkg-buildpackage doesn't set LDFLAGS. Also, why wasn't this sent to the bug? Cheers, Julien signature.asc Description: Digital signature
Re: Bug#608220: RFS: hugs98 (NMU, RC bugfix)
On Sun, Jan 16, 2011 at 23:40:43 +0100, Felix Geyer wrote: I've upload a new version to Debian Mentors without the LDFLAGS change and CCed the bug. Well you've still not sent a patch to the bug, afaict. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome (updated package)
On Tue, Aug 31, 2010 at 15:19:40 +0200, Julien Viard de Galbert wrote: I'm writing to both X Strike Force and Mentors as my previous questions to X strike force [1] did not get any response I'm guessing X Strike Force is too bust with the release and bugs in other packages to mentor a newbie like me. I hope I didn't hurt anyone by doing so. 1: http://lists.debian.org/debian-x/2010/08/msg00290.html Sorry, I missed that mail, will reply to it now. In the future don't hesitate to nag me privately or on irc after some days if you don't get an answer. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: mobile-broadband-provider-info (updated package)
On Thu, Aug 26, 2010 at 13:00:15 +0800, Paul Wise wrote: On Thu, Aug 26, 2010 at 12:37 PM, Bhavani Shankar R bh...@ubuntu.com wrote: The respective updated dsc file can be found at: http://mentors.debian.net/debian/pool/main/m/mobile-broadband-provider-info/mobile-broadband-provider-info_20100824-1.dsc Built and uploaded. Unblocked. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: mobile-broadband-provider-info (updated package)
On Wed, Aug 25, 2010 at 10:50:53 +0530, Bhavani Shankar R wrote: henceforth I am attaching the diff from the present version in sid/squeeze for your kind review Looks ok for a freeze exception. Please let -release know when the package is accepted in the archive. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-qxl
On Fri, May 21, 2010 at 10:05:36 +0800, Liang Guo wrote: On Friday 21 May 2010 04:08:53 Julien Cristau wrote: You're calling dh_prep in debian/rules clean, this is wrong, should be replaced by dh_clean. dh_prep is used in the install target before running make install, and obsoletes 'dh_clean -k', not all invocations of dh_clean. Corrected, Thank you. Could you please check it again ? Uploaded, thanks. Not quite sure how to deal with the 3.0 (quilt) sillyness of deleting the autogen.sh script and moving it to debian/patches/debian-changes-0.0.12-1 during the build (the script is in upstream git, but not in tarballs, so shows up as a diff), but I don't care enough. Cheers, Julien signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-qxl
On Fri, May 21, 2010 at 01:54:45 +0800, Liang Guo wrote: There is a strange file debian/xserver-xorg-video-qxl.debhelper.log in generated package xserver-xorg-video-qxl_0.0.12-1.debian.tar.gz, shoud I remove it? You're calling dh_prep in debian/rules clean, this is wrong, should be replaced by dh_clean. dh_prep is used in the install target before running make install, and obsoletes 'dh_clean -k', not all invocations of dh_clean. Let me know when that's fixed I'll upload the package to the archive (I assume you've tested the driver in a RHEV environment, and it worked for you?). Thanks, Julien signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-qxl
On Thu, May 6, 2010 at 23:19:20 +0800, Liang Guo wrote:
I've upload a new version xserver-xorg-video-qxl to mentor, it can be get
from
http://mentors.debian.net/debian/pool/main/x/xserver-xorg-video-qxl/xserver-
xorg-video-qxl_0.0.12-2.dsc
its git repository is
git://git.debian.org/git/collab-maint/xserver-xorg-video-qxl.git
Hi,
I just had a quick look at the git repo. The packaging looks sane
enough. The git tree is kind of a mess though. It would be nicer IMO
to directly pull from the upstream git tags at
git://anongit.freedesktop.org/git/xorg/driver/xf86-video-qxl, rather
than dump the contents directly. Same goes for debian/xsfbs/ stuff.
Also the code is moved to a versioned xserver-xorg-video-qxl-0.0.12
subdir inside your git tree, which is not the way to go IMO.
debian/patches/series mentions fix_qxl_driver_assert.patch, but that
patch is not in the repo (I assume it's upstream's qxl: remove asserts
that make no sense anymore commit).
Some minor stuff that could be updated for recent changes in other
pkg-xorg drivers:
- rename the build dir from 'obj-$(DEB_BUILD_GNU_TYPE)' to 'build' or
similar, there's no reason to have the build machine type in there
(that's just a cosmetic change)
- update xsfbs.mk to the latest version, build-depend on
xserver-xorg-dev 2:1.7.6.901, and use ${xviddriver:Depends} instead of
${xserver:Depends}. This should allow us to handle ABI changes
without Conflicts/Breaks in the future, see #573371.
- drop the http://xorg.freedesktop.org and mailman urls from
debian/control
Thanks for working on this driver!
Cheers,
Julien
signature.asc
Description: Digital signature
Re: Bug#521918: pbuilder --build --binary-arch invokes 'build' target
On Mon, May 11, 2009 at 13:46:30 +0200, Lionel Elie Mamane wrote: No, policy is very clear on that: if you call the build target, you _must_ satisfy Build-Depends-Indep and Build-Conflicts-Indep: And policy is clearly not followed by any actual practice on this point. So that's as much a bug in policy as anything else (#374029). Cheers, Julien -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#521918: pbuilder --build --binary-arch invokes 'build' target
On Tue, May 5, 2009 at 19:01:41 +0200, Petr Pudlak wrote: Hi, I was trying to attend a reported bug (#521918) of a recently uploaded package 'eprover', but unfortunately I didn't know what to do about it. I've already asked on debian-mentors, but nobody replied. The problem is that if pbuilder is invoked with --binary-arch, it still tries to build the whole project, including the documentation (indep). But the tools required to build the documentation are missing, since they are specified in Build-Depends-Indep:, not in Build-Depends:. It looks to me as if the problem is with pbuilder (or with the tools it's invoking), but of course the problem might as well be my ignorance. The only solution I thought of so far was to put the tools for building the documentation into Build-Depends:, but this seems to me (at least) as improper. Could anyone help me, either by advising how to properly solve the problem, or by pointing out what I'm doing wrong? arch-specific builds run 'debian/rules build $rootcmd debian/rules binary-arch' (where rootcmd is fakeroot or sudo). They can't do anything else, because the build-arch target is (still) not required. Whatever's needed for this needs to be in Build-Depends. Basically the only place you're allowed to use the Build-Depends-Indep stuff is the binary-indep target. There's a long-standing bug on debian-policy about this, IIRC. Cheers, Julien -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: font policy changes
On Thu, Jul 17, 2008 at 00:19:39 -0700, [EMAIL PROTECTED] wrote: What I meant by don't work is that, as you mention, these two options are no-ops. According to the update-fonts-dir(1) man page, these options should not be no-ops: === update-fonts-dir creates a fonts.dir file in an X font directory by invoking mkfontdir(1x) with the appropriate argumentsFor each directory, which is simply the last component of its path (such as '75dpi' or 'misc'), update-fonts-dir will generate either /usr/lib/X11/fonts/directory/fonts.dir or /usr/share/fonts/X11/directory/fonts.dir from the fonts.scale and font files found within it. -7, --x11r7-layout switches the font layout to the one introduced in X11R7: fonts in /usr/share/fonts/X11/directory (default is: fonts in /usr/lib/X11/fonts/directory) === The manpage is outdated. Here are examples of what happens in practice on Etch (4.0r3, i386 DVD install), showing where the man page says the program should look versus what actually happens. Invocation: update-fonts-dir misc Documented Path: /usr/lib/X11/fonts/misc Actual Path: /usr/lib/X11/fonts/misc Status: works as advertised (and complains that /usr/lib/X11/fonts/misc doesn't exist) No. It looks in both the old and the new paths. Did you actually look at the script? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: font policy changes
On Wed, Jul 16, 2008 at 08:37:12 -0700, [EMAIL PROTECTED] wrote: Thank you. I can write a proposed addition to the Policy Manual for TrueType fonts after I'm done with the current package unless someone else wants to do it. The update-fonts-dir utility currently only handles fonts in the X11 tree (not TrueType), and even then the new X11 font directory options to look under /usr/share/fonts/X11/ (-7 and --x11r7-layout) don't work on my stable release (Etch 4.0r3). These options are no-ops. What do you mean by don't work? Also please stop breaking the thread. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: font policy changes
On Sun, Jul 13, 2008 at 22:13:27 -0700, Russ Allbery wrote: [EMAIL PROTECTED] writes: 3) Even if mkfontdir were invoked directly or if it's okay to give update-fonts-dir an absolute path (in which case its man page needs to be updated and the warning removed), isn't it also advisable to run xset fp rehash in postinst and postrm scripts? That program is the standard mechanism for updating installed fonts on recent versions of X11, including in Debian and other GNU/Linux distributions. Hm. That's an interesting thought, although it's going to fail if no X server is currently running, correct? It will always fail, because the user running the script (root) won't normally have access to the X server. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: font policy changes
On Mon, Jul 14, 2008 at 08:50:57 -0700, Russ Allbery wrote: Julien Cristau [EMAIL PROTECTED] writes: It will always fail, because the user running the script (root) won't normally have access to the X server. See, I thought that too, and then I tried it and it seemed to work fine. Maybe my test was wrong? Maybe HOME was still set to the user's home dir? If XAUTHORITY isn't set Xlib looks in $HOME/.Xauthority, so that may work depending how you get root. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457477: devscripts: [tagpending] Did not tag the bug.
On Mon, Dec 24, 2007 at 06:02:35 +0900, Charles Plessy wrote: Also, it is a bit frustrating that unless digging in the logs, it is not possible to know that the operation failed. If the problem is more the configuration of the BTS, could at least DEBEMAIL be used to deliver an error message ? The problem is not bts, or tagpending, or the BTS. The problem is that your MTA is not configured correctly. With exim, which you appear to be using, see /etc/email-addresses. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-snapshot for testing
On Fri, Dec 14, 2007 at 22:38:56 +0300, Dmitry E. Oboukhov wrote: I needed to test the building of one of my packages with gcc4.3. However it turns out that gcc-snapshot from unstable contains the critical bug, which makes impossible using it. At the same time the previous version of the gcc-snapshot deb-package has been already deleted from unstable. As a result I spent two days on building of the previous version of gcc-snapshot (I've got rather slow hardware) in order to make a patch for FTBFS-bug instead of 15 minutes. :) May be it would be better to enable the passing of gcc-snapshot into testing but not to included it in stable releases? It will allow to have a working instrument in such situations. http://snapshot.debian.net/gcc-snapshot Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ntfs-3g (updated package)
[I'm not subscribed to -mentors] On Wed, Aug 8, 2007 at 20:10:41 +0200, Adam Cécile (Le_Vert) wrote: Hmm, I have something crap to ask... As you may have noticed, wxwidget 2.8 is not available in Debian. However Mathias Klose maintain it in Ubuntu... Would you sponsor my wx2.8 ubuntu sync uploads ? I'm really fed up with this situation, but wx is far too complex for me and I don't have any interrest in it. All I want is to have wx2.8 in Debian, so I could update filezilla... What's your aim about this ? Having an ubuntu-maintained package is better than not having it, at least for me... This is so broken it's not even funny. A package needs to be maintained, it needs someone to handle bugs, who is knowledgeable and cares about it. If you aren't prepared to be that person, then advocating something like that is irresponsible and a QA disaster. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help on t-p-u ? Re: gpr in etch is useless: hint 0.12deb ? upload in t-p-u ?
On Tue, Jan 16, 2007 at 17:09:45 +0100, A Mennucc wrote: hi (CC: to d-mentors : I need some help here) Steve Langasek ha scritto: I think in conclusion I would prefer t-p-u for this. I tried it ; I uploaded a package (using dput) ; the first line in debian/changelog was gpr (0.11deb.etch1) testing-proposed-update; urgency=low This should either be testing or testing-proposed-updates. See the section in the dev-ref about uploading to testing: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-t-p-u Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depend on virtual packages
On Tue, Jun 14, 2005 at 14:02:03 +0200, Stefano Zacchiroli wrote: I see no problem with autobuilders and virtual build-dependencies since they're supposed to be configured with just unstable repositories. Actually, I think autobuilders also have an apt source for the incoming directory on ftp-master. This means that between the upload of a new ocaml version and the next dinstall run, there may be two available versions of the virtual package (the old version still in the pool and the new version from incoming). Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
