Bug#796987: Updated package looking for sponsor.
I have created a package for pidgin-sipe 1.20.0, which is now looking for a sponsor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797502 signature.asc Description: OpenPGP digital signature
Bug#790409: eclipse-pydev: pydev is not recognized by eclipse anymore
Hi Markus, On 06/30/2015 12:26 AM, Markus Koschany wrote: > Hence I would like to suggest that we aim for a solution with the > current version of bnd 1.5.0 in unstable. I think bnd isn't the real > blocker. Your fix for bnd 2.1.0 will not be in vain. It's good to know > that those packages work with the newer version of bnd. If you agree, we > could make all affected packages work with bnd 1.5.0, which should be > trivial, and get this bug here fixed as soon as possible. okay, switching back to bnd 1.5 will not cause much trouble. I'll soon start RFS'ing all the missing pieces needed for bringing Pydev back into working state. Regards, Jakub signature.asc Description: OpenPGP digital signature
Bug#790409: eclipse-pydev: pydev is not recognized by eclipse anymore
Hi Markus, On Mon, 29 Jun 2015 19:17:19 +0200 Markus Koschany wrote: > I saw that Jakub Adam already changed the build-dependencies and dependencies > in eclipse-pydev but I don't know what else is required to fix this > issue. If someone else does, please let us know. Some of the new dependencies are missing OSGi metadata in their manifests, which are needed in order for them to be usable in Eclipse. I use bnd to generate the metadata at build time and have pushed the necessary changes to the java packages in question. Because bnd is now in a process of being updated, I made my changes already compatible with the bnd version in experimental. So, the best way you could help is to finish the transition and get bnd 2.1 into sid. Once this is done, I'll start issuing sponsorship requests for all the components needed to get Pydev working again. If there is something blocking the bnd upload, please let me know. Regards, Jakub signature.asc Description: OpenPGP digital signature
Bug#747054: FTBFS: package javax.servlet.http does not exist
Hi, I've rebuilt eclipse package in current sid using pbuilder and didn't encounter any error. Can someone please confirm this bug is still relevant? Regards, Jakub -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728802: calendar-exchange-provider: Impossible to connect to exchange calendar after 24.0 upgrade (it connect but calendar is RO)
Hi, On 5.11.2013 18:13, Eric Valette wrote: Running tb 24.1, lightning 2.6.2 and calendar-exchange-provider 3.2.0-beta57 on a windows VM on the same machine works with same settings. Where did you come to beta57? The latest tarball I see available for download is beta52 and in git is beta53. Could you update icedove, iceowl-extension and calendar-exchange-provider to the same version. I've packaged ~beta53 that declares it's compatible with TB 24.0 [1] and contacted my sponsor. He is quite fast with reviewing so hopefully this time it won't be an exception. The upload will be into experimental (that's where Icedove 24.0 is). Is icedove 24.0 really TB 24.0 or 24.0.1 because 24.0.1 requires lightning 2.6.1 and 24.1 requires lightning 2.6.2... AFAIK icedove and iceowl-extension are built from the very same source tarball, so there shouldn't arise any version incompatibilities between these two. Regards, Jakub [1] https://mentors.debian.net/package/calendar-exchange-provider -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723776: androidsdk-tools: FTBFS with perl 5.18: POD errors
Hi Damyan, this is already fixed in the new version uploaded into sid yesterday. Regards, Jakub -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#642199: Currently working with NSS_SSL_CBC_RANDOM_IV=0 workaround
Hi Dominique, > Since a workaround is available, the 'grave' severity of this bug is not > justified. I'll downgrade it to important unless someone objects (with > arguments) I agree we can downgrade the severity. Please note that because of this bug pidgin-sipe is right now on the list of candidates for removal from testing[1], so please make the change happen before Friday the 26th of October! Some time ago I opened a ticket in Pidgin upstream proposing a solution for this bug[2], without any response yet. We will have to live with the workaround for now. Regards, Jakub [1] https://lists.debian.org/debian-devel/2012/10/msg00373.html [2] https://developer.pidgin.im/ticket/15247 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689527: Circular build dependency between eclipse-mylyn and eclipse-egit
Package: src:eclipse-mylyn Version: 3.8.0-1 Severity: serious eclipse-mylyn FTBFS with following error: dpkg-source: error: failed to copy eclipse-mylyn/.pc/rebuild-prepare-install-profile-job-3-6.patch/org.eclipse.mylyn.commons/org.eclipse.mylyn.discovery.ui/src-e3.6/org/eclipse/mylyn/internal/discovery/ui/PrepareInstallProfileJob_e_3_6.java to eclipse-mylyn/org.eclipse.mylyn.commons/org.eclipse.mylyn.discovery.ui/src-e3.6/org/eclipse/mylyn/internal/discovery/ui/PrepareInstallProfileJob_e_3_6.java: No such file or directory dpkg-source: info: unapplying rebuild-prepare-install-profile-job-3-6.patch dpkg-buildpackage: error: dpkg-source --after-build eclipse-mylyn gave error exit status 2 This is caused by dpkg bug #683547. rebuild-prepare-install-profile-job-3-6.patch could be rewritten so that the dpkg problem doesn't affect it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689452: Circular build dependency between eclipse-mylyn and eclipse-egit
Package: src:eclipse-mylyn Version: 3.8.0-1 Severity: serious There is a circular build dependency between eclipse-mylyn and eclipse-egit. This can introduce problems when rebuilding the packages. This dependency should be avoided. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684604: eclipse-rcp: eclipse 3.8 hangs on splash screen with "Loading Workbench" after update from 3.7.2
Hi Felix, Thanks for all the information you provided so far. I spent some time studying the logs but couldn't make any final conclusion. All of the required packages you have installed seem to be at their latest versions and I didn't find any fatal error related to bundle loading in your debug logs. Thinking of it more, maybe there is nothing wrong with the installation, but there is something in your workspace that makes Eclipse hang during startup (but also it doesn't affect 4.2 binary tarball). When you run without ~/.eclipse do you see a workspace selection popup? If so, can you please try to create a new empty workspace and look if Eclipse will start then? If it happens that it's your current workspace that causes the hang on startup, are you able to put somewhere for download a stripped down version? I think only the .metadata folder will be sufficient, no projects that might contain private of confidential data. Please check that the hang still occurs with the stripped workspace before uploading. Regards, Jakub -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684604: eclipse-rcp: eclipse 3.8 hangs on splash screen with "Loading Workbench" after update from 3.7.2
Hi Felix, On 19.8.2012 19:31, Felix Natter wrote: I'd really like to help you, but this file: /usr/lib/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info is not there any more. It will be back when you reinstall eclipse-platform. That you are missing it right now is a good sign, means you will get correct version from the latest package when installed and we don't have to care about its content. You shouldn't ever run eclipse as root of course, or it will be overwritten. BTW, what do you have in /etc/eclipse.ini? To make things easier for me, here are the versions of *all* installed packages (of course some packages have been removed when I removed the eclipse packages): http://pastebin.com/9cHJaj5J Thanks for the list, but please reinstall eclipse-platform and make a new one, current is missing many packages as you noted. I assume you use 4.2 tarball from eclipse.org, so reinstalling distribution Eclipse will not interfere with your work environment. Use 'dpkg --list' to create the list, it will be easier for me to compare. Do you have any additional plugins installed? Yes, I installed "saferefactor" from here: http://dsc.ufcg.edu.br/~spg/saferefactor/ I assume you installed it from the update site as regular user, so running Eclipse without ~/.eclipse eliminates its possible influence on the configuration. You already tried this, so I doubt the extra plugin is a source of the problem. Many thanks, Jakub -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684604: eclipse-rcp: eclipse 3.8 hangs on splash screen with "Loading Workbench" after update from 3.7.2
Hi Felix, On 19.8.2012 17:33, Felix Natter wrote: Meanwhile I read this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681726 and decided to give "Juno" 4.2 a try. This seems to work fine right now :-) Just to make it clear, that bug is a wishlist item. Wheezy release is now frozen so 4.2 will NOT make it into Debian until the next stable release is made (a horizon of months) and it was never in our plan for Wheezy, as all the plugins we have packaged run the same on Eclipse 3.8 (now the deprecated platform). !MESSAGE The artifact file for osgi.bundle,javax.servlet,2.5.0.v200806031605 was not found. Thanks a lot for your help, unfortunately I didn't receive it in time (my own fault), and I am happy with 4.2 :-) I'll close this report soon then. I tried to reproduce the problem, but without success. It could be your local configuration issue, but also it's possible the bug is still there affecting other users and might even persist into 4.2 release if not fixed properly. Anyway, if you could still provide some of the information I asked previously, you would be much helpful. I can't force you of course :) Regards, Jakub -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684604: eclipse-rcp: eclipse 3.8 hangs on splash screen with "Loading Workbench" after update from 3.7.2
Hi Felix, !MESSAGE The artifact file for osgi.bundle,javax.servlet,2.5.0.v200806031605 was not found. This should not happen, Eclipse 3.8 uses javax.servlet 3.0.0. Please paste here the contents of your /usr/lib/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info Maybe it wasn't updated for some reason. Also please create an .options file somewhere, with following contents: org.eclipse.equinox.p2.core/debug=true org.eclipse.equinox.p2.core/reconciler=true org.eclipse.equinox.p2.core/installregistry=true org.eclipse.eclipse.p2.engine/engine/debug=true osgi.checkConfiguration=true org.eclipse.osgi/debug=true Then run eclipse *from the same directory* where .options is placed, with these arguments: /usr/lib/eclipse/eclipse -consoleLog -debug This should produce more debug information. Start with empty ~/.eclipse. Please check if you have installed the latest version of libservlet3.0-java from Debian testing. Even better if you can get a list of all dependencies of eclipse-rcp package and installed versions. Do you have any additional plugins installed? Also check /usr/lib/eclipse/plugins for any broken symlinks. Regards Jakub -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677974: eclipse-egit: FTBFS with eclipse 3.8.0 (git version)
Hi Niels, in your build log I see: dpkg-buildpackage: source package eclipse-egit dpkg-buildpackage: source version 1.1.0-1 dpkg-buildpackage: source changed by Jakub Adam Why are you using such an old version? Current eclipse-egit in sid is 1.3.0-1, I tried to compile it with eclipse 3.8.0 and it builds without problems. Obviously your build failure is because in sid there is libjgit-java 1.3.0-2, but eclipse-egit 1.1.0-1 requires also 1.1.0 jgit. Regards, Jakub -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670756: Tuxguitar does not start
Hi Tony, On 16.5.2012 17:01, tony mancill wrote: In any event, I'm still able to run tuxguitar on sid with both 3.5 and 3 packages installed, so I'm not convinced we've ironed out the precise cause of the bug. Ok, I will try to describe it more thoroughly: The direct cause of crash is that required JNI library libswt-cairo-gtk-3555.so (from package libswt-cairo-gtk-3.5-jni) is not installed when it has to be. On a clean system where neither SWT nor tuxguitar is installed we can get into this situation with following sequence of events: (1) Install tuxguitar: $ apt-get install tuxguitar Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libswt-cairo-gtk-3-jni libswt-gtk-3-java Suggested packages: libswt-gtk-3-java-gcj tuxguitar-jsa lilypond Recommended packages: tuxguitar-alsa tuxguitar-oss The following NEW packages will be installed: libswt-cairo-gtk-3-jni libswt-gtk-3-java tuxguitar 0 upgraded, 3 newly installed, 0 to remove and 15 not upgraded. ... Setting up libswt-gtk-3-java (3.7.2-2) ... update-alternatives: using /usr/share/java/swt-gtk-3.7.jar to provide /usr/share/java/swt.jar (swt.jar) in auto mode. ... Now we have libswt-gtk-3-java, libswt-cairo-gtk-3-jni and /usr/share/java/swt.jar is provided by swt-gtk-3.7.jar. So far good, we can successfully launch tuxguitar and it will use SWT 3.7 (2) Now let's add libswt-gtk-3.5-java to the installation $ apt-get install libswt-gtk-3.5-java Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libswt-gtk-3.5-jni Suggested packages: libswt-gtk-3.5-java-gcj libswt-gnome-gtk-3.5-jni The following NEW packages will be installed: libswt-gtk-3.5-java libswt-gtk-3.5-jni 0 upgraded, 2 newly installed, 0 to remove and 15 not upgraded. ... We have libswt-gtk-3.5-java installed, *BUT NOT* libswt-cairo-gtk-3.5-jni and /usr/share/java/swt.jar is symlinked to swt-gtk-3.5.1.jar. When you now try to start tuxguitar, it will use SWT 3.5 and crashes with exception we already know from Grant: Exception in thread "main" org.eclipse.swt.SWTException: Unable to load graphics library [Cairo is required] (java.lang.UnsatisfiedLinkError: no swt-cairo-gtk-3555 or swt-cairo-gtk in swt.library.path, java.library.path or the jar file) (3) To fix this, we can manually install libswt-cairo-gtk-3.5-jni. Then tuxguitar finally runs also with SWT 3.5 - this is most probably your (Tony's) situation, when you have both SWTs and application is working: ||/ NameVersion Description +++-===-===- ii libswt-cairo-gtk-3-jni 3.7.2-2 Standard Widget Toolkit for GTK+ Cairo JNI library ii libswt-cairo-gtk-3.5-jni3.5.1-2.1 Standard Widget Toolkit for GTK+ Cairo JNI library un libswt-gnome-gtk-3-jni(no description available) un libswt-gnome-gtk-3.5-jni (no description available) ii libswt-gtk-3-java 3.7.2-2 Standard Widget Toolkit for GTK+ Java library un libswt-gtk-3-java-gcj (no description available) ii libswt-gtk-3-jni3.7.2-2 Standard Widget Toolkit for GTK+ JNI library ii libswt-gtk-3.5-java 3.5.1-2.1 Standard Widget Toolkit for GTK+ Java library un libswt-gtk-3.5-java-gcj (no description available) ii libswt-gtk-3.5-jni 3.5.1-2.1 Standard Widget Toolkit for GTK+ JNI library ii libswt-webkit-gtk-3-jni 3.7.2-2 Standard Widget Toolkit for GTK+ WebKit JNI library It's that tuxguitar sometimes needs libswt-cairo-gtk-3.5-jni, but it's not depending on it in any way. Do you see where is the problem now or did I confuse you even more? :) So I think we would have to change its Depends to something like: Depends: libswt-gtk-3-java | libswt-gtk-3.5-java, libswt-cairo-gtk-3-jni | libswt-cairo-gtk-3.5-jni, ... etc That change to depends won't have the desired effect. All that expresses is "either libswt-gtk-3-java or libswt-gtk-3.5-java or both" which is what we are trying to avoid. I believe you want to express an exclusive (XOR) in there - one or other, but not both. You are right, my change is not sufficient. XOR might work, but I'm not sure if this can be expressed in Depends. When you say "get rid of the alternatives," I'm not sure what you mean. Tuxguitar only lists the following swt dependencies: libswt-gtk-3-java, libswt-cairo-gtk-3-jni, and libswt-webkit-gtk-3-jni. It sounds like we might be back to conflicting with libswt-gtk-3
Bug#670756: Tuxguitar does not start
On 15.5.2012 07:52, Niels Thykier wrote: On 2012-05-15 06:38, tony mancill wrote: On 05/14/2012 08:18 AM, Jakub Adam wrote: In my opinion libswt-gtk-3.5-java and libswt-3-gtk-java are not in conflict, generally it's ok to have them installed both. The problem is in tuxguitar package itself which will not work with SWT 3.5. So I suggest that we make tuxguitar to conflict with libswt-gtk-3.5-java (and maybe also with libswt-gtk-3.4-java and libswt-gtk-3.6-java I see in Grant's package list too). Hi Jakub, There are times in the past when tuxguitar explicitly depended on libswt-gtk-3.5-jar, so it seems odd to say that tuxguitar won't work with it. What seems to be the case is that tuxguitar won't work when both -3.5 and -3 packages are install. Sorry, I was wrong with my statement. I thought libswt-cairo-gtk-3555.so was for some reason not built in swt-gtk 3.5, but I missed it is packaged separately in libswt-cairo-gtk-3.5-jni. I believe that swt uses alternatives for the swt.jar, so if you have an older version of libswt-*-java providing the alternative without (all) the relevant -jni package => "boom". Now that should not be possible to do, but it is... """ un libswt-gnome-gtk-3.5-jni [...] un libswt-gnome-gtk-3.6-jni [...] [...] ii libswt-gtk-3.5-java 3.5.1-5 [...] ii libswt-gtk-3.6-java 3.6.2-1 [...] """ Presumably the dependency relations on the old -jni packages (or on the old -java packages) are not strong enough. I'd like to note that even the most recent libswt-gtk-3-java doesn't have a strong dependency on all its -jni packages. For example libswt-cairo-gtk-3-jni is neither a dependency nor a suggestion in any other package created from swt-gtk (except -gcj which is not relevant in this case I suppose). If it was meant to be changed in the past, presumably it wasn't done. I don't think this is something wrong, as it allows to install only what is really needed, as long as applications list all the -jni packages they require. Tuxguitar does this, but only for libswt-gtk-3-java and doesn't expect that any alternative can be present, therefore it may crash. So I think we would have to change its Depends to something like: Depends: libswt-gtk-3-java | libswt-gtk-3.5-java, libswt-cairo-gtk-3-jni | libswt-cairo-gtk-3.5-jni, ... etc ... or get rid of the alternatives. Personally, I think the swt alternatives is... "weird" at best. So I would vote for breaking the old packages to force their removal and then remove the usage of alternatives in Wheezy+1. I support this -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670756: Tuxguitar does not start
In my opinion libswt-gtk-3.5-java and libswt-3-gtk-java are not in conflict, generally it's ok to have them installed both. The problem is in tuxguitar package itself which will not work with SWT 3.5. So I suggest that we make tuxguitar to conflict with libswt-gtk-3.5-java (and maybe also with libswt-gtk-3.4-java and libswt-gtk-3.6-java I see in Grant's package list too). On 14.5.2012 06:08, Grant Diffey wrote: so my installed package list is nevyn@cetacea:~$ dpkg -l libswt* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii libswt-cairo-gtk-3-jni 3.7.2-2 Standard Widget Toolkit for GTK+ Cairo JNI library ii libswt-glx-gtk-3-jni3.7.2-2 Standard Widget Toolkit for GTK+ GLX JNI library ii libswt-gnome-gtk-3-jni 3.7.2-2 Standard Widget Toolkit for GTK+ GNOME JNI library un libswt-gnome-gtk-3.5-jni (no description available) un libswt-gnome-gtk-3.6-jni (no description available) ii libswt-gtk-3-java 3.7.2-2 Standard Widget Toolkit for GTK+ Java library un libswt-gtk-3-java-gcj (no description available) ii libswt-gtk-3-jni3.7.2-2 Standard Widget Toolkit for GTK+ JNI library un libswt-gtk-3.4-java (no description available) un libswt-gtk-3.4-jni (no description available) ii libswt-gtk-3.5-java 3.5.1-5 Standard Widget Toolkit for GTK+ Java library un libswt-gtk-3.5-java-gcj (no description available) ii libswt-gtk-3.5-jni 3.5.1-5 Standard Widget Toolkit for GTK+ JNI library ii libswt-gtk-3.6-java 3.6.2-1 Standard Widget Toolkit for GTK+ Java library un libswt-gtk-3.6-java-gcj (no description available) ii libswt-gtk-3.6-jni 3.6.2-1 Standard Widget Toolkit for GTK+ JNI library ii libswt-webkit-gtk-3-jni 3.7.2-2 Standard Widget Toolkit for GTK+ WebKit JNI library un libswt3.2-gtk-gcj (no description available) un libswt3.2-gtk-java (no description available) un libswt3.2-gtk-jni (no description available) so yes ii libswt-gtk-3.5-jni 3.5.1-5 Standard Widget Toolkit for GTK+ JNI library is installed. if this breaks with the new version of libswt-3-gtk-java should it not conflict? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670756: Tuxguitar does not start
Hi Grant, from the fact that SWT is looking for swt-cairo-gtk-3555 I suspect you have still libswt-gtk-3.5-java and libswt-gtk-3.5-java-jni installed. Removing these packages should solve the problem. Regards, Jakub -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662976: [sat4j] Delay sat4j 2.3.1-1 transition to testing - breaks eclipse plugins
Package: sat4j Version: 2.3.1-1 Severity: serious --- Please enter the report below this line. --- Eclipse running with sat4j 2.3.1-1 will not load any plugins[1]. Problem has to be fixed in eclipse package, this bug is only to prevent new sat4j to enter testing prematurely. Once my update for eclipse is in place, I will close it. Regards Jakub [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662153 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#638693: Packaging dita-ot
Hi, during my work on packaging eclipse-wtp[1] I went into a need to package dita-ot[2] to be able to rebuild eclipse html help from DITA files. I never used this tool before and my sole purpose of its packaging is to have it as eclipse-wtp's build-dep which works for me well now, but I found that there is an existing dita-ot RFP[3] which is marked as blocking another bugreport[4]. So before my RFS, I'd like to give people involved in [3] and [4] a chance to review the package if in its current shape is usable for them or needs further improvements. It is available in pkg-java git[5]. Regards, Jakub [1] http://eclipse.org/webtools [2] http://dita-ot.sourceforge.net [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555635 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638693 [5] http://anonscm.debian.org/gitweb/?p=pkg-java/dita-ot.git -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
