Bug#611828: ITP: probalign -- multiple sequence alignment using partition function posterior probabilities
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: probalign Version : 1.4 Upstream Author : Usman Roshan * URL : http://cs.njit.edu/usman/probalign/ * License : Public Domain Programming Lang: C++ Description : multiple sequence alignment using partition function posterior probabilities Probalign uses partition function posterior probability estimates to compute maximum expected accuracy multiple sequence alignments. It performs statistically significantly better than the leading alignment programs Probcons v1.1, MAFFT v5.851, and MUSCLE v3.6 on BAliBASE 3.0, HOMSTRAD, and OXBENCH benchmarks. Probalign improvements are largest on datasets containing N/C terminal extensions and on datasets with long and heterogeneous length sequences. On heteregeneous length datasets containing repeats Probalign alignment accuracy is 10% and 15% than the other three methods when standard deviation of length is at least 300 and 400. The package will be maintained by the Debian Med packaging team and is ready for upload at Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/probalign/trunk/?rev=0&sc=0 Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/probalign/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110202163915.4003.65326.report...@mail.an3as.eu
Bug#611928: ITP: mrbayes -- Bayesian Inference of Phylogeny
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: mrbayes Version : 3.1.2 Upstream Author : Fredrik Ronquist * URL : http://mrbayes.sourceforge.net/ * License : GPL Programming Lang: C Description : Bayesian Inference of Phylogeny Bayesian inference of phylogeny is based upon a quantity called the posterior probability distribution of trees, which is the probability of a tree conditioned on the observations. The conditioning is accomplished using Bayes's theorem. The posterior probability distribution of trees is impossible to calculate analytically; instead, MrBayes uses a simulation technique called Markov chain Monte Carlo (or MCMC) to approximate the posterior probabilities of trees. The package will be maintained in the Debian Med team. Packaging stuff is available in SVN: Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/mrbayes/trunk/?rev=0&sc=0 Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/mrbayes/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110203210644.3097.52748.report...@mail.an3as.eu
Bug#612953: ITP: jam-lib -- Java applications look and behave like native applications
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: jam-lib Version : SVN R297 Upstream Author : Andrew Rambaut * URL : http://code.google.com/p/jam-lib/ * License : LGPL-3+ Programming Lang: Java Description : Java applications look and behave like native applications JAM provides classes for building desktop applications that look and behave like native applications. applications created using JAM will look native on Mac, Windows and Linux/UNIX machines. The packaging seems to be ready (modulo asking Debian Java team for checking) and is available at svn://svn.debian.org/svn/debian-med/trunk/packages/libjam-java/trunk/ It could be maintained by Debian Med team because it is a precondition for Java Evolutionary Biology Library. If somebody thinks this in principle not medicine / bio-medicine related package should better go under Debian Java hood that's fine as well. -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (50, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211211742.29440.22970.report...@mail.an3as.eu
Bug#613080: ITP: jebl2 -- Java Evolutionary Biology Library
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: jebl2 Version : SVN R6 Upstream Author : Andrew Rambaut * URL : http://code.google.com/p/jebl2/ * License : LGPL Programming Lang: Java Description : Java Evolutionary Biology Library A Java library for evolutionary biology and bioinformatics, including objects representing biomolecular sequences, multiple sequence alignments and phylogenetic trees. . This is a branch of the original JEBL on http://sourceforge.net/projects/jebl/ to develop a new API and class library. This package will be maintained in the Debian Med team at svn://svn.debian.org/svn/debian-med/trunk/packages/libjebl2-java/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (50, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212171151.8875.48721.report...@mail.an3as.eu
Bug#614278: ITP: figtree -- graphical phylogenetic tree viewer
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: figtree Version : 1.3.1 Upstream Author : Andrew Rambaut * URL : http://code.google.com/p/figtree/ * License : GPL Programming Lang: Java Description : graphical phylogenetic tree viewer FigTree is designed as a graphical viewer of phylogenetic trees and as a program for producing publication-ready figures. In particular it is designed to display summarized and annotated trees produced by BEAST. The package is maintained in the Debian Med team and available in SVN Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/figtree/trunk Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/figtree/trunk/?rev=0&sc=0 -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (50, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110220195609.27831.66720.report...@mail.an3as.eu
Bug#614657: ITP: clonalframe -- inference of bacterial microevolution using multilocus sequence data
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: clonalframe Version : 1.2 Upstream Author : Xavier Didelot * URL : http://www.xavierdidelot.xtreemhost.com/clonalframe.htm * License : GPL Programming Lang: C++ Description : inference of bacterial microevolution using multilocus sequence data ClonalFrame identifies the clonal relationships between the members of a sample, while also estimating the chromosomal position of homologous recombination events that have disrupted the clonal inheritance. . ClonalFrame can be applied to any kind of sequence data, from a single fragment of DNA to whole genomes. It is well suited for the analysis of MLST data, where 7 gene fragments have been sequenced, but becomes progressively more powerful as the sequenced regions increase in length and number up to whole genomes. However, it requires the sequences to be aligned. If you have genomic data that is not aligned, we recommend using Mauve which produces alignment of whole bacterial genomes in exactly the format required for analysis with ClonalFrame. The package will be maintained in Debian Med team and is available at Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/clonalframe/trunk -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (50, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011001737.1629.17186.report...@mail.an3as.eu
Bug#619100: ITP: abacas -- Algorithm Based Automatic Contiguation of Assembled Sequences
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: abacas Version : 1.3.1 Upstream Author : Wellcome Trust Sanger Institute * URL : http://abacas.sourceforge.net/ * License : GPL Programming Lang: Perl Description : Algorithm Based Automatic Contiguation of Assembled Sequences ABACAS is intended to rapidly contiguate (align, order, orientate), visualize and design primers to close gaps on shotgun assembled contigs based on a reference sequence. . ABACAS uses MUMmer to find alignment positions and identify syntenies of assembled contigs against the reference. The output is then processed to generate a pseudomolecule taking overlapping contigs and gaps in to account. ABACAS generates a comparision file that can be used to visualize ordered and oriented contigs in ACT. Synteny is represented by red bars where colour intensity decreases with lower values of percent identity between comparable blocks. Information on contigs such as the orientation, percent identity, coverage and overlap with other contigs can also be visualized by loading the outputted feature file on ACT. The packaging will be done in the Debian Med team and is available in SVN at Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/abacas/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (50, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110321092521.24386.9506.report...@mail.an3as.eu
Re: ITH: xournal
Carlo Segre wrote: > This can > be fixed with a known patch. Can you tell me a source to this patch? > I will be preparing an updated package for upload by the weekend unless I > hear from the current maintainer before then. Did you finish it already? I have the same problem and reported the bug. I found out, that the libgtk and xournal from unstable have this problem on i386 arch. So i can't "paint" in PDF files anymore with Xournal on my Thinkpad X61t. On my Desktop i have amd64 arch, and there everything is working fine although the version of libgtk and Xournal are the same like on the i386. A downgrade to the stable libgtk at the laptop made it work again, but other programs like gajim stopped working. So i am really looking forward to a patch for my laptop debian system and i would be happy if u can help, because i need it when University starts in 2 weeks. thx -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Xen - Source?
Hallo everybody! Xen is distributed with Debian (main) Seems the source-package doesn't contain the code of the hypervisor. Also /lib/modules/2.6-686/kernel/arch/xen/i386/mm/hypervisor.c is not included. Installing it (make), it downloads the binary of the hypervisor! "Cloning http://xenbits.xensource.com/linux-2.6.18-xen.hg " # (downloading) So where do I find the source of the xen-Hypervisor (running below the linux-kernel)? - Or: why could it be distributed with Debian? thanks a lot, Andrew -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from DPL
Am Mon, Jun 03, 2024 at 04:34:08PM +0200 schrieb gregor herrmann: > On Mon, 03 Jun 2024 11:00:34 +, Holger Levsen wrote: > > > > however, "costs to attend" are not the same as "costs while attending"... ACK. > Also & related, https://wiki.debian.org/HostingBSP#Sponsorships says > (emphasis mine): > > participants to a BSP can get a reimbursement of up to 100 USD for their > *travel fees*. > > whereas the discussions around the MiniDebConf Berlin were about > sponsored food, IIRC. > > Note that I'm not saying "Debian must pay for food for a week for > all people at any price, no matter what", just that "100 USD for > expenses" is not the same as "100 USD for their travel fees". > > No big deal, just maybe a chance for clarification before the next > Debian event :) The major friction point for MiniDebConf Berlin, in my opinion, was the need to raise a large amount of funds at very short notice. This should be avoided for future Debian events. My position is clear: I strongly support in-person meetings and thus I will do my best enabling active contributors to attend. If financial limitations are a barrier for active contributors, we should find ways to help. The amount of financial support needed can vary greatly depending on the region where the in-person meeting is happening. Therefore, please consider this as a rule of thumb, not a fixed (upper or lower) limit. More importantly, organizers should strive for realistic cost calculations in advance and communicate any changes as soon as possible. Finally, securing sponsors can be very helpful, and the probability of finding them is typically higher in regions with higher overall costs. Kind regards Andreas. -- https://fam-tille.de
Re: DEP17 /usr-move: debootstrap set uploaded
Am Thu, Jun 06, 2024 at 08:14:18PM +0200 schrieb Étienne Mollier: > > 100% agreed. The care and excellence that you've brought to this work has > > been exceptional. > > Very much seconded, you have my thanks added on the stack! :) Seconded as well. You deserve a $DRINK / some sweets once we meet next time (no matter whether I might wear my DPL hat at hat time any more). ;-) Kind regards Andreas. -- https://fam-tille.de
Re: autoconf 2.72 to unstable?
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? cu Andreas
Re: Vendoring an unmaintained library?
On 2024-07-03 Alexandre Rossi wrote: [...] > #1073005 asks for the vendoring back of an unvendored library, arguing > that this particular library is unmaintained upstream, implying that the > vendored fork is better maintained. > My view on this is that if the vendored fork is better maintained, the > vendored fork should become the upstream of the Debian package. [...] FWIW both FreeBSD and Gentoo have switched to the suggested fork (last commit 2020), while the original source on sf is quite dead (last change 2013). cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: DD's, Debian Mentors needs you!
Hi Phil, thanks for advertising Debian Mentors. Am Sat, Jul 06, 2024 at 02:45:33PM +0100 schrieb Phil Wyett: > Hi all DD's > > Debian Mentors[1] always struggles to find available Debian Developers for > final reviewing and > sponsoring of packages submitted too our part of the project. One thing I'm missing on mentors.d.n is that I it does not advertise existing teams. It happened from time to time that there was some sponsoring request of Debian Science, Debian Med or Debian Python Team related packages (surely others I did not notices). Asking on the relevant lists very easily helps getting the package in question sponsored. I have a personal sponsoring policy that I only sponsor from a Git repository in a team I'm working in. This has the advantage I can easily help by pushing some commit with extensive comment to teach the sponsee in some direct way. Making a sponsee aware how to work together with a team inside Debian is IMHO very important. Thus I would welcome if there could be some explicit hint to mentees to relevant teams. Kind regards Andreas. PS: Please do not understand my remark related to the packages below just a general remark fitting the subject. > We believe some packages are ready or very close to the quality for > sponsorship and we would request > any DD who has the time and is willing, to have a look at one or more of the > packages below and > possibly sponsor them into Debian. > > Mentors page: > https://mentors.debian.net/package/hexwalk/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065008 > > Mentors page: > https://mentors.debian.net/package/uriparser/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074542 > > Mentors page: > https://mentors.debian.net/package/mailgraph/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074552 > > Mentors page: > https://mentors.debian.net/package/dmidecode/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074553 > > Mentor page: > https://mentors.debian.net/package/selint/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074592 > > Your assistance will be extremely appreciated and if announcing a few at a > time on the 'devel' list > works, this could become a weekly thing. > > [1] https://mentors.debian.net > > Regards > > Phil > > -- > > Internet Relay Chat (IRC): kathenas > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- https://fam-tille.de
Re: DD's, Debian Mentors needs you!
Hi Phil, Am Sun, Jul 07, 2024 at 08:48:22AM +0100 schrieb Phil Wyett: > > Thank you for the kind words. I agree whole heartedly with your comments that > more people getting > involved to make for a better Debian mentors would be good. Debian mentors is > a great place to be > around and we all learn something being involved. Thanks to you and all your work for mentors.d.n. Just to clarify my mail about connecting to teams (which is done as I learned in response): I did by no means intended to lower the importance of mentors.d.n in general for Debian and newcomers. Thanks again Andreas. -- https://fam-tille.de
i686 require SSE4.1-capable processor?
Hi I'm maintaining a package (filezilla) which just got a bug report that it simply crashes on program start - It gets a SIGILL - "Illegal instruction". (#1076312 report [1]). After the reporter debugged it, it seems like it crashes on the assembler instruction "pinsrd", which looks like it was added in SSE4.1, while the reporter runs this on a Intel(R) Celeron(R) M CPU 420 @ 1.60GHz which only supports SSE2. (Full cpuinfo available in the report) - So, my question is - is this a cpu that is too old for Debian to support, or should we support it, and Debian gcc generates invalid code requiring SSE4.1 while it still should support SSE2? (Or is the problem something else completely?) -- Andreas Rönnquist mailingli...@gusnan.se gus...@debian.org [Please don't CC me, if I mail to a mailinglist, I am subscribed to it.] 1: https://bugs.debian.org/1076312
Re: i686 require SSE4.1-capable processor?
On Mon, 15 Jul 2024 17:31:30 +0500, Andrey Rakhmatullin wrote: >On Mon, Jul 15, 2024 at 01:42:50PM +0200, Andreas Ronnquist wrote: >> I'm maintaining a package (filezilla) which just got a bug report that >> it simply crashes on program start - It gets a SIGILL - "Illegal >> instruction". (#1076312 report [1]). >> >> After the reporter debugged it, it seems like it crashes on the >> assembler instruction "pinsrd", which looks like it was added in >> SSE4.1, while the reporter runs this on a >> >> Intel(R) Celeron(R) M CPU 420 @ 1.60GHz >> >> which only supports SSE2. (Full cpuinfo available in the report) - So, my >> question is - is this a cpu that is too old for Debian to support, or >> should we support it, and Debian gcc generates invalid code requiring SSE4.1 >> while it still should support SSE2? (Or is the problem something else >> completely?) > >Neither. >Packages built for the i386 arch need to conform to the i386 baseline, >which is currently i686. If a package contains a newer instruction it's a >bug in that package and gcc is not the cause of it, the package is. >https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0 >indeed contains at least one compile command with -msse4.1. > >(there is also a "workaround", adding a dep on some isa-support >subpackage, but it's unlikely to be the correct course of action here and >I still don't know why is it even allowed in general) > Yeah, I have discovered that it is indeed a cause of the d/rules in the filezilla package. I blame having taken over it recently, and still haven't learned the ins and outs of it. I'll take care of it. Thanks wRAR! -- Andreas Rönnquist mailingli...@gusnan.se gus...@debian.org pgpeJ_dw_ifoE.pgp Description: OpenPGP digital signatur
Updating delegation for the backports team
Backports Team delegation = I'm sorry for my mistake to copy-and-paste from last delegation text while not remembering Rhonda changed her name. I'd like to immediately fix the appointment for the Backports Team. The correct team member list is: - Alexander Wirt - Rhonda D'Vine - Micha Lenk This delegation addet the new member Micha Lenk - thanks to Micha for volunteering for this task. Sorry for Rhonda for my mistake in the latest, now invalid appointment. The delegation is not time-limited. It will be effective until further changes by present or future DPLs. Task Description The Backports Team oversee and maintain the well-being of Debian's backport service that allow Debian Developers to prepare backported packages for Debian users. Members of the Backports Team are responsible for tasks that include: - Defining the policy for backports upload, in consultation with Developers. - Running the archive infrastructure that powers the backports service, usually with the support of the FTP Masters. - Accepting and rejecting NEW packages that enter the backports repository (AKA "NEW queue processing" for the backports service). - Managing the keyring that control upload access to the backports service, performing tasks such as adding, removing, and updating keys. More info - - You can find the policy for backports upload at https://backports.debian.org/Contribute/ - More details on the activities of the Backports Team are available at <http://wiki.debian.org/Teams/Backports - If you want to help out the backports team and/or joining it, you're welcome to contact them at Thanks a lot for thw whole backports team to provide this service Andreas, Debian Project Leader. signature.asc Description: PGP signature
Accepting DEP14?
Hi, considering that it makes sense to settle with DEP14[1] first before we can decide about DEP18 I wonder what is finally needed to accept DEP14. I think its cruxial to make git-buildpackage supporting DEP14 per default[3] but I'm somehow sensing some hen-egg problem here what to do first. If DEP14 might be accepted the motivation to fix bug #829444 would be probably way higher. Just a personal note: All repositories where I'm uploader (>1000) are following git-buildpackage default layout and thus not compatible with the DEP. So accepting DEP14 would mean a lot of work for me (at least testing the suggested scripting solutions[4] carefully) and for my personal workflow I'm not really keen on pushing DEP14. However, wearing my DPL hat with the clear intention to streamline common workflows, I'd be happy if we would move forward here. Are there any blockers to accept this DEP which I might have missed? Kind regards Andreas. [1] https://dep-team.pages.debian.net/deps/dep14/ [2] https://salsa.debian.org/dep-team/deps/-/merge_requests/8 [3] https://bugs.debian.org/829444 [4] https://lists.debian.org/debian-devel/2020/09/msg00168.html https://lists.debian.org/debian-devel/2020/09/msg00172.html -- https://fam-tille.de
Re: Accepting DEP14?
Hi Otto, Am Thu, Aug 15, 2024 at 01:43:40PM -0700 schrieb Otto Kekäläinen: > Yes to finalizing DEP-14 soon, but first I think we need to complete the > technical work to have git-buildpackage use DEP-14 branch names by default. Well, this is what I meant as a hen-egg-problem. It might support DEP-14 since it would be way easier to follow the DEP using the well-known and really convenient tool. However, it might be that Guido (in CC) is more motivated to adapt the tool to a DEP once its accepted. Guido, what do you think? > I tried implementing it but turned out a bit too involved.. Perhaps this should rather be discussed in the bug log. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444 > Use DEP14 branch layout by default > = master -> debian/latest > = upstream -> upstream/latest > > Any hands available to help with this? As far as there are no concerns about DEP-14 any more it might make sense to do this. Kind regards Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Hi, Am Fri, Aug 16, 2024 at 11:09:58AM +0200 schrieb Andrea Pappacoda: > > In #829444 it has been proposed the addition of a new "layout" option to > gbp.conf, which would tell git-buildpackage which layout to follow, > allowing for a graceful migration. > > I've been thinking about a different approach though. What about adding > a warning to git-buildpackage when `debian-branch` and `upstream-branch` > are not set in gbp.conf? Compared to the `layout` option, it would have > the following benefits: > ... > How does it sound to you? Am I missing something? I prefer having no debian/gbp.conf at all in case the repository layout would fit team policy. So the question is whether git-buildpackage can cope with the old master + upstream + pristine-tar as well as debian/latest + upstream/latest + pristine-tar if no gbp.conf exists. Kind regards Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Am Fri, Aug 16, 2024 at 02:58:40PM +0500 schrieb Andrey Rakhmatullin: > > pristine-tar isn't the default either, so you need debian/gbp.conf if your > team uses it. That's correct but the teams I'm working in recommend something like: Add the following to the configuration file ~/.gbp.conf or debian/gbp.conf: [DEFAULT] builder = ~/bin/git-pbuilder pristine-tar = True pbuilder-options=--source-only-changes (for instance in Debian Med team policy[1]) > Unless I've missed some recent changes. You did not miss anything, My statement was incomplete. Kind regards Andreas. [1] https://med-team.pages.debian.net/policy/ -- https://fam-tille.de
Re: Accepting DEP14?
Hi Jonas, Am Fri, Aug 16, 2024 at 02:12:21PM +0200 schrieb Jonas Smedegaard: > > Quoting Andreas Tille (2024-08-16 11:44:38) > > I prefer having no debian/gbp.conf at all in case the repository > > layout would fit team policy. > > I understand that it would be lovely if git-buildpackage supported DEP14 > without you needing to touch a thousand packages. I tried to express: I'm more than willing to convert all packages where I'm Uploader (most preferably) if DEP14 is accepted. > But do you really put on your DPL hat and raise that wishlist bug to a > matter for d-devel to debate and try solve? I tried to raise my DPL hat against my own obvious interest to rather do nothing. In other words: As DPL I consider DEP14 an advantage and would defend this even against my own interest. > Please do consider the simpler approach here: > > Step one: Discuss on d-devel if DEP14 can be accepted as-is. ... which I do. > Step two: Discuss in bugreports how various tools might be improved for > as exciting a user experience with DEP14 as sensible for each tool. In some discussions (written and aural at DebConf) I heard the opinion that a precondition for DEP-14 would be git-buildpackage support. I simply picked up this opinion as some potential reason why there is no progress for DEP-14. I do not think so which is why I wrote "If DEP14 might be accepted the motivation to fix bug #829444 would be probably way higher." Seems my wording was miserable enough to make you believe I would be in contrast to your suggestion, which is actually not. BTW, I do not think that the DPL hat can be (mis)used to draw technical decisions. I just wanted to know what might be the blocker for some decision that is pending since a long time. I'd be happy if you would understand that I mentioned my role only for the sake to learn about blockers, not to push into any direction. > Personally, I think DEP14 is usable as is, and look forward to have it > formally be declared done. Cool. So lets do this. > I do not, however, understand the details of > the DEP procedures well, however, so look forward to feedback from > others beter understanding those details. Same here. > ...but not details on git-buildpackage: Details on the formal DEP > procedures - unless those really are super intertwined. Until someone > knowledgable on DEP procedures explains how that necessitates solving > specific tooling issues as well, please pretty please discuss tooling > details, like git-buildpackage migration handling and/or default > settings, at the appropriate bugreports *without* cross-posting to > d-devel. I'm not fully sure why git-buildpackage should not be discussed here in a possible different thread. However, I agree that we can finalise the formal DEP process without mixing both discussions. Kind regards, Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Hi Andrey, Am Fri, Aug 16, 2024 at 07:17:52PM +0500 schrieb Andrey Rakhmatullin: > > > pristine-tar isn't the default either, so you need debian/gbp.conf if your > > > team uses it. > > > > That's correct but the teams I'm working in recommend something like: > > > > Add the following to the configuration file ~/.gbp.conf or > > debian/gbp.conf: > > Putting team-specific settings into the global ~/.gbp.conf is a bad idea > in my opinion, but also you can set DEP14 branches there in the same > way... Sure I can and probably would - but we need to decide about DEP-14 first. Kind regards Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Am Sat, Aug 17, 2024 at 10:17:19AM +0200 schrieb Chris Hofstaedtler: > On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: > > IMO, and from discussions in the Debian Perl Group, the blocker is > > the conversion of existing repos, both on salsa (which should be > > doable via the API as suggested in the sketches mentioned above) and > > also locally for hundreds of developer machines [git fails horribly > > on the upstream/ → upstream/latest change]. > > I want to echo this pain. When changing the layout it seems almost > better to start from scratch. > > Additionally, in my opinion debian/latest is a mistake we should not > recommend. OK, I admit I do not mind about the actual names that are used. I mind about the fact that it makes sense to settle with some *common* repository layout for all our repositories to make sure that someone who wants to contribute to some random git repository feels home immediately. Sam said, gbp-buildpackage default is fine. If people agree here we could change DEP-14 to simply use this (despite now lots of repositories are featuring the currently suggested DEP-14 layout). Gregor and Chris underline that the choice of the names in DEP-14 are hard to convert. I'm fine with some better proposal. For me DEP-14 is an attempt to settle with some common default. I personally do not mind about the actual names. I guess its a requirement to have some automated conversation (which could be even done by Janitor for instance). If DEP-14 suggests something that fails here its hard to accept for many (including myself). Any ideas how we can come up with some suggestion that will finally enable us with some common reopsitory layout that enables automated conversion from any existing layout. IMHO we should move DEP-14 forward since having it an open suggestion for ages will not bring any progress. Kind regards Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Am Sat, Aug 17, 2024 at 10:33:58AM +0200 schrieb Chris Hofstaedtler: > > > Add the following to the configuration file ~/.gbp.conf or > > debian/gbp.conf: > > Putting per-repository relevant settings into a global config and > not into the per-repo config seems to fly into the face of the DEP18 > spirit. I'd perfectly follow the DEP-14/DEP-18 spirit since if we have some common default any specifications inside team policies become void and we can get rid of those settings in ~/.gbp.conf. My personal preference would be if we make a pristine-tar branch default since this is what I observed in the wide majority of cases. > Maybe there is no issue with changing git-buildpackage after all > then. Yes. Kind regards Andreas. -- https://fam-tille.de
Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
Hello, Anyone not interested in ancient history can skip this mail. On Thu, Aug 15, 2024 at 11:20:47PM +0100, Colin Watson wrote: > On 2024-07-14 (five days before the iproute2 change was made), there was > this conversation on #debian-devel: > > 19:14 Is there a reason why iproute2 ships a symlink > from /sbin/ip to /bin/ip? I've looked into the packaging repo and it > seems to predate the git log. I was involved with iproute2 during the era when some sbin->bin shuffling happened, but apparently `ip` moving happened long before and only other tools followed later on. >From debian/changelog: iproute (20010824-7) unstable; urgency=medium * Move `ip' binary to /bin to fix FHS violation (closes: Bug#134812) -- Juan Cespedes Mon, 4 Mar 2002 00:20:30 +0100 (My recollection was that formorer moved ip, but apparently not. Calling it a FHS violation is IMHO a very strong claim.) Also relevant: iproute (20051007-4) unstable; urgency=low * Moved *stat binaries to /usr/bin/ (Closes: #350703) [...] -- Alexander Wirt Sun, 5 Feb 2006 09:47:36 +0100 ... and ... iproute (20110629-1) unstable; urgency=low [ Alexander Wirt ] * Install ss to /bin instead of /sbin. [...] -- Andreas Henriksson Mon, 04 Jul 2011 17:29:04 +0200 FWIW I've personally supported sbin and bin merging at some point, just for the simple reason that I'll never get back all the time wasted on arguing with people who want things moved around (but refuse to take it up with upstream). Apparently this is something which is still taking up time and even causing new bugs. > ... > 19:52 petn-randall: > https://codesearch.debian.net/search?q=%2Fsbin%2Fip%5Cb&literal=0 has > a pretty non-trivial list of things that would need fixed before > removing that (and of course some false positives) While I generally don't support hard-coding paths, not having the sbin symlinks means we have nothing in the location where upstream install these tools, which I also think is a bad idea. (I'm not sure if other distros follows upstreams location, but I'm still willing to call having the tools in bin a Debian-ism.) For a current list of tools where we override the upstream install path, see debian/iproute2.install in the source package or at: https://salsa.debian.org/kernel-team/iproute2/-/blob/debian/sid/debian/iproute2.install > > I realize it wasn't petn-randall who made this change, but it seems a > big coincidence that the symlink was dropped a few days after this IRC > conversation; and yet it seems nobody bothered to do the most basic due > diligence that I pointed out here, which is kind of sad. (I fixed > wireless-tools after this change caused an RC bug there.) > > -- > Colin Watson (he/him) [cjwat...@debian.org] > Regards, Andreas Henriksson
Re: Removing more packages from unstable
On 2024-08-20 Helmut Grohne wrote: > Hi fellow developers, > (modified resend, as first attempt didn't arrive) > please allow me to open a can of worms. Package removal from unstable. > Deciding when it is time to remove a package from unstable is difficult. > There may be users still and it is unclear whether keeping the package > imposes a cost. In this mail I want to argue for more aggressive package > removal and seek consensus on a way forward. +1 > What does a package cost? > There are various QA-related teams looking at packages from other [ a lot] I always notice this whenever I make a pretty minor transition, about half the packages I have to deal with are of dubious usefulness and quite unmaintainted. [...] > mixer.app [...] On one hand I am proud that I managed to remove it early from testing OTOH I should have had it removed from sid years ago. Bug filed now. cu Andreas
Re: Removing more packages from unstable
Hi, Am Tue, Aug 20, 2024 at 02:51:49PM +0900 schrieb Simon Richter: > > enigmail > > Thunderbird has native GPG support now, including (well-hidden) support for > calling into the installed gpg binary to use a smartcard. > > > mutextrace > > Oof, I should fix that finally, because in principle a debugging layer to > find lock hierarchy violations would be good to have. > > > obs-websocket > > Websocket support was merged into the main program a while ago. To my understanding this reads like: We can remove enigmail and obs-websocket or what do you want to express? If so would you mind filing removal bugs? Kind regards Andreas. -- https://fam-tille.de
Re: Removing more packages from unstable
Am Tue, Aug 20, 2024 at 11:09:31AM +0200 schrieb Helmut Grohne: > > I considered adding popcon to the criteria before hitting send. In the > end, I opted for not including it based on my own cost/benefit analysis. > While popcon may be a signal for the benefit-of-keeping aspect, it > provides little value for the cost-of-keeping part that feels most > important to me. As you point out, popcon is partially considered via > the key package constraint. As others (e.g. Niels) point out, the cost > of a package largely is a function of our ability to modify it and long > lasting RC bugs are a relatively high quality signal indicating that a > package is difficult to modify. Either some of those many users > (according to popcon) eventually gets interested in doing the hard work, > or we should put it onto the chopping block. Even mailing the rc bug > would reset its last modified timer. These are very good arguments. > If there ends up being consensus for adding popcon as a signal, so be > it. I've explained my reasons and am not too strongly attached to > excluding popcon. Anyway I think while a low popcon should not really put a package on the potential removal list but a high popcon might be a good reason to remove the package from the list. My guess is that you will not find that many high popcon packages in your list so it will probably not become way shorter by removing high (by whatever definition of high) popcon packages. Thank you in any case for your investigation Andreas. -- https://fam-tille.de
Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
Am Tue, Aug 20, 2024 at 06:35:52PM -0700 schrieb Otto Kekäläinen: > ... ACK to everything. > However, pushing for wider Salsa CI adoption I think makes sense as a > goal by itself, and I would be keen to hear what people think is a > reasonable way to proceed with that? ACK. What about configuring Salsa that Salsa CI is switched on by default? Since 2021 I'm discussing with Debian Java team (last mail about this in my DPL contact[1]) to not hide the "Switch Salsa CI on"-button which makes it extra hard to get Salsa CI for these packages. Not sure about other teams but IMHO the better strategy would be to make it extra hard to switch of Salsa CI. Kind regards Andreas. [1] https://lists.debian.org/debian-java/2024/06/msg7.html -- https://fam-tille.de
Re: LPC: Support for Complex Cameras in Debian
Hi Ricardo, Am Tue, Sep 03, 2024 at 10:37:27PM +0200 schrieb Ricardo Ribalda Delgado: > ... > As a newer DD, I don't feel comfortable speaking on behalf of the > project just yet. I'm hoping someone from debian-dev or > debian-multimedia might be interested in participating, either in > person or virtually.s If you are a "newer DD" but with competence on the actual topic I wonder what some "older DD" who has no idea about the topic can do better than you? > Alternatively, if someone could spare 30-60 > minutes to discuss Debian's best approach with me before the event, > that would be immensely helpful. What actual question do you want to discuss? Kind regards Andreas. -- https://fam-tille.de
Re: Bits from DPL
Hi, Am Wed, Sep 04, 2024 at 11:29:39PM -0400 schrieb Scott Kitterman: > On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote: > > > > OoC, what is your point, especially considering the quote of your own > > opinion Andreas made? > > > > This just seems passive-aggressive, and the fact he stepped up once > > doesn't mean he has the time or will to step up hundreds of times. > > I think it's odd that he would talk about how hesitant people are to touch > other packages when he in fact does it himself. I'm not sure who he thinks > he's speaking for, clearly not himself. I did it *after* someone with insight into the topic gave the according hint[1]. So the sequence was: 1. I filed ITS 2. Someone with insight suggested removal 3. Reassigned ITS to RM I personally see some difference between this sequence and a straight asking for removal. > I don't have statistics, but maintainer filed RM requests a pretty rare. My > impression is it's only a small fraction of the total. I processed a lot of > requests last night and almost none of the requests for package removal were > from maintainers. You are definitely the expert about package removals. > It probably was a little passive aggressive, but I don't appreciate the DPL > using the Bits from DPL message to punch down like that. If he has a point > to > make to further the discussion, it should be made as part of the discussion. My intention was to highlight interesting contributions to the entire discussion. If phrases like 'Scott Kitterman made a valid point' and 'I agree' came across as dismissive, I sincerely apologize—that was not my intent. I genuinely valued your point, and I added my own suggestion "based on defined criteria, it could help reduce some of the social pressure." Item 2. above could possibly be such a criterion, since you pointed to this actual example. > If he's only trying to bring the issue to the wider project's attention, then > I don't think picking one person's opinion to disagree with in Bits is very > appropriate. I'm sorry if there was any misunderstanding, but I'm unsure how my message gave the impression that I disagreed. Could you clarify which part led you to this conclusion? Also, just to clarify, I avoid using sarcasm in electronic communication, especially in Bits from the DPL, as it often doesn't translate well. > FWIW, all an automated process would do is create work for the FTP Team. > Those I would feel I have to scrutinize even more closely than ones filed by > a > human since no one has given it a sanity check before it gets to the FTP Team > to process. I need to trust you here as the one who is doing the work. The discussion also was about a semi-automatic process which. Do you have some opinion about this? Kind regards Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079816#8 -- https://fam-tille.de
More about removing more packages from unstable (Was: Bits from DPL)
Hi again, Am Thu, Sep 05, 2024 at 06:18:02PM + schrieb Scott Kitterman: > I'm willing to assume good faith and accept that was not your intention. > It's in the past. OK. > >I need to trust you here as the one who is doing the work. The > >discussion also was about a semi-automatic process which. Do you have > >some opinion about this? > > > I don't have any problem with a process that suggests to people doing QA work > in Debian that package removal might be appropriate based on some criteria. > I don't think that such a semi-automatic process relives the person filing > the RM bug from engaging their brain to decide if it makes sense. > > I can see how having such a tool that used criteria that has been socialized > within the project to some degree might reduce social pressure to not file > the bug. More people working on QA is always good. Nice we agree here. One more detail about package removals: As you might have seen there were about 200 removals of 32 bit architectures of r-bioc-* packages and I expect more r-cran-* packages to come. Do you see any chance to automate architecture specific removals, most favourably by dealing with a whole dependency tree. This would probably remove a lot of manual work from DDs as well as your own work. Kind regards Andreas. -- https://fam-tille.de
Re: Ubuntu discussion at planet.debian.org
* Matthias Urlichs ([EMAIL PROTECTED]) [041023 23:00]: > Hi, Manoj Srivastava wrote: > > Secondly, buildd's do > > not work with experimental. > That can be fixed quite easily. In fact, my own (personal) buildds do it. Actually, I'm also building experimental packages, for mips, hppa, sparc and alpha. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Release-critical Bugreport for May 14, 2004
On Sun, 24 Oct 2004, Petter Reinholdtsen wrote: Did these reports stop, or is there something wrong with my email? The last one I could find in my debian-devel-announce mail folder is from 2004-05-14. This is what I wondered every week but was to lazy to ask. Either something is broken or our both email systems are broken. Kind regards Andreas.
Re: Drop testing
* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:00]: > #include > * Joey Hess [Sat, Oct 23 2004, 08:36:18PM]: > > > > not look appear as critical for maintainer, or not important enough to > > > touch > > > package in the holy "frozzen" state). Such bugs are a disaster, they make > > > our definition of a Stable release absurd. Yes, Debian Stable has become a > > > buggy stable release. Just face it. > > > > AIUI, you propose to freeze unstable and go back to the old method of > > having updates during the freeze be manually put in at the discretion of > > the Release Managers. If we did that, how would one of these "ugly bugs" > > be any more likely to be fixed in frozen unstable than it is in today's > a) The release time would be shorter I would like to see a prove of this. > b) It would be up to humans (and not some obscure scripts) to decide whether > the bugs deseves a fix or not This is already the case. If the humans decide that a bug should be fixed, they can either just do it, or at least upgrade the bug to RC-grade. If they decide that it is actually not so bad that it requires a fix for the release, they could downgrade it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Drop testing
* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:10]: > At least they won't poison Sid with fresh things that may others life > more difficult. Eg. new library versions. And why should that work better than now? The developers _are_ asked to not poison sid. The advantage of testing is however that we have some chance to un-do broken actions. > > they like less than x but still more than y. So this will at least fail, > > and probably hurt debian too. > Maybe. What is the alternative? Continue with the current method and > release Edge... 2009 or so? If we could get back to facts, our main problem is _not_ that sarge is not in release-quality. Sarge is (mostly) in very good shape, and the remaining problems would be there also with your proposal. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Ubuntu discussion at planet.debian.org
* Marcelo E. Magallon ([EMAIL PROTECTED]) [041026 09:35]: > On Sun, Oct 24, 2004 at 01:37:21AM -0500, Manoj Srivastava wrote: > > > Okay, it's a month old, but there hasn't been any since. > > > http://lists.debian.org/debian-devel-announce/2004/09/msg5.html > > > "We are also still missing official autobuilders for > > > testing-proposed-updates on alpha and mips. All other architectures > > > appear to be keeping up with t-p-u uploads." > >Missing a buildd on an arch or too is a far cry from t-p-u > > being unsupported. > Testing is by design all-or-nothing. As long as a single architecture > hasn't buildd support for t-p-u, the buildd support for t-p-u is as > good as missing. You could do builds by hand, but then again, how many > developers actually do that? And, please don't do it. We definitly can't release without official buildds for all architectures, so please no binary-only uploads in t-p-u (if the release team would consider different, I'd have started building mips and alpha there long ago). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Several X applications refuse to start
Hello, asking Google for this problem just leaded to hints of some broken X resources but I have no real clue what might have caused the failure of at least three important applications which I'm running on a laptop with an up to date testing. I never faced similar problems with three other machines running more or less the same stuff. $ emacs X protocol error: BadValue (integer parameter out of range for operation) on protocol request 45 Fatal error (6). $ xdvi X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 45 (X_OpenFont) Value in failed request: 0x1c2 Serial number of failed request: 20 Current serial number in output stream: 21 $ gv Warning: Missing charsets in String to FontSet conversion Warning: Unable to load any usable fontset The problem is that this Laptop is the machine I installed most recently and I want to share this obervations with other developers just to prevent that something goes really wrong in Sarge ... So the question is, which information do I have to provide to track down this problem. Kind regards Andreas.
Re: Several X applications refuse to start
On Thu, 28 Oct 2004, Simon Huggins wrote: Is this a Transmeta Crusoe based laptop? No. It is centrono based and I guess this is rather a problem of some pure X applications, because Gnome and KDE applications and also Mozilla are behaving fine. The only thing is that sometimes fonts are not rendered nicely (for instance the fonts in the menu of xmms look ugly and do not seem to use TrueType fonts. Have you seen bug 216933? I get this bug periodically. Apparently running the debugging server or recompiling to turn off optimisation in the X server may help. Though I guess your symptoms are a little different. Definitely. Kind regards Andreas.
Re: Drop testing
* Jan Nieuwenhuizen ([EMAIL PROTECTED]) [041028 14:05]: > Thomas Bushnell writes: > > So the RC bugs should not be blocking release unless they are *new* RC > > bugs which don't already exist. > I'd word that a bit differently: the definition of an RC bug should > *never* allow a bug still present in stable now (+ security.stable) to > reach the level of RC. We _have_ RC-bugs in woody - even RC-bugs we won't fix. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Versioned bugs in the BTS (was: Drop testing)
* Frank Küster ([EMAIL PROTECTED]) [041028 17:00]: > Matthias Urlichs <[EMAIL PROTECTED]> wrote: > > Besides, we'll have a bug database which tracks version numbers. This in > > turn means that we have a nice distinction between bugs that are actually > > RC in the "fix this if we'd want to release Etch tomorrow" sense, and bugs > > that are RC in the "keep this out of testing" sense. > This sounds great, and I heard that it has been promised for after the > sarge release, sounding as if it was implemented yet. Is the counterpart > also implemented, namely testing scripts that take this information into > account? The implementation of version in the BTS is done so that the second is not _so_ hard to implement (speaking as someone who has seen lots of parts of britney). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Drop testing
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [041028 22:00]: > Also note that there are _many_ patches in the BTS for RC (and many other > bugs). But RC bugs do not get fixed in time [0] this also shows that a > number of packages are not being properly maintained and we maybe could > maybe think a way to force the maintainer to give over maintainership if he > is overloaded with other work and he cannot fix the package in time. I plan to go through the packages that are not released with sarge, and propose to orphan / delete some / most of them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Several X applications refuse to start
On Thu, 28 Oct 2004, Sean Perry wrote:
1) what locale? try C.
[EMAIL PROTECTED]:~$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
[EMAIL PROTECTED]:~$ emacs
X protocol error: BadValue (integer parameter out of range for operation) on
protocol request 45
Fatal error (6).Aborted
2) this looks like a font issue (as you mentioned) try forcing the app to
load 'fixed' as its font.
I also tend to see the problem in finding the right fonts. When looking at
the strace output all applications I mentioned (emacs, xdvi, gv) have certain
problems with fonts, but I have neigther an idea how to force fixed fonts
nor how to fix the problem. Regarding to the things I changed with the fonts
I was following some hints from
http://www.paulandlesley.org/linux/xfree4_tt.html#FONTS-FILES
which might be summed up in this script:
MSTTFONTDIR=/usr/share/fonts/truetype/msttcorefonts
cd ${MSTTFONTDIR}
ttmkfdir -o fonts.scale
head -1 fonts.scale > fonts.dir
tail +2 fonts.scale | tac >> fonts.dir
cp fonts.dir fonts.scale
cd /etc/X11/fonts/TrueType
cp -a ${MSTTFONTDIR}/fonts.dir .
# the following script was downloaded via the link I mentioned above
# because the site has moved it is attached to this mail
/tmp/download/mkfontalias.py
grep 'iso8859-1"' fonts.alias > msttcorefonts.alias
rm -f fonts.dir fonts.alias
update-fonts-alias TrueType
I had to do this to get MagicPoint working with TrueType fonts. I hope that
this did not break other important things.
Any font expert here who might see the problem?
Kind regards
Andreas.#!/usr/bin/python
#
# This is a short python utility to assist people in de-uglification of
# their true type fonts. Basically, creates a fonts.alias file from the
# fonts.dir file found in the directory.
#
# Consider this software to be under GPL.
#
# Roman Sulzhyk, Starmedia Networks, 2000. [EMAIL PROTECTED]
# --
# 20.05.2000: Added common MS webfonts as fontnames to map:
# Verdana, Tahoma, Impact, Arial Black, Comic Sans MS, Georgia, Trebuchet MS.
# R.K.Aa. [EMAIL PROTECTED]
# --
# 21.05.2000: Added 'cheating' - sizes 6,7 and 8 now map to 9 point fonts.
# --
import sys, string, os
_font_sizes = range(6, 16) + [ 18, 24 ]
_infile = 'fonts.dir'
_outfile = 'fonts.alias'
# Resolution
_res = [ '75', '75' ]
# Do 'cheating' to make sizes 6,7,8 as 9 bit fonts
_cheat_map = { 6 : 9,
7 : 9,
8 : 9 }
# The fonts to map. Format name : alias
_font_map = { 'Arial' : 'Arial',
'Times New Roman' : 'Times New Roman',
'Verdana' : 'Verdana',
'Tahoma' : 'Tahoma',
'Impact' : 'Impact',
'Arial Black' : 'Arial Black',
'Comic Sans MS' : 'Comic Sans MS',
'Georgia' : 'Georgia',
'Trebuchet MS' : 'Trebuchet MS',
'Courier New' : 'Courier New' }
# Read in the fonts.
try:
# Strip the first line
fonts = open ( _infile ).readlines()[1:]
except IOError, val:
sys.stderr.write ( 'Cannot read %s (%s) - are you sure you are in the '
'fonts directory?\n' % (_infile, val) )
sys.exit(1)
# Now, create the output
_aliases = []
for line in fonts:
try:
# Get rid of the first entry, but mind that other may have
# spaces in them
font = string.strip(string.join ( string.split ( line, ' ' )[1:], ' '))
except IndexError:
sys.stderr.write ( 'Cannot parse %s line: %s\n' % (_infile, line ) )
sys.exit(1)
entries = string.split ( font, '-' )
if len(entries) != 15:
# Seems to be invalid
sys.stdrr.write ( 'Invalid font: %s\n' % (font) )
sys.exit(1)
name = entries[2]
map = _font_map.get ( name, None )
if map:
# Create a bunch of aliases, for each size
for size in _font_sizes:
# Do the 'cheating' - fallback to size if not in the cheat map
real_size = _cheat_map.get ( size, size )
name = string.join ( entries[:7] + [ str(real_size),
str(real_size * 10) ] +
entries[9:], '-' )
alias = string.join ( entries[:2] + [map] + entries[3:7] +
[ str(size), str(size * 10) ] +
_res + entries[11:], '-&#x
Re: NMU on sysklogd
* Jerome Warnier ([EMAIL PROTECTED]) [041028 15:25]: > It is really annoying since every log analysis tool is failing on this > every week at least? By "log analysis tool" I mean anything relying on > files in /var/log to do something. > [..] > Could someone go through the list and NMU this? I'm willing to help, if > necessary. For Bug 275111 - I think this bug needs a proper explanaition / patch, because that's the only way to fix it. In general: sysklogd is already frozen for release of sarge. So, please don't upload _anything_ which won't make it for sarge, i.e. only RC-bug fixes. Changes like using /etc/defaults might be nice, but are not possible any more for sarge. (And, I guess that the maintainer might do a cleanup round after release of sarge.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: $HOME/.dotfiles and FHS 2.3
Frank KÃster <[EMAIL PROTECTED]> writes: >> * Window Maker stores its configuration across several files and >> directories under ~/GNUstep (configurable) (and no, I won't change >> the default because it's configurable via an environment variable) > > I was always annoyed by this, and it's not easy to find the solution in > the documentation (I only learned of the environment variable in this > thread). Why not change the default, when everybody can get back the > original buggy behavior by setting an environment variable? > Why not simply make it search for ~/GNUstep, and when that isn't found, ~/.GNUstep or something like that - would retain full compatibility. Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Any technology not indistinguishable from magic is insufficiently advanced. -- Terry Pratchett
Re: Bug#278914: ITP: dcmtk -- OFFIS DICOM ToolKit
On Sat, 30 Oct 2004, Pablo Sau wrote: * Package name: dcmtk Version : 3.5.3 Upstream Author : Marco Eichelberg <[EMAIL PROTECTED]> * URL : http://dicom.offis.de/ * License : BSD like Description : OFFIS DICOM ToolKit Freely available DICOM ToolKit (DCMTK) from Institute OFFIS & Oldenburg University, formerly European CTN (Central Test Node). This is a very interesting project for Debian-Med. I'd love if we could found an interested sponsor for the package. Kind regards Andreas.
Re: Several X applications refuse to start
On Thu, 28 Oct 2004, Sean Perry wrote: 2) this looks like a font issue (as you mentioned) try forcing the app to load 'fixed' as its font. Using emacs with fixed font works and I also found the problem which is descirbed in #279380. I think this bug is worth to be increased in severity but strangely the effect I observed on my laptop does not occure on other installations. I'd like to aks some "font-experts" if the remaining fonts.* files might make other applications crash and which further circumstances lead to this result. At least at my laptop was the removal of these files successful. Kind regards Andreas. -- http://fam-tille.de
more current iproute
Dear all, I uploaded the current version of iproute (that also works with current 2.6-kernels) to experimental. As this is a major change, any test reports are appreciated. Also, a review of the source whether I managed to keep all security patches might be a good idea (I'm quite confident that I did, but - a independent look might be a good thing). Please note that I'm aware that the package documentation is not in the best state, but as this was a NMU, I didn't do the changes that I would have done with a normal maintainer upload. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: more current iproute
* Milan P. Stanic ([EMAIL PROTECTED]) [041110 12:35]: > Why version is iproute_20041019 while the upstream is > iproute2-2.6.9-041019? Upstream version is 2.6.9 actually. Date is > appended to serve as timestamp, I think. Because changing the version format would be a bad think in a NMU. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Please test findutils 4.2.4 in experimental
Hello,
findutils upstream has taken up lots of speed while I was VAC and has
not only managed to declare 4.1.20 stable but also to make a couple of
new releases from CVS.
The changelog is quite big, closing many bugs and also adding a couple
of features (no, -exec {}+ is not there yet). I'd appreciate testing
before I upload to unstable.
thanks, cu andreas
spamassassin3 - is memory usage ok now?
Hi, I can remember some people complained that spamassassin3 had increased ressource usage. For the people who had problems: Are they fixed now with the new release that appeared in unstable? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Trouble to log in into s390 developer machines
Hi, at http://db.debian.org/machines.cgi the hosts raptor and trex are listed as s390 developer machines. I wanted to build the package phylip which has to be builded manually because it is in non-free. $ ssh -i ~/.ssh/my_key [EMAIL PROTECTED] ssh_exchange_identification: Connection closed by remote host $ ssh -i ~/.ssh/my_key [EMAIL PROTECTED] [EMAIL PROTECTED]'s password: For security reasons I have no passwort on any developer machine and use ssh-key authentication exclusively. Any hint how to log in on any s390 machine with chroots to build the package? Kind regards Andreas. -- http://fam-tille.de
Re: G++ in sarge.
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [041112 12:20]: > I would like to know if the Debian community is really going to release > Sarge with G++ 3.3.x as the default C++ compiler. > > My question stems from the fact that Sarge will probably be the only > stable release in the next year or two, that Sarge's packages C++ code > is compiled against libstdc++5, and that that library is unable to cope > with file streams longer than 2 Gb. > > I think the answer to this question ---only relevant for me, probably--- > could be a simple "yes" or "no", without making any noise and without > wasting developers' time in futile discussion. Sarges toolchain is frozen, and if we want to release at all, the answer is: Sarge will release with gcc-3.3 as default compiler, but gcc-3.4 is also included. However, I really hope that we manage to release etch a bit faster than sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: spamassassin3 - is memory usage ok now?
Andreas Barth <[EMAIL PROTECTED]> writes: > Hi, > > I can remember some people complained that spamassassin3 had increased > ressource usage. For the people who had problems: Are they fixed now > with the new release that appeared in unstable? > I recently decided to try SA3, even though its alleged performance problem, and with -m 2, it seems to run fine on my 96MB machine up to now. Cheers, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Software Patents: Where do you want to stifle inovation today?
Re: Bug#280675: ITP: l2tpns
* Jonathan McDowell ([EMAIL PROTECTED]) [041112 15:10]: > On Wed, Nov 10, 2004 at 10:34:04PM +, Jonathan McDowell wrote: > > * Package name: l2tpns > > Version : 2.0.5 > > Upstream Author : David Parrish and others <[EMAIL PROTECTED]> > > * URL : http://l2tpns.sf.net/ > > * License : GPL > > Description : L2TP LNS which does not require l2tpd, pppd or any > > kernel patches. > > > >L2TPNS is half of a complete L2TP implementation. It supports only > >the LNS side of the connection. > > > >L2TP (Layer 2 Tunneling Protocol) is designed to allow any layer 2 > > protocol > >(e.g. Ethernet, PPP) to be tunneled over an IP connection. L2TPNS > > implements > >PPP over L2TP only. > > > >Also supports ISP features like speed throttling, walled garden, usage > >accounting, and more. > Please stop following up to this ITP and telling me you don't understand > the description unless you have prior experience of L2TP in an ISP > environment. If you don't know what L2TP is or how an LNS fits into the > picture, then this package probably isn't for you. I don't believe any > of the terms used should be alien to the sort of person this package > will be of use to. Frankly speaking, the description should make sense for people who _don't_ have a clue about the topic - and even if only telling them that they should ignore the package. So, perhaps add something like L2TPNS is the implementation of the internet services provider (ISP) side of L2TP, i.e. it supports LNS. If you are not an ISP, you won't need it. For some more ideas, please see http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-desc-basics Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: sarge security (was: Re: Release update: please upload to unstable; toolchain; buildds; ...)
* Santiago Vila ([EMAIL PROTECTED]) [041113 15:25]: > On Sat, 13 Nov 2004, Martin Schulze wrote: > > Adrian 'Dagurashibanipal' von Bidder wrote: > > > On Tuesday 09 November 2004 23.44, Colin Watson wrote: > > > > N+0 days > > > > Official security support for sarge begins > > > > > > Will the start of official security support for sarge be announced > > > widely, > > > to get as much testing as possible? (Like: general debian-announce, press > > > contacts, ...) > > > > No. Why should it? The new release of Debian will be widely announce. > > > > How do you want to test official security support? Suddenly discover > > loads of vulnerabilities? > The day it is officially known that security support exist for sarge, > lots of people will migrate their servers to sarge, even if it is not > released as stable yet, so yes, it would be interesting that it is > announced, widely or not, so that sarge (not the security support) > get as much testing as possible before the release. Be sure that we take care that as much testing as possible is done before the final release. But - as we don't know when what will happen, it is a bad idea to promise certain actions on certain days now. (Of course, we know that a lot of users will upgrade as soon as security support is in place - I'll do the same with my servers. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: sarge security (was: Re: Release update: please upload to unstable; toolchain; buildds; ...)
* Marc Haber ([EMAIL PROTECTED]) [041113 19:20]: > On Sat, 13 Nov 2004 14:53:25 +0100, Martin Schulze <[EMAIL PROTECTED]> > wrote: > >Adrian 'Dagurashibanipal' von Bidder wrote: > >> Will the start of official security support for sarge be announced widely, > >> to get as much testing as possible? (Like: general debian-announce, press > >> contacts, ...) > >No. Why should it? > Because it was widely announced to start on September 15, and many > people are already running sarge. We learned from that mistake, and don't announce any fixed dates until we have it working (and, BTW, we announced also that we won't make it at that date - but I also know that enough magazines have just ignored that). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Debian menu and GNOME (request for help)
On Mon, 15 Nov 2004, Sebastien Bacher wrote: The Debian menu is only a submenu in GNOME and I'm not sure this is worth spending time and efforts for something that's redesigned upstream right now. Perhaps we should let it in this state for Sarge and work on a menu improvement for sarge+1 with GNOME 2.10 ? This is definitely not a good solution and I'd against the word "only" in the first line of your quote. The Debian menu is a menu which users can find in all graphical and text environments on a Debian GNU/Linux system and thus I would regard it as the *main* menu entry. The Debian menu is the *only* (and here 'only' is in the right sense) which is almost complete regarding the installed applications on the machine (and if you ask me personally it is the only one which is worth looking at). Backporting the user menu back to the Gnome version which will be shipped Sarge would be a really great thing for Custom Debian Distributions. Kind regards Andreas. -- http://fam-tille.de
Re: Request For Comments: Cycleroot-ng
On Mon, 15 Nov 2004, [ISO-8859-1] Salva Peiró wrote: I've built a `little` bash script (its size is 29Kb) that controls/manages background images, it's easily configurable for any of the existing window-managers and I've included many features. Because the idea to publish this here was mine I'd like to add something: It is a really nice script you wrote and it is very usable in connection to background images like I'm providing at http://people.debian.org/~tille/debian-background/ I'd suggest to continue with the name cycleroot because the '-ng' appendix sounds a little bit strange if there is no well known project cycleroot (and I wouldn't really call my little script I worte years ago in connection to my background images a "project". I've been using it extensively and now I think that it will be a good idea to make it available for public use. So I wanted to know if any of the existing Debian projects about window-managers (as Debian Desktop for example) would be interested in this package, or what do you think about. I have read about the docs available at debian-devel about package-building, and I think it will be easy for me to build a debian-package. I'd offer to sponsor such kind of package if there wouldn't be any better solution (which might be integration into a package were it fits into nicely) which would be the preferred solution from my point of view. Thanks for your efforts Andreas. -- http://fam-tille.de
Re: possible mass bug filing: spamassassin 3
Hi, * Ramunas Vabolis ([EMAIL PROTECTED]) [041116 09:15]: > I was wondering too, why there is no SA3 in sarge yet. A friend of mine > asked to write a couple words about this new version from a system > administrator view. Given that SA3 is a major change, and we had massive memory issues with the previous upload, the transfer to sarge is a bit delayed. I expect that SA3 will go in one of these days, and it is _definitly_ on my direct watch list. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Steinar H. Gunderson ([EMAIL PROTECTED]) [041116 12:30]: > On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: > > Given that SA3 is a major change, and we had massive memory issues with > > the previous upload, the transfer to sarge is a bit delayed. I expect > > that SA3 will go in one of these days, and it is _definitly_ on my > > direct watch list. > FWIW, we've run SA3 here (with a couple thousand users) in a woody backport > for almost a week now, with no problems. This is of course not to say there > is no bugs... :-) This is definitly one of the good news, and together with the other good news I was almost convinced to let SA3 through. However, I'm not too sure if bug 279981 needs to be solved prior to SA3 going to sarge, and I would like some feedback from the maintainer. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) [041116 14:55]: > On Tue, 16 Nov 2004, Andreas Barth wrote: > > * Steinar H. Gunderson ([EMAIL PROTECTED]) [041116 12:30]: > > > On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: > > > > Given that SA3 is a major change, and we had massive memory issues with > > > > the previous upload, the transfer to sarge is a bit delayed. I expect > > > > that SA3 will go in one of these days, and it is _definitly_ on my > > > > direct watch list. > > > FWIW, we've run SA3 here (with a couple thousand users) in a woody > > > backport > > > for almost a week now, with no problems. This is of course not to say > > > there > > > is no bugs... :-) > > This is definitly one of the good news, and together with the other good > > news I was almost convinced to let SA3 through. However, I'm not too > > sure if bug 279981 needs to be solved prior to SA3 going to sarge, and I > > would like some feedback from the maintainer. > IMHO it only *has* to be fixed in sarge if it affects upgrades from > 2.20, which is in stable. Otherwise, documentation on NEWS.Debian should be > enough. I agree with you that fixing is only required if this might be a problem for upgrades from woody. As this bug report is quite young, I think the best thing really is to give the maintainer enough time to take a look at it, and decide whether this needs to be fixed first (and if, how) or not. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Duncan Findlay ([EMAIL PROTECTED]) [041116 16:50]: > On Tue, Nov 16, 2004 at 03:01:03PM +0100, Andreas Barth wrote: > > I agree with you that fixing is only required if this might be a problem > > for upgrades from woody. As this bug report is quite young, I think the > > best thing really is to give the maintainer enough time to take a look > > at it, and decide whether this needs to be fixed first (and if, how) or > > not. > I don't recommend 3.0.1 go into sarge. 3.0.2 will be released shortly, > and that fixes a few more bugs that should make it mature enough. I understand this as that I should keep my block hint, and once 3.0.2 has survived 10 days in unstable, it will automatically go in? > This bug, specifically [...] I trust you as maintainer that you do the right thing. I just saw this bug on skimming through the bug list, and wanted to know your opinion on it. Thanks for your explanation. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Debmirror - problem
Hello, from time to time (about 1-2 time in three month) debmirror fails with the following error: --- $ /usr/bin/debmirror -v /tmp/debian --arch=i386 --host=debian.tu-bs.de --nosource --getcontents --dist=testing Mirroring to /home1/ftp/pub/debian/debian from ftp://anonymous:debian.tu-bs.de//debian/ Arches: i386 Dists: testing Sections: main,contrib,non-free,main/debian-installer Attempting to get lock, this might take 2 minutes before it fails. Get Release files. [0%] Getting: dists/testing/Release [0%] Getting: dists/testing/Release.gpgWon't mirror without dists/testing/main/binary-i386/Packages.gz signature in Release at /usr/bin/debmirror line 1094. releasing 1 pending lock... at /usr/lib/perl5/LockFile/Simple.pm line 182. Get Packages and Sources files and other miscellany. The target directory does not contain a single file: $ ls -aR /tmp/debian /tmp/debian: . .. dists .temp /tmp/debian/dists: . .. testing /tmp/debian/dists/testing: . .. main /tmp/debian/dists/testing/main: . .. binary-i386 /tmp/debian/dists/testing/main/binary-i386: . .. /tmp/debian/.temp: . .. dists /tmp/debian/.temp/dists: . .. testing /tmp/debian/.temp/dists/testing: . .. main /tmp/debian/.temp/dists/testing/main: . .. binary-i386 /tmp/debian/.temp/dists/testing/main/binary-i386: . .. When asking Google for this problem the question is often asked but never answered precisely. It is a little bit hard to file a bug report because it might be a cooincidence with several other things. At least I tried four different Debian mirrors as --host argument to make sure that the source host is not the problem. Any idea? Kind regards Andreas. -- http://fam-tille.de
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
* Steve McIntyre ([EMAIL PROTECTED]) [041201 12:20]: > Rather than argue about morality, legality, whatever, shouldn't we be > considering this in other terms - simple usefulness? Instead of asking > "why shouldn't this go into Debian?", ask "why _should_ this go into > Debian?". > > We seem to have a growing and worrying trend to pick up any random > free software and add it to the distribution without considering > whether it's actually useful or not... Agreed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#283751: ITP: fakepop -- fake pop3 server to warn users that only pop3-ssl is available
* Ron Johnson ([EMAIL PROTECTED]) [041201 12:40]: > On Wed, 2004-12-01 at 22:25 +1100, Matthew Palmer wrote: > > On Wed, Dec 01, 2004 at 05:17:33AM -0600, Ron Johnson wrote: > > > On Wed, 2004-12-01 at 11:04 +, Steve McIntyre wrote: > > > > So, let me get this straight - fakepop will allow people to log in > > > > (using their username and password) in the clear and THEN tell them > > > > that they should have used POP over SSL instead. Quite how is this > > > > better than "connection refused"? > > > Read the description: > > > "You can customize messages in /etc/fakepop/ directory to teach > > > your users how they should configure their mail clients to use > > > pop3-ssl instead of pop3" > > So I can put "All your mail is belong to us" in my /etc/fakepop/ directory, > > so that people know that their passwords *have* been successfully sent in > > the clear before being told to reconfigure their mail client? Well, *I'm* > > comforted. > But since the password isn't valid, does it make much difference? > > For example, my pop3 password isn't the same as my GnuPG passphrase. Well, but the probability that users who mis-use pop3 instead of pop3-ssl use their pop3-ssl password for pop3 is quite high. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes: > On Tue, 30 Nov 2004, Andres Salomon wrote: > >> Er. What? Since when does religion have anything to do w/ the >> anti-slavery movement? >> > > Exactly. For instance "Mine eyes haves seen the glory of the coming of > the Lord," the anthem of the abolitionists (and the Union forces in the > civil war) doesn't actually refer to theology but the superiority of Arch > over CVS. > LOL! Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Python is executable pseudocode, Perl is executable line-noise.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
* Christian Perrier ([EMAIL PROTECTED]) [041202 08:15]: > As already written in -women, this is the point which saddens me the > most in this thread. I'm really disappointed by seeing most > contributors just not realize why this package, as proposed, is likely > to hurt the feelings of several women (probably not all, I don't know) > as well as, indirectly or not, some men. > > I have indeed no intention for objection this package in any > matter. I'd just hope that the maintainer proposing it realizes that, > though he personnally doesn't think so, his work may hurt some people. > > Legal nitpicking is another issue, which I personnally do not consider > the most important one, indeed. > > The package is currently sexist, in my opinion. I just hope that > saying this loud enough will make the maintainers change their > mind. If it does not, well the result will be another sexist thing in > free software. > > I someday wish I had an opportunity to talk of this with Bruno > Bellamy, by the way (the artist whose drawings are used in this > package). His artwork (and good work) is widely used in the free software > community in France and (personal opinion, still) may sometime ring > this bell of sexism. I think you described the important issues quite well. Making a good distribution is more than just "upload any package which you legally could". Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
Michelle Konzack <[EMAIL PROTECTED]> writes: > Am 2004-12-02 08:44:34, schrieb David Weinehall: > >> Really, she's 13, and you think it'd do any difference whatsoever to >> expose her to a pixelled image of a nude woman?! Sheesh. Either >> you've been shielding her completely (no TV, no advertisments, >> no magazines, no Internet), or you need a reality update. > > And if she does not like violence and naked people ? > Well, nobody is forced to install/use hot-babe. >> Worried parents should realise, that if their kids are old enough to >> administrate a Debian-machine to the level of installing their own > > She has an IQ enorm and will make her Lycee examen next year. > 4 years before the others... > > She do not like to see everywhere naked People... > See above. Cheers, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 It's *GNU*/Linux dammit!
Re: RFC: common database policy/infrastracture
On Sat, 20 Nov 2004, sean finney wrote: this sounds like a good plan, i'll upload this after i do the update and some final testing of the last set of changes i've made. I've found your stuff at http://people.debian.org/~seanius/policy/examples/ from today and I'm really impressed. My question is now whether I can help anything to get postgresql into the same state as you prepared for mysql. Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Sat, 20 Nov 2004, sean finney wrote: On Sat, Nov 20, 2004 at 06:23:46PM +0100, Andreas Tille wrote: deb http://people.debian.org/~seanius/policy/examples/ ./ deb-src http://people.debian.org/~seanius/policy/examples/ ./ More questions on your version 0.7: - I asked in previous mail what to do for PostgreSQL support. While having a quick view on the code I wonder if just using a variable for the database server most of the code could be shared between databases servers. Is this to naive? - The application I want to package (GnuMed) has a bootstrapping script using a configuration file which cares for installation of several SQL code files in the correct sequence. This bootstrap script has to know the database administrator password. Formerly I did this the following way ... db_get gnumed/pgsql/admin-pass insert_passwd_into_temporary_config_file $RET bootstrap_gnumed_database --config temporary_config_file rm temporary_config_file My problem is now: How to address gnumed/pgsql/admin-pass in your dbconfig-common framework? Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Thu, 2 Dec 2004, sean finney wrote: most of the script stuff could be shared in between the two, yeah. i designed the system such that it could eventually handle supporting multiple database types, as well as packages that support multiple database types themselves. then, i proceeded to start with what i know :) currently, i'm using code from wwwconfig-common for doing the actual db stuff, and there is pgsql support in that package, so i don't think implementing pgsql support would be initially too hard. Well, my question is basically: Should I just copy and search+replace the mysql stuff to pgsql (which is error prone for future changes which are quite possible) Or should we do something like inserting a variable in all these scripts for the database and use a parameter or even do something like
Re: Bug#284219: please remove gnu-standards
* Ben Pfaff ([EMAIL PROTECTED]) [041204 18:25]: > Package: ftp.debian.org > Version: 2004-12-04 > > Please remove the gnu-standards package (that I maintain). Its > use of the GNU FDL violates Debian's DFSG, so it cannot remain in > the distribution. I think it might be a good thing if you orphan this package before you ask for removal, especially as you (and we all) know that GFDL-docu is allowed in the upcoming release of sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#284219: please remove gnu-standards
* Glenn Maynard ([EMAIL PROTECTED]) [041204 22:25]: > 2004-004 is not "allow non-free documentation in main for Sarge; we > don't care"; it's "allow non-free documentation in main because we don't > have time before Sarge to deal with it all". In no way does it discourage > maintainers with the time and inclination to deal with it before Sarge > from doing so. Well, handling it in a good way is of course appreciated, one way you proposed yourself: > (I'd suggest that gnu-standards be moved to non-free, though, not removed.) Just dropping on the floor is not appreciated. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#284283: ITP: fairuse -- spam filter based on sender identity verification
* Stephen Birch ([EMAIL PROTECTED]) [041205 09:10]: > Package: wnpp > Severity: wishlist > > * Package name: fairuse > Version : x.y.z > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://www.example.org/ If you don't mind to update this information, it might be good :) > * License : Free for non-commercial use means non-free, right? > Description : spam filter based on sender identity verification > > Subject to license verification (DFSG compliant): > > FairUCE is a spam filter that prevents spam from reaching the > recipient's inbox by verifying the identity of the sender. It will stop > the vast majority of spam without the use of a content filter, and > without requiring a probable spam or bulk folder that needs to be > checked periodically. Is the name FairUCE or fairuse? And, what is the major advantage over e.g. using SPF? (In other words: In which way is the verification done?) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: charsets in debian/control
* Petter Reinholdtsen ([EMAIL PROTECTED]) [041205 11:30]: > [Peter Samuelson] > > We seem to be moving to a de facto standard of UTF-8 for non-ASCII > > characters in debian/control files. This is not specified in Policy > > [1], but for hopefully obvious reasons, consistency is a Good Thing, > > and UTF-8 seems to be the best solution for this sort of thing. > Some will argue that only ASCII is acceptable in debian/control files. > I am not one of these. > > I agree that we should standardise on UTF-8 for both the changelog and > the control file (and the copyright file, for the upstream author and > package author names). We need to be able to correctly represent the > names of people, and it can not be done using ASCII only. > > Good to see that most packages already uses UTF-8. I hope the > packages using other charsets can be converted to UTF-8 as soon as > possible. There are different way to view that, and there is a policy bug about that very topic. I think most of us agree that non-UTF-8-characters are not a good idea (please note the UTF-8-characters is a superset of ASCII). For some places (like package names), I think most of us even agree that only ASCII-characters should be used. Also, there is the proposal that in other fields (i.e. names), an translation should (also) be used if the characters are not in some basic classes (more or less: ASCII plus ASCII-similar letters). So, I personally consider non-UTF-8-characters an bug, and UTF-8-not-ASCII on the way from bug to allowed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: charsets in debian/control
* Josselin Mouette ([EMAIL PROTECTED]) [041205 13:05]: > Le dimanche 05 décembre 2004 à 11:43 +0100, Andreas Barth a écrit : > > I think most of us agree that non-UTF-8-characters are not a good idea > > (please note the UTF-8-characters is a superset of ASCII). For some > > places (like package names), I think most of us even agree that only > > ASCII-characters should be used. Also, there is the proposal that in > > other fields (i.e. names), an translation should (also) be used if the > > characters are not in some basic classes (more or less: ASCII plus > > ASCII-similar letters). > > > > So, I personally consider non-UTF-8-characters an bug, and > > UTF-8-not-ASCII on the way from bug to allowed. > > Many of us have names that can't be written using ASCII. Furthermore, > the Debian tools need consistency between the developer name in the > changelog and the Maintainer/Uploaders fields in the control file. The > only way for these developers to have a policy-compliant changelog > without having their uploads considered as NMUs is to encode the control > file in UTF-8. Though I agree on your last statement (and please, remember, I'm from germany where non-ASCII-characters are also in common use), I still consider that UTF-8-not-ASCII has not finally reached ok, but it's on the way to it (and I consider this a good thing). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Duelling banjos or how a sane community goes crazy
Hi fellow developers, I failed in ending this thread when I posted http://lists.debian.org/debian-devel/2004/12/msg00016.html instead I caused two trolls making even more noise. I hope all you people are aware that you are causing a new duelling banjo case and helping out Google to connect Debian with hot-babes. This stupid thread made its way even in a German Linux news feed ... http://www.pro-linux.de/news/2004/7569.html even if you do not understand German: I would love if Debian would become famous for releasing Sarge instead of discussing about hot-babes. I have not read the contents of most of all these mail but even Godwin's law was issued. My great plea to all you people who are not able to stop their temper to discuss all their feelings here: 1. Please double check whether your topic is really relevant for Debian. 2. If you feel obliged to continue to a thread which might Debian connect to porn sites for Google or any other search machine just fix an RC bug first and then send your mail. 3. Go to debian-curiosity with mails which do not belong to debian-devel. Kind regards Andreas. PS: I just cleared my very fast /dev/null device for responses to this mail of my own. The sense was to reduce SPAM mails to this list and not to produce even more - just in case people did not understand my broken English. -- http://fam-tille.de
Re: Bug #277824; is the hotkeys maintainer dead?
* Thomas Folz-Donahue ([EMAIL PROTECTED]) [041206 04:00]: > Where is Anthony Wong? > [...] > debian-developers, now I turn to you. Where is Anthony Wong, and how > can I get this feature-restoring patch in the hotkeys package? Please see http://www.debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-mia-qa for how to deal with such issues. The maintainer is currently un-available, so you need some Developer who does a NMU. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#282742: Move daily find run later
On Sat, Nov 27, 2004 at 05:32:20PM +0100, Peter Palfrader wrote: > On Sat, 27 Nov 2004, Andreas Metzler wrote: >> On 2004-11-24 Martin Schulze <[EMAIL PROTECTED]> wrote: >>> Package: findutils [...] >>> It would be nice if the daily find run could be moved behind the >>> logrotate and sysklogd runs (maybe as zz_find) so that log files which >>> could grew quite large were already compressed. >>> Alternatively, I could move the sysklogd script to 00_sysklogd which >>> would leave logrotate (hmm, and the apache compress & rotate mechanism). >> [...] >>> PS: I wonder if for similar reasons the directory should be id >>> based entirely. >> Hello, >> I do not have any strong feelings about this. - If people think it to >> be the smart thing to do I can change it. However as the respective >> file is a dpkg-conffile it will be a PITA (I would mv >> /etc/cron.daily/find /etc/cron.daily/zz_find in preinst on upgrades) >> and I do not want to repeat the exercise. > zz_find? That's a really ugly name. I'ld rather not have it changed if > it means living with such a beast. Have you got any better ideas? Afaik the only possibilty to move the job is by giving it a name that sorts later. cu andreas
Re: Debian's status as a legal entity and how it could effect a potential defense.
* Hamish Moffatt ([EMAIL PROTECTED]) [041206 13:45]: > Having said that, this package doesn't really advance Debian in any > way. It won't gain us any users [...]. And that's the reason why I think it should not be included. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#282742: Move daily find run later
On 2004-12-07 Stephen Gran <[EMAIL PROTECTED]> wrote: > This one time, at band camp, Andreas Metzler said: >> On Sat, Nov 27, 2004 at 05:32:20PM +0100, Peter Palfrader wrote: >>> On Sat, 27 Nov 2004, Andreas Metzler wrote: >>>> On 2004-11-24 Martin Schulze <[EMAIL PROTECTED]> wrote: >>>>> Package: findutils >> [...] >>>>> It would be nice if the daily find run could be moved behind the >>>>> logrotate and sysklogd runs (maybe as zz_find) [zz_find is ugly] >>> zz_find? That's a really ugly name. I'ld rather not have it changed if >>> it means living with such a beast. >> Have you got any better ideas? Afaik the only possibilty to move the >> job is by giving it a name that sorts later. > Do the run-parts stuff, and then run this special script in /usr/share > last, if it exists. A little ugly and special case, but I think I'd > rather have that than a zz_find script (ick) I am not sure I read you correctly. You want cron* to change support not only /etc/cron*/ but also /usr/share/cron/tabs/pleaserunmeaftercron*? cu and- already giving up on this bugreport -reas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: charsets in debian/control
* Roger Leigh ([EMAIL PROTECTED]) [041207 00:40]: > I think going to UTF-8 as the default locale charmap for all locales > is a feasable goal for etch, as is recoding everything to UTF-8 (where > it makes sense). "feasable goal" and "etch" are the magic words I think: I agree on that, but I don't want to claim that we are already there today. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: menu-method for .desktop files?
On Wed, 8 Dec 2004, Bill Allombert wrote: So we could: move kdm:/usr/share/apps/kdm/sessions/ to menu-xdg:/usr/share/xdg/sessions/ Perhaps a stupid question because I do not understand all this menu stuff: Would this (together with Gnome 2.8) fix the user menus in Gnome??? This would be reall great for Sarge release! Kind regards Andreas. -- http://fam-tille.de
Re: Bug#282742: Move daily find run later
On 2004-12-07 Stephen Gran <[EMAIL PROTECTED]> wrote: >>>>>> On 2004-11-24 Martin Schulze <[EMAIL PROTECTED]> wrote: >>>>>>> Package: findutils >>>> [...] >>>>>>> It would be nice if the daily find run could be moved behind the >>>>>>> logrotate and sysklogd runs (maybe as zz_find) [zz_find is ugly] [...] > No, I was thinking that since findutils is both Essential and Priority: > Required, this one job could be special-cased, not that there should be > general support for doing this sort of thing all over the place. I > realize that that's the kind of thing that 'opens up the door' so to > speak. Perhaps that by itself points to my idea being a bad one. It > was just a thought, and probably a beer-fueled one at that. > I was sort of thinking along the lines of "there are some things that > cron does on every sytem, since those jobs are installed by essential > packages - wouldn't it be cleaner to integrate them into cron and let > cron do the sorting, rather than having to do naming hacks?" [...] I see. I think the premiss does not apply: While findutils is installed on every debian system, the cronjob does not run on everybody's system, many users choose to disable it. Anyway the solution seems to be overengineered for the problem at hand. I have yet to decide whether * I'll close the bugreport with "request denied" or * go for zz_find or something like that anyway and get being crucified by anybody who has been able to preserve a sense of aesthetics. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
ITP: g-wrap -- Scripting interface generator for C
Package: wnpp
Severity: wishlist
Subject: ITP: g-wrap -- Scripting interface generator for C
Package: wnpp
Severity: wishlist
* Package name: g-wrap
Version : 1.9.3
Upstream Author : Andreas Rottmann <[EMAIL PROTECTED]>
Rob Browning <[EMAIL PROTECTED]>
Christopher Lee <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/g-wrap
* License : LGPL
Description : Scripting interface generator for C
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
G-Wrap takes a set of interface declarations (written in Scheme) and
wraps the described interface for Guile.
This is the sucessor of G-Wrap 1.3.4 (packaged as libgwrapguile-dev and
libgwrapguile). It is packaged as a new source package since G-Wrap 1.3.4
is still needed to build GnuCash, although GnuCash CVS has received patches
to allow building with G-Wrap 1.9.x, so the old G-Wrap packages can be
faded out sometime after the release of GnuCash 1.8.10.
The source package g-wrap will procduce the following binary packages:
Package: g-wrap
Architecture: any
Depends: guile-1.6, guile-1.6-slib, guile-library (>= 0.1.1),
libgwrap-runtime0-dev (= ${Source-Version})
Conflicts: gwrapguile-dev
Description: Scripting interface generator for C
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
.
G-Wrap takes a set of interface declarations (written in Scheme) and
wraps the described interface for Guile.
Package: libgwrap-runtime0-dev
Section: libs
Architecture: any
Depends: libgwrap-runtime0 (= ${Source-Version}), libffi3-dev, libc6-dev
Description: Scripting interface generator for C - runtime
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
.
This package contains the development files for the runtime shared
libraries.
Package: libgwrap-runtime0
Section: libs
Architecture: any
Depends: ${shlibs:Depends}
Description: Scripting interface generator for C - runtime
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
.
This package contains the runtime shared library.
Package: guile-g-wrap
Architecture: any
Depends: ${shlibs:Depends}
Description: Scripting interface generator for C - Guile runtime
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
.
This package contains the Guile standard wrapset, needed by Guile
bindings generated by G-Wrap.
Re: binary NMUs and version numbers
Anthony Towns azure.humbug.org.au> writes: > Goswin von Brederlow wrote: [...] > > Another case that should be considered is the existing use of + for > > revisions of a cvs snapshot (e.g. mutt uses a + but always does so): > > 1.2-20041208 "<<" 1.2-20041208+2 "<<" 1.2-20041208+b1 > > Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the > upstream version? Or "1.2-20041208-1", or "1.2+cvs20041208-1" or whatever. > > -rw-rw-r-- 16 katiedebadmin 2908273 May 2 2004 >pool/main/m/mutt/mutt_1.5.6.orig.tar.gz > -rw-rw-r-- 16 katiedebadmin 412082 Nov 17 10:17 >pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz > > It seems to result in rather large diffs, and I can't really see the > benefit? [...] It is a payoff, larger diff for less frequent orig.tar.gz uploads. Instead of uploading a 3MB mutt_1.5.6-20040915.orig.tar.gz the mutt maintainers can upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915. cu andreas
Re: "Why is package X not in testing yet" - where's the page
* Frank Küster ([EMAIL PROTECTED]) [041209 17:25]: > I used to check testing migration with the link > > http://bjorn.haxx.se/debian/testing.pl > > but the host is no longer found. Does anybody know whether this is just > a temporary problem? Or is there an alternative site? Both nameservers (which are just one ip-adresses next to each other) are not found currently. If the author wants, I'd offer secondary DNS servers. Also, we might perhaps consider to integrate these scripts into pts or on release.d.o. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: "Why is package X not in testing yet" - where's the page
Frank KÃster debian.org> writes: > I used to check testing migration with the link > > http://bjorn.haxx.se/debian/testing.pl > > but the host is no longer found. Does anybody know whether this is just > a temporary problem? Or is there an alternative site? Hello, It worked yesterday, and I've no idea what the status of the /site/ actually is because the nameservers for haxx.se seem to be down. cu andreas
Re: ITP: g-wrap -- Scripting interface generator for C
[CC'ed Thomas Bushnell, since he has filed an ITA on gwrapguile] [EMAIL PROTECTED] writes: > Please, check the following bugs, rename or close them, however you prefer. > > > 1) #242467: ITA: gwrapguile -- Tool for exporting C libraries into... > > 2) #263127: O: gwrapguile -- g-wrap: Tool for exporting C... > I prefer to have them open until GnuCash is built against G-Wrap 1.9.3 and the gwrapguile source package can be removed. A note to Thomas: You can already try building GnuCash 1.8.9 (1.8.10 will have the patch applied, as it is already in CVS, both in HEAD and the 1.8 branch) when you apply the attached patch. Note that I have not yet done extensive testing with the G-Wrap 1.9.3-built GnuCash, so there *might* be problems, so I'm not sure if we want this to be a pre-Sarge change (although probably any problems would show up quick enough to fix them before Sarge). You can download G-Wrap 1.9.3 .debs by adding this to your /etc/apt/sources.list: deb http://people.debian.org/~rotty/debian/ unstable/ deb-src http://people.debian.org/~rotty/debian/ unstable/ ? app-file/gnome-glib.log ? app-utils/gnome-glib.log ? business/business-core/gnome-glib.log ? business/business-gnome/gnome-glib.log ? business/dialog-tax-table/gnome-glib.log ? engine/gnome-glib.log ? gnome/gnome-glib.log ? gnome-search/gnome-glib.log ? gnome-utils/gnome-glib.log ? report/report-gnome/gnome-glib.log Index: engine/gw-engine-spec.scm === RCS file: /home/cvs/cvsroot/gnucash/src/engine/gw-engine-spec.scm,v retrieving revision 1.73 diff -u -p -r1.73 gw-engine-spec.scm --- engine/gw-engine-spec.scm 13 Jun 2004 20:01:29 - 1.73 +++ engine/gw-engine-spec.scm 8 Oct 2004 16:03:28 - @@ -97,8 +97,6 @@ (gw:wrap-as-wct ws ' "QofIdType" "QofIdTypeConst") (gw:wrap-as-wct ws ' "Account*" "const Account*") (gw:wrap-as-wct ws ' "Account**" "const Account**") -(gw:wrap-as-wct ws ' "InvAcct*" "const InvAcct*") -(gw:wrap-as-wct ws ' "AccInfo*" "const AccInfo*") (gw:wrap-as-wct ws ' "AccountGroup*" "const AccountGroup*") (gw:wrap-as-wct ws ' "QofBook*" "const QofBook*") (gw:wrap-as-wct ws ' "GNCLot*" "const GNCLot*") Index: gnome-search/dialog-search.h === RCS file: /home/cvs/cvsroot/gnucash/src/gnome-search/dialog-search.h,v retrieving revision 1.11 diff -u -p -r1.11 dialog-search.h --- gnome-search/dialog-search.h 23 Oct 2003 04:32:57 - 1.11 +++ gnome-search/dialog-search.h 8 Oct 2004 16:03:28 - @@ -24,6 +24,8 @@ #ifndef _GNC_DIALOG_SEARCH_H #define _GNC_DIALOG_SEARCH_H +#include + #include "GNCId.h" #include "QueryNew.h" Index: report/report-gnome/dialog-column-view.h === RCS file: /home/cvs/cvsroot/gnucash/src/report/report-gnome/dialog-column-view.h,v retrieving revision 1.2 diff -u -p -r1.2 dialog-column-view.h --- report/report-gnome/dialog-column-view.h 22 Feb 2003 08:13:23 - 1.2 +++ report/report-gnome/dialog-column-view.h 8 Oct 2004 16:03:28 - @@ -20,8 +20,14 @@ * Boston, MA 02111-1307, USA [EMAIL PROTECTED] * / +#ifndef GNC_DIALOG_COLUMN_VIEW_H +#define GNC_DIALOG_COLUMN_VIEW_H + #include +#include typedef struct gncp_column_view_edit gnc_column_view_edit; GtkWidget * gnc_column_view_edit_options(SCM options, SCM view); + +#endif Regards, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Software Patents: Where do you want to stifle inovation today?
Re: ITP: g-wrap -- Scripting interface generator for C
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Andreas Rottmann <[EMAIL PROTECTED]> writes:
>
>> A note to Thomas: You can already try building GnuCash 1.8.9 (1.8.10
>> will have the patch applied, as it is already in CVS, both in HEAD and
>> the 1.8 branch) when you apply the attached patch.
>
> Just so you know, it's really my intention not to have *any* pre-Sarge
> changes.
>
Fine. I'll probably try building GnuCash 1.8.9 with G-Wrap 1.9.3
anyway, as maybe NetBSD pkgsrc switches to this setup and I want to
make sure it works. I'll file a wishlist bug ("build against G-Wrap
1.9.x") on GnuCash with the according patches once G-Wrap 1.9.x is in
Debian and I've made it work with GnuCash.
Cheers, Rotty
--
Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL
PROTECTED]
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Life is a sexually transmitted disease.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
David Pashley <[EMAIL PROTECTED]> writes: > On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying: >> I have looked at it. And I don't think it is an acceptable thing to ship as >> part of an operating system. I am an atheist and a liberal but the majority >> of people in the world are not. > > I don't think it is an acceptable thing to ship as it has no use. > Well, I tried hot-babe and it was a bit amusing for a minute or two, but I personally don't find it useful/amusing enough seeing any need for it. If, on the other hand, someone finds it useful aneough to package and maintain it, and there are a few other users interested in running it, well I can't really say anything against it. Usefulness is a subjective thing. Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Any technology not indistinguishable from magic is insufficiently advanced. -- Terry Pratchett
Re: Linux Core Consortium
* Brian Nelson ([EMAIL PROTECTED]) [041210 19:55]: > Yup. There's never been a sense of urgency. The RM's throw out release > dates and goals every once in a while, but no one seems to take those > seriously. Not true. (And, perhaps you noticed, the release team avoided to give specific days in the last time, and the timeline depends on a day N.) > And probably for good reason. Remarks like this _are_ driving the release back. > For the second straight > release, when we've gotten to a point that it seemed we were nearly > ready for a release, we then discover we have no security autobuilders. > The release then gets pushed back a few more months, while the plebeian > developers sit around twiddling their thumbs unable to help wondering > why the hell no one thought to set up the autobuilders in the 2+ years > we've been preparing a release. Be assured, the setting up the security autobuilders are a topic since I'm following the process of releasing sarge closely. Like e.g. in http://lists.debian.org/debian-devel-announce/2004/08/msg3.html which tells us that we need them for being able to freeze. Or, a bit later, http://lists.debian.org/debian-devel-announce/2004/09/msg5.html. This even tells: | The bad news is that we still do not have an ETA for the | testing-security autobuilders to be functional. This continues to be | the major blocker for proceeding with the freeze I don't think this mean that we suddenly discover it, but as other issues were more prominently blockers e.g. in July (like the toolchain), those issues were resolved back in September (and are still resolved now). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#282742: Move daily find run later
On 2004-12-08 Martin Schulze <[EMAIL PROTECTED]> wrote: > Andreas Metzler wrote: >> Anyway the solution seems to be overengineered for the problem at >> hand. I have yet to decide whether >> * I'll close the bugreport with "request denied" > Please don't do that but tag it wontfix instead if you "won't fix" this > bug report. Hello, My personal policy is to tag real bugs wontfix, but to close wishlist-requests, as it is a PITA for everybody involved to have the BTS cluttered with a great number of wishlist items. #282742 is somewhere in between, I'll respect your wish. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
amd64: ftp-masters questions (was: -= PROPOSAL =- Release sarge with amd64)
* Martin Michlmayr - Debian Project Leader ([EMAIL PROTECTED]) [040717 15:55]: > [AMD64 situation] > As to the > technical questions ftpmaster wants to raise, I'm quite disappointed > that they have not been posted yet because I was promised at DebConf > that it would happen soon. I've now asked someone I trust to find out > what these issues are exactly so hopefully progress will be made on > that soon. Is there any progress on this issue? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
historic mails from me - please ignore
Hi, I seem to have un-frozen a couple of historic mails. Sorry for the noise, please ignore them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: LCC and blobs
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Tim Cutts <[EMAIL PROTECTED]> writes: [...] >> It's not the driver software depends on the firmware to function; it's >> the hardware that depends on the firmware to function. The software >> dependency is a side-effect. > With the driver software loading the firmware I think it is pretty > clear that it depends on it. [...] It is obviously not "pretty clear", otherwise Tim wouldn't have defended a position different to yours. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: lintian warning about /usr/X11R6/lib
Neil Roeth <[EMAIL PROTECTED]> wrote:
> One of my packages, xfonts-kapl, installs fonts to
> usr/X11R6/lib/X11/fonts, as it should, according to policy 11.8.5. I
> get a lintian warning that nothing should install to /usr/X11R6/lib
> unless it uses imake, and that is just reflecting policy 11.8.7.
> Seems like those two section contradict each other;
Afaict 11.8.7 is more concerned about /usr/X11R6/{lib,bin,sbin,share}.
> where should the fonts go? If they are already going to the proper
> place, am I getting the warning because I forgot something else, or
> is it a lintian bug?
Imho it is a lintian bug, as long as our implementation of the
X-Window System lives in /usr/X11R6 the fonts will have to stay there.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
