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: 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
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
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: 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: 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.
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: 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:], '-' )
# Add the entry to the aliases
_aliases.append ( '"%s" "%s"' % (alias, name) )
# Boast
print 'Created %s aliases' % len(_aliases)
# Backup the existing file
_bak = _outfile + '.bak'
if os.path.exists ( _outfile ) and not os.path.exists ( _bak ):
try:
os.rename ( _outfile, _bak )
except OSError, val:
sys.stderr.write ( 'Cannot backup %s to %s: %s\n' % (_outfile, _bak,
val) )
sys.exit(1)
else:
print 'Backed up ex
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
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: 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
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: 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
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: 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: menu-method for .desktop files?
On Sat, 11 Dec 2004, Christoffer Sawicki wrote: 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! No, this is about fixing the available session types in gdm and kdm. Thanks for the clarification. Does anybody see a chance for fixing the user menu in Gnome 2.8 before releasing Sarge? Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Wed, 15 Dec 2004, sean finney wrote:
On Mon, Dec 13, 2004 at 08:36:19PM +0100, Andreas Tille wrote:
Do you have any hint for me how to help here and according to my
previous mail on debian-devel how can I obtain debconf settings
for the specific package ( db_get gnumed/pgsql/admin-pass)
because I did not understand how you planned to do this.
there's a file in /etc/dbconfig-common per-package that has these
settings in a shell script include format, so you could essentially
do something like
. /etc/dbconfig-common/$package.config
this is to work with the "debconf is not a registry (tm)" philosophy.
this config file is also sourced in all the maintainer scripts, setting
new default values in the .config and is used for the authoritative
values during the other scripts.
Yes, but I do not want to store the password *anywhere* - it could even
be removed from debconf database because it makes no sense to store it
in case the local maintainer changes the database password the value
is absolutely useless in any config file or debconf database. Moreover
it is even a security risk to store a password in an additional place.
So my question remains: How to obtain the admin-pass value for the
database application in question *inside* the postinst script.
Otionally we should remove it from debconf database in the end of the postinst
script.
the only problem i see with "any" is that in the future there may be
more non-sql database types handled this way. in the existing framework
there's a debconf variable package/dbtype which gets the dbtype
in question, which is i think what you'd use. now that i'm taking
a look at what's currently there, i see that i'm not actually writing
this variable to the config file. i think that was originally because
i didn't want it to be something configurable if the package didn't
support it.
the plan as it stands now is to have maintscripts for each dbtype,
and then to also have a central master maintscript, to which you can
feed environment variables such as the supported database types. this
central script would then take those and populate a the dbtype template
as a select question. something like
dbtypes="mysql postgresql"
. /usr/share/dbconfig-common/dpkg/config
Sure. My problem with your current 0.7 version is that yu provide *.mysql
scripts which are about 90% reusable for postgresql. IMHO we should do
something like
{config,postinst,postrm,preinst,prerm}
which source a further file containig special things for the database
in question according to the variable $DBTYPE like
. /$DBTYPE/`basename $0`
This avoids mainly doubling of code.
Well, I guess this might be solved by "su" as mentioned above, but
my problem is, who to access the values the user have input in the
debconf questions? I need to know some of these values in the
script.
a ". /etc/dbconfig-common/$package.config" should take care of that.
As I said - I do not want to write passwords into extra files. But if this
file would be created by the config script I could read this file in postinst
and remove the password afterwards from there while keeping the other
values untouched. I did not really tested the dbconfig-common stuff because
I was unsure about the postgresql issue but did I understand you right,
that this file exists after finishing the configure script?
Depends
This declares an absolute dependency. A package will not be
configured unless all of the packages listed in its Depends field
have been correctly configured.
and since the postinst script is where all the db-changing code occurs,
you don't have to worry about whether or not the locales is being run
before the main package, if i'm understanding both you and policy :)
Well, the policy speaks only about *configuration*. But the main database
is installed in the *postinst* script. I did not found anything about the
fact that the postinst from a dependant package has to be installed first.
But the locale part of the database only installs if the main server exists
in the postgresql database.
also, fyi, i have initial postgresql support in the latest version of
the package (0.8, which i haven't uploaded yet, but will be in the next
day or two). the one thing lacking is proper dumping and recovering from
errors, as i haven't spent enough time looking at the pg_dump manpage.
I'd volunteer to check that.
ps: i'm not cc'ing d-d, but feel free to do so in your replies if you
like.
Done, because I think it is interesting also for others.
Kind regards
Andreas.
--
http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, Olaf van der Spek wrote: Yes, but I do not want to store the password *anywhere* - it could even be removed from debconf database because it makes no sense to store it in case the local maintainer changes the database password the value is absolutely useless in any config file or debconf database. Moreover it is even a security risk to store a password in an additional place. If it's only readable by root, how much of a risk is it really? Why should I use md5 passwords if they are stored in /etc/shadow which is only readable by root? IMHO, it is a good idea not to store passwords in clear text if there is no reason to do so. If a temporary file at install time suffices I just prefer this over permanent storage. Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, Olaf van der Spek wrote: Because system passwords aren't 'needed' by any applications to authenticate themselves to the system, while database passwords are. No, they are not needed in the file system. They are needed inside the database and they are save there (assumed that the database server has no bugs). True, but how many database apps work without storing the password? At least these that do authentification directly against the database should not store their passwords in an extra file. This is the case for the application I'm currently working on (GnuMed) where the client does the authentication via user interaction. Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, Olaf van der Spek wrote: Is that the majority or the minority of applications? Take for example a web application like a forum. It requires the password so it can connect to the database. It can't/won't ask the password from the user. Can you tell me any reason why I should store a clear text password in a text file for *my* application only because *other* applications would require this? Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, sean finney wrote: but something to point out: dbconfig-common already performs the administrative actions needed to set up the database and database user in the first place, so does your package even need the admin password? The applilcation I want to package comes with a quite complex bootstrap script which does *all* setup (including creating the database and adding an admin account). So what we could do here: 1. From a Debian point of view provide an option for debconf which just tells postinst not to create the database etc, because the bootstrap script would take over this job. Just provide the data which are needed in a defined interface instead. 2. From the application point of view I could ask people to include an option which prevents the bootstrap script from doing the work which is just done. I guess this is no big deal for the very responsive authors. take a look at 0.8 :) URL? I hope you would announce new versions or just move the package to experimental to keep people informed. this was the plan all along, but i had to start with what i knew. also, i discovered that you can't reliably use $0 in the maintainer scripts because when a package is first preconfigured before being unpacked the filename doesn't follow the same naming scheme. Sure. The use of $0 was just to make things clear as a sketch. The implementation has to be a bit more precise... but now there are subscripts for the supported mysql and pgsql database types, and a larger common type (which will eventually support applications that support multiple db types): mini-me[~]10:28:00$ ls /usr/share/dbconfig-common/dpkg/ commonpostinstpostrm.mysql preinst.pgsql configpostinst.mysql postrm.pgsql prerm config.mysql postinst.pgsql preinstprerm.mysql config.pgsql postrm preinst.mysql prerm.pgsql While this is only cosmetics I would prefer storing the database specific stuff in separate directories. If we will have more databases it would be more easy to read. for the admin pass, it should be configurable globally whether or not the admin password is stored at all. This would be nice. for the user password, it will have to be stored in a file somewhere anyway for whatever application uses the database, so i'm not too concerned about that. No problem with that. If the package maintainer thinks it has to be deleted afterwards - there will be a way to do so ... i'm not against providing a way around that, however, if there really is a situation in which you wouldn't need the password. If all else fails: dd if=/dev/zero of=/dev/hda ;-) i believe that when policy speaks of configuration it is in fact speaking of the postinst script. the .config script is usually referred to as "pre-configuration". with pre-configuration, it is true that you can't rely on any dependencies being met, but touching files in the .config script is generally a bad practice, and i don't do anything other than ask debconf questions in the config script. Well, if this is really the case than it would save a certain amount of time for me. While I think this is a perfectly reasonable requirement I remember times were this was not the case and I had trouble to work around this. Kind regards Andreas. -- http://fam-tille.de
Problems to upload
Hi, did something changed in the upload queue?: $ dput *.changes Uploading package to host ftp-master.debian.org ... Good signature on /home/tillea/debian-maintain/sponsor/dosbox/dosbox_0.63-2.dsc. Uploading via ftp dosbox_0.63-2.dsc: Error '553 Could not create file.' during ftp transfer of dosbox_0.63-2.dsc Traceback (most recent call last): File "/usr/bin/dput", line 909, in ? main() File "/usr/bin/dput", line 858, in main progress=config.getint(host,'progress_indicator')) File "/usr/share/dput/ftp.py", line 54, in upload f, 1024) File "/usr/lib/python2.3/ftplib.py", line 415, in storbinary conn = self.transfercmd(cmd) File "/usr/lib/python2.3/ftplib.py", line 345, in transfercmd return self.ntransfercmd(cmd, rest)[0] File "/usr/lib/python2.3/ftplib.py", line 327, in ntransfercmd resp = self.sendcmd(cmd) File "/usr/lib/python2.3/ftplib.py", line 241, in sendcmd return self.getresp() File "/usr/lib/python2.3/ftplib.py", line 214, in getresp raise error_perm, resp ftplib.error_perm: 553 Could not create file. $ dupload *.changes dupload note: no announcement will be sent. Uploading (ftp) to ftp-master.debian.org:/pub/UploadQueue/ [ job dosbox_0.63-2_i386 from dosbox_0.63-2_i386.changes dosbox_0.63-2.dsc, md5sum ok dosbox_0.63-2_i386.deb, md5sum ok dosbox_0.63-2.diff.gz, md5sum ok dosbox_0.63-2_i386.changes ok ] Uploading (ftp) to anonymous-ftp-master (ftp-master.debian.org) [ Uploading job dosbox_0.63-2_i386 dosbox_0.63-2.dsc 0.9 kBdupload fatal error: Can't upload dosbox_0.63-2.dsc: YOU MUST USE PASSIVE MODE. Type: passive at /usr/bin/dupload line 506 $ dupload --to erlangen *.changes dupload note: no announcement will be sent. Uploading (ftp) to ftp.uni-erlangen.de:/public/pub/Linux/debian/UploadQueue/ [ job dosbox_0.63-2_i386 from dosbox_0.63-2_i386.changes dosbox_0.63-2.dsc, md5sum ok dosbox_0.63-2_i386.deb, md5sum ok dosbox_0.63-2.diff.gz, md5sum ok dosbox_0.63-2_i386.changes ok ] Uploading (ftp) to erlangen (ftp.uni-erlangen.de) [ Uploading job dosbox_0.63-2_i386 dosbox_0.63-2.dsc 0.9 kBdupload fatal error: Can't upload dosbox_0.63-2.dsc: YOU MUST USE PASSIVE MODE. Type: passive at /usr/bin/dupload line 506 When trying manual ftp I found out that dosbox_0.63-2.dsc was put to master but with zero bytes and I'm not allowed to remove this file. Kind regards Andreas. -- http://fam-tille.de
Re: Problems to upload
On Thu, 16 Dec 2004, Steve Langasek wrote: See the dcut command (or the README file in UploadQueue) for information on how to remove broken files from the ftp server. I do not find the string dcut in ftp://ftp-master.debian.org/pub/UploadQueue/README but the *.commands file would probably help as well. But what me *really* concerns is why dput and dupload failed in the first place. Especially the hint to "PASSIV MODE" smells like something has changed to the situation before. I do not know something about passive mode but I'm afraid somebody has changed something at our firewall which resulted in problems with FTP protocol. Kind regards Andreas. -- http://fam-tille.de
Re: Problems to upload
On Fri, 17 Dec 2004, Andreas Metzler wrote: But what me *really* concerns is why dput and dupload failed in the first place. Especially the hint to "PASSIV MODE" smells like something has changed to the situation before. [...] | dput (0.9.2.15) unstable; urgency=low | | * More verbose error message for ftp uploads. And also use active | ftp per default. (Closes: #268489) | [...] | -- Christian Kurz <[EMAIL PROTECTED]> Sat, 13 Nov 2004 22:21:06 +0100 Perhaps this was the reason but I should probably reopen the bug which claimed more verbose error messages. The failure was caused because only passive mode seems to work - at least I was asked by manual ftp-client to switch to passive mode (I do not know until know what passive excatly is). Also dupload caused a passive mode related error message. In contrast to this dput just stopped with a Python error. Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Fri, 17 Dec 2004, Karsten Hilbert wrote: Well, see, the GnuMed bootstrapping does a lot more advanced things regarding "the database user". There's users and groups with varying levels of access to the database. However, if dbconfig-common creates the admin account we just use it. We can also deal with the fact that the database is pre-created, no problem. Fine. Agree. We might need to double-check but I think we are in good shape on that already. I guessed this. BTW, do you think that the daily snapshot service will be started soon or should I switch back to check out from CVS. I'd prefer the snapshot because this is a certain file which I could refer to. I think you need to be very clear on what you mean here. There is an admin account for *PostgreSQL* (eg. postgres in most cases) On Debian GNU/Linux the user postgres has no password (by default). You can only "su postgres" and use the ident method from localhost. but there's also an admin account for the database "gnumed" inside PostgreSQL (usually called gm-dbowner). The latter one owns all objects in that database and grants rights to other user groups. I was talking about this user as "administrator" of the GnuMed database. I see no need to store the password of gm-dbowner in any file inside the file system. Thus it should be avoided. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#289043: ITP: perlprimer -- [Biology] Graphical design of primers for PCR
On Fri, 7 Jan 2005, Andreas Rottmann wrote: Wouldn't the package be better named "pcrprimer" or something like this? The fact that it is written in perl seems not to be relevant to the user. The name "perlprimer" makes me rather think of a primer (tutorial) for perl. Hmm, that was my first thought, too. OTOH, the upstream package is named perlprimer... We have several packages which are differently (and better / more logical) named than the upstream packages. I really like the name pcrprimer because it exactly describes what the package is. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#294506: zope-textindexng2: Package builds incorrectly on amd64: Python site-packages files do not install
On Wed, 9 Feb 2005, Per Bojsen wrote: Package: zope-textindexng2 Version: 1:2.0.8-4 Severity: normal When this package is built on the amd64 architecture, the files that are to go in the /usr/lib/python2.2/site-packages/zope-textindexng2 directory fail to be installed. This is not obvious when the package is being built, but leads to numerous test errors during installation of the package [1]. I tracked this down to the debian/install file. The following patch allowed me to build the package correctly on amd64 and it now installs with all tests passing: --- debian/install.orig 2005-02-09 22:25:08.575769172 -0500 +++ debian/install 2005-02-09 22:10:34.499301101 -0500 @@ -1,2 +1,3 @@ build/lib.linux-i686-2.2/*usr/lib/python2.2/site-packages/zope-textindexng2 +build/lib.linux-x86_64-2.2/* usr/lib/python2.2/site-packages/zope-textindexng2 debian/zope-textindexng2.pth usr/lib/python2.2/site-packages/ I just added the line for the x86_64 architecture. This works because dh_install ignores patterns that do not match. However, if someone is building both the i386 and amd64 version of the package in the same build directory and forgets to do a clean between each build, then they could end up with a bad package where the amd64 files overwrite the i386 ones. The alternative is to have one install file for each architecture. Is this even possible? How is this situation handled in other packages? ... (see more details on the bug page) I would like to foreward this problem to this list, because I have no idea how to handle this bug right. I guess the patch would solve the problem but as the bug reporter mentioned it might lead to problems if you try to build on different machines. I think "forgetting" to clean is not really in issue if you use the default package building tools, but anyway I would rather fix this in the build process and do report the problem upstream. IMHO, the problem is caused by the fact that the package installs for instance $ file /usr/lib/python2.2/site-packages/zope-textindexng2/Levenshtein.so /usr/lib/python2.2/site-packages/zope-textindexng2/Levenshtein.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped into /usr/lib/python2.2/site-packages where normally python files (and there precompiled flavours) belong. Any hint, how to circumvent this? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 21 Feb 2005, Ingo Juergensmann wrote: On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: ... But then it doesn't matter anymore. These days, Debian is "infrastructure". We no longer make releases. We provide the basis from which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. That's true in some regards, but hasn't to do anything with the number of archs. Especially it is wrong regarding the fact about Custom Debian Distributions (if you mean this special term) because they reside inside Debian and in consequence do also cope with all architectures. There are reasons that people use such CDDs for only a single architecture and do some further adaptations to a CDD but this is a different issue. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Any reason why I'm not CCed by bugs of my packages?
Hi, I have an open bug against dict-wn ~> apt-cache show dict-wn | grep Maint Maintainer: Andreas Tille <[EMAIL PROTECTED]> but got no mail notification about #296197 - just have seen it via web interface. Any idea what went wrong here. (If I'm not absolutely wrong this is not the first case for this package.) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Any reason why I'm not CCed by bugs of my packages?
On Fri, 25 Feb 2005, Steve Langasek wrote: ~> apt-cache show dict-wn | grep Maint Maintainer: Andreas Tille <[EMAIL PROTECTED]> but got no mail notification about #296197 - just have seen it via web interface. Any idea what went wrong here. (If I'm not absolutely wrong this is not the first case for this package.) Perhaps there was some spam filter in your pipeline that tried to do natural language parsing of the text, and exploded the same way my brain did upon reading that message? Interesting idea but I doubt that. I also did not got my response and if I remember right in the past this also happened for another bug of the same package. I do not regard this as a hard issue but I wanted to make sure that this would not happen for others with more important packages. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Any reason why I'm not CCed by bugs of my packages?
On Mon, 28 Feb 2005, Joel Aelwyn wrote: I just make it a regular habit to scan my packages via the web interface, if only to remind myself about the wishlist bugs sitting on some of them. Sure, that's why I detected the bug just in time, but this personal habit is no excuse that a function of the BTS might work or might work not. Nothing's perfect. Sure - but arent we here to report and fix bugs - also the bugs of the BTS? I do not understand your posting. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian-Edu developer meeting in Nafplion, Greece
On Mon, 7 Mar 2005, Andreas Schuldei wrote: Debian-Edu will hold a Developer Gathering in Nafplion, Greece, from the 15th to 17th of April. http://www.debian.gr/~bilbo/nafplion/CANON0216.jpeg It looks really nice, but any help how to get there would be great. I suspect that I did something wrong when just booking a flight to Athens. Perhaps I was a little bit quick when booking my flight but according to support your "Book quick" mail: My first research in the morning had a certain result and after waiting two hours and reloading the page it was by 20 Euro increased and when I tried the concrete reservation it was increaseb by further 15 Euro. So please keep in mind that prices keep on increasing from hour to hour. There are other pictures with palm trees available, too. Nice, but a map and the information about the nearest airport would help more. Perhaps I have to change my booking. See you in Nafplion! Definitely. Do we see the DPL there. ;-) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, 8 Mar 2005, sean finney wrote: you could easily extend the script i wrote to unencrypt/loop-mount a filesystem-in-a-file without too much effort. prod me enough and i might do it myself. Prodding. :) Moreover I'd suggest to send the result of it as patch to the gpg package for inclusion into /usr/share/doc/gpg/examples . Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious kernel problems on new i386 hardware
On Thu, 10 Mar 2005, Mike Hommey wrote: On Thu, Mar 10, 2005 at 03:10:12PM +0100, Andreas Tille <[EMAIL PROTECTED]> wrote: ERROR: Removing 'trm290': Device or resource busy ERROR: Removing 'vis82cxxx': Device or resource busy pivot_root: No such file or directory /sbin/init: 432: cannot open dev/console: No such file Kernel panic - not syncing: Attempt to kill init! Let me guess... you are using devfs in 2.4, and /dev is empty if devfs is not mounted. Sorry, I did nothing but installing Debian from scratch and installing several kernel-image-2.6.x packages afterwards. I did no fiddling around with devfs whatever (to be honest I do not even have an idea why I should if everything would work fine). The only hint Google was able to reveal was a broken initrd which is not able to handle SATA - but as I said, I tried to disable SATA for exactly this reason (perhaps I failed but this does not explain why 2.4.x works). Please tell me what I should check and report to follow your idea. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious kernel problems on new i386 hardware
On Thu, 10 Mar 2005, Jacob S wrote: Which version of the Debian-Installer did you use? We had similar symptoms on a new Dell recently at work and had to grab the latest daily build to get a working version. I can check on the exact date of the daily build we used, if you want. On my desk I see only a CD with the hand written text "Sarge RC 2" and thus I'm relatively sure I took this one ... Are there any traces left in a logfile or something like that which contains the exact installer version? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious kernel problems on new i386 hardware
On Thu, 10 Mar 2005, Thomas Schneller wrote: mkinitrd -v /boot/initrd-2.6.x-x.img 2.6.x-x I guess you mean here "s/-v/-o/", right? Well, I did so mkinitrd -o /boot/initrd.img-2.6.10-1-686 2.6.10-1-686 (under # uname -a Linux wr-linux03 2.4.27-1-386 #1 Wed Dec 1 19:43:08 JST 2004 i686 GNU/Linux ) but nothing changed. The hint with the initrd problem was given when trying to get SATA work - but this will be only my next step once I switch SATA on in BIOS ... make sure to add this line to the grube menue.lst: initrd /boot/initrd-2.6.x-x.img Sure - I did not changed the default grub boot menu which is created by the kernel package. Not now - later, if the default Debian kernel works I normally go without an initial ramdisk. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious kernel problems on new i386 hardware
On Thu, 10 Mar 2005, Jesús Roncero wrote: I've recently had those problems also on a Dell server, using SATA too. The fine guys from #gpul helped me a lot on this. Basically, what happened to me is that kernel 2.4 mapped the SATA drive as /dev/hdc and kernel 2.6 mapped it to /dev/sda Well, after doing an sed -i "s/hda/sda/" /etc/fstab __AND__ switching BIOS from "conventional" (=no SATA) to "normal" (=SATA) __AND__ changing grub boot menu from kernel /boot/vmlinuz-2.6.10-1-686 root=/dev/hda3 ro to kernel /boot/vmlinuz-2.6.10-1-686 root=/dev/sda3 ro it worked. I really regard this problem as serious because it probably leaves people with SATA hardware with an unbootable system after kernel-image updates, because the kernel image packages just reinsert "root=/dev/hda?" into grub's menu.lst . Any idea how to solve this problem? Kind regards Andreas. -- http://fam-tille.de
Re: Serious kernel problems on new i386 hardware
On Fri, 11 Mar 2005, Miros/law Baran wrote: it worked. I really regard this problem as serious because it probably leaves people with SATA hardware with an unbootable system after kernel-image updates, because the kernel image packages just reinsert "root=/dev/hda?" into grub's menu.lst. Any idea how to solve this problem? ...by using partition labels in fstab? Sorry, I do not know anything about partition labels but if this is the solution it should be done in the installer and if this works in Grub menu.lst this should be done here as well. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical Bugreport for March 11, 2005
On Fri, 11 Mar 2005, BugScan reporter wrote: ... Number concerning the next release (excluding ignored and not-in-testing): 147 ... I'm quoting from previous bug reports: Bug stamp-out list for Feb 11 06:02 (CST) Number concerning the next release (excluding ignored and not-in-testing): 98 Bug stamp-out list for Feb 18 06:02 (CST) Number concerning the next release (excluding ignored and not-in-testing): 108 Bug stamp-out list for Feb 25 06:02 (CST) Number concerning the next release (excluding ignored and not-in-testing): 123 Bug stamp-out list for Mar 4 06:09 (CST) Number concerning the next release (excluding ignored and not-in-testing): 128 --- The question is: can we increase the pressure on maintainers of packages with RC bugs if we want to release? Currently we have an increase of RC bugs of 50% in 4 weeks. :-(( When browsing quickly through the list of bugs we could simply get below our "less than 100 bugs state" by just announcing to remove those buggy packages from testing which are optional or extra after say 10 days? Did I missed something like that? Any yes, while writing this I could tried to write a patch or do a NMU but I do not really see why people who provide patches or do NMUs should waste their time on RC bugs if the maintainer does not even care about tagging their bugs [help] or something that indicates that he is caring about the RC bug in the end of a Debian release cycle. Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies
On Sun, 13 Mar 2005, Michael Prokop wrote: I think replacing the prosper-package with ha-prosper wouldn't be a good choice. I'd like to provide ha-prosper in a separate package so when TeXciting is available there aren't any breakages with prosper. Recently I investigated some time in LaTeX based presentation tools. The consequence was: 1. Prosper is nice but development tsopped since about 3 years. 2. HA-prosper was kind of continuing the work of prosper. It is more enhanced and I even builded some packages for my private use of it until I noticed latex-beamer (see below). My impression was that while it is superior about prosper and should prosper replace regarding to this fact it is not really worth packaging because development is stalled as well because of the new TeXciting project. 3. LaTeX-Beamer has compatibility modes for prosper and ha-prosper. It is much more feature complete and flexible than both above. There is absolutely no reson to investigate time into any *prosper package because LaTeX-Beamer is the package your really want. For an example see http://people.debian.org/~tille/talks/200503_peking_cdd/index_en.html I do not know anything about TeXciting and thus I can not compare but before crowding the archive with a package like ha-prosper try LaTeX-Beamer. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sun, 13 Mar 2005, Steve Langasek wrote: - it must first be part of (or at the very least, meet the criteria for) scc.debian.org (see below) - the release architecture must be publicly available to buy new - the release architecture must have N+1 buildds where N is the number required to keep up with the volume of uploaded packages - the value of N above must not be > 2 - the release architecture must have successfully compiled 98% of the archive's source (excluding architecture-specific packages) - the release architecture must have a working, tested installer - the Security Team must be willing to provide long-term support for the architecture (?) - the Debian System Administrators (DSA) must be willing to support debian.org machine(s) of that architecture (?) - the Release Team can veto the architecture's inclusion if they have overwhelming concerns regarding the architecture's impact on the release quality or the release cycle length (?) - there must be a developer-accessible debian.org machine for the architecture. IMHO all these facts with exception of those "social" facts I marked (?) are fullfilled by Sparc. - there must be a sufficient user base to justify inclusion on all mirrors, defined as 10% of downloads over a sampled set of mirrors Hmmm, regarding to the fact that i386 makes a real lot of percentage it might be a quite hard limit to have 10%. I guess this reduces the number of supported architectures by fitting to a previousely defined number of architectures we are willing to support. - the architecture must be freely usable (i.e., without NDAs) - the architecture must be able to run a buildd 24/7 sustained (without crashing) - the architecture must have an actual, running, working buildd - the port must include basic unix functionality, e.g resolving DNS names and firewalling - binary packages must be built from the unmodified Debian source (required, among other reasons, for license compliance) - binaries for the proposed architecture must have been built and signed by official Debian developers - the architecture must have successfully compiled 50% of the archive's source (excluding architecture-specific packages) Seems also all be true for Sparc. - 5 developers who will use or work on the port must send in signed requests for its addition I'm DD and use Sparc (but do no active development to support this hardware). - the port must demonstrate that they have at least 50 users Just did wajig install popularity-contest on my Sparc machines. The problem is that I use a *minimum* set of packages on a server and the machines I mainly use as servers are Sparcs. These objective requirements would be applied both to the other eight architectures being released with sarge that are not currently regarded as candidates for release with etch, and also to any porter requests asking for new architectures to be added to the archive. I do not want to start a "This is my favourite architecture - just include ist" flamewar. It is just something I'm using and I feel the technical parameters you mentioned (and which are very reasonable) fullfilled, while I see reasons why SParc might show up more seldom in popularity contest for certain reasons. In general I would like to say that supporting a lot of architectures was an important difference between Debian and other distributions. I know the drawbacks of this but I just do not want to hide my opinion that I do not like the idea of reducing the number of supported architectures that drastical. IMHO the effect would be that people will start forking Debian for porting issues and we will loose the power of those porters while they will spend time for things they would not have to do else. I think we should at least vote about such a drastic change. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i has 99% support for filesystem labels (was: Re: Serious kernel problems on new i386 hardware)
On Mon, 14 Mar 2005, Andrew Pollock wrote: Sorry, I do not know anything about partition labels but if this is the solution it should be done in the installer and if this works in Grub menu.lst this should be done here as well. I gave some of the relevant people in the d-i team an education on the benefits of filesystem labels, to to the point where partman will create filesystems with a label, however I didn't manage to convince them to mount by the label in /etc/fstab Well, may be it sounds convincible to file RC bugs for beeing left with an unbootable system on SATA machines? But I did not tried with RC3 candidates and I will not have the chance to do this installation tests with my main working horse ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies
On Sun, 13 Mar 2005, Michael Prokop wrote: I do know many people who are used to ha-prosper and haven't switched to LaTeX-Beamer yet. As I said - there is a compatibility mode - but I did not tested it yet. ha-prosper needs less space than latex-beamer (not taking care of dependencies but ratio should be equalent): [EMAIL PROTECTED] ~ # apt-cache show ha-prosper | grep Installed-Size Installed-Size: 516 [EMAIL PROTECTED] ~ # apt-cache show latex-beamer | grep Installed-Size Installed-Size: 3364 Huh, what's this for an argument? I guess today we do not really have to care for this and as I said, the bigger size has its reasons ... And TeXciting might never be released, quoting Hendri - the author of ha-prosper: | I have reconsidered whether it will be possible | to finish this project. Taking into account also | the work that I'm doing on other packages and | my involvement in LaTeX3, I conclude that it will | unfortunately be very unlikely, that I will ever | finish that project. See his posting on ha-prosper-mailinglist for more details: http://listserv.surfnet.nl/scripts/wa.exe?A2=ind0503&L=ha-prosper&F=&S=&P=777 So this is no problem because we have latex-beamer. BTW, I guess TeXciting would have a similar size relation as you mentioned above and we would have to keep ha-prosper anyway according to your reasoning. So in my opinion it would be useful to provide a debian package of ha-prosper. In the end it is the business of people who are maintaining the package and I really hope that they will do a good job in maintaining orphaned software. So I can not keep you away from maintaining ha-prosper but my advise as somebody who had thought about this on my own and knowing that you have also to maintain a further package as dependency would be: Just have a look at latex-beamer's compatibility mode and think twice about it if is worth the effort. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 14 Mar 2005, Ingo Juergensmann wrote: Sorry for using "stupid", "braindead" and others. But there are no other words for crap like this, imho. Hmm, while I'm in principle share your point of keeping the architectures it does not sound very sane to be that harsh. If a group of volunteers faces the situation that they are not able to continue the work they did with the expected quality, they have to face real world and draw a decision. Normally everything what needed to be done was done and thus if enough people stand up and care for fitting the criteria (98% compiled packages, security for the arch, supporting the kernel). If there are no such people who do the work talking about "stupid" decisions makes no sense. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 14 Mar 2005, Martin Michlmayr wrote: For some SSC arches, it *might* not make a difference (possibly m68k) but others (e.g. s390 and mipsel) are typically used for servers or gateways, and you don't really want to run unstable in such environments. testing+security updates might be a compromise, but unstable is clearly not an option for a S390 box or a mipsel Cobalt gateway. TBM for leader. ;-) Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 14 Mar 2005, Andres Salomon wrote: Releasing a snapshot of unstable definitely seems like a step backwards. Of course, I understand the reason for suggesting it (and not wanting to support a testing distribution for SCC). Instead, I would suggest to porters that they base releases off Debian stable releases. When a stable release comes out, the distribution can be (re)built for all SCC archs; porters can then add their own packages and fixes on top of stable, as necessary. This has the added benefit of simplifying security maintenance; when a DSA is announced, porters can simply rebuild (or incorporate patches, if necessary) based on the security update. Developers can still track unstable from scc.d.o, so as to minimize the work necessary after a stable release (architecture-specific problems can be found and fixed as they occur in unstable, instead of suddenly popping up in a stable release). Porters are also in charge of their own d-i images, so there's no need to bother the RMs with it. While I'm not so deeply involved to decide whether this is technically doable but the sugguestions sounds as sane to me as your name implies. ;-)) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions for the DPL candidates
On Tue, 15 Mar 2005, Anthony Towns wrote: if you want a technical discussion instead of a political one it helps to ...not have it on a Debian mailing list. :-/ Quoting from http://lists.debian.org/debian-devel/ Development of Debian Discussion about technical development topics. You should file a bug report against debian-www if this is wrong. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, 15 Mar 2005, Julien BLACHE wrote: For $DEITY's sake. Will you please understand that the Ubuntu folks totally failed to inform their fellows about what was going on ? And at the time, there was no Canonical website, no Ubuntu website. Only a handful of patches up on no-name-yet. I think we deserved a better explanation. Hmmm, I do not remember that Corel did some better information policy when they made a Debian derived distribution. There are other examples as well. I do not want to compare Ubuntu with those commercial distributors, but if we build a FREE operating system nobody has to inform us about anything as long it is conform to our license. And no, I do not exactly know what Ububtu people are doing but I see no harm in it if they employ a certain amount of DDs as other companies do as well. Please could we concentrate back on our own problems instead of discussing the problems of other distributions. Our own problem is whether certain groups inside Debian have problems in communication with other interested people which do not (yet) belong directly to this group. I would answer this question with: Yes, by a certain amount. We have to enhance communication as a certain kind of documentation: 1. Reasonable protocols of discussion inside these groups are be useful for their own work. These protocols can be opened (we don't hide problems). 2. Lower barriere for potential helpers to step in (because they are informed about what's going on.) 3. This would (hopefully) reduce FUD. So why not setting up at a certain web space containing information about meeting of groups like the Vancouver meeting: 1. Date + Time 2. Location 3. Agenda 4. Invited people ---> This should be published before the meeting 5. Log about the points which were discussed after the meeting in form of a technical documentation Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, 15 Mar 2005, David Schmitt wrote: And if the security team is not able to support those arches as-is, someone will have to step up and do the work. Overly long delays for security updates also diminish the usefulness of $arch. I guess I missed the "Call for help on security issues on architecture xy" mail on debian-devel-announce. Can you point me to it please. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
On Tue, 15 Mar 2005, Ben Collins wrote: I have an e3500 to replace both auric and vore (and the raid), but I Suddenly it occures to me that we might have no stable release for some important machines in our infrastructure once etch is out. H Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, 17 Mar 2005, Karsten Merker wrote: Some, maybe. Are there lots of people running servers on m68k and arm? ^^^ Perhaps not on m68k, but at least I do on sparc and mipsel, and I doubt that I am the only one. Well, at least the Debian project itself is running some important servers on Sparc hardware. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Source of LPhoto
Hi, I found that LPhoto sounds like a nice program to have. The only link to the source I found is at http://software.lindows.com/emptypool//lindowsos/pool/main/l/lphoto which points to a direct tarball in the Linspire pool archive and this archive contains a GPL statement but contains verison 0.12 while at the latest announcement contained version 2.0. For a more recent version just look at: http://www.linspire.com/lindows_products_details.php?product_id=12418 which says in the end: ... Lphoto is an open source application - source code available. But there is no link or other sign of a downloadable source. Am I to stupid to find the source or do the people at this site have a different opinion about downloadable source than I. I wanted to issue an ITP if it is worth but wonder which link to the source I should use. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#341702: ITP: ppower4 -- generator of presentations for LaTeX
On Fri, 2 Dec 2005, [UTF-8] Rogério Brito wrote: * Package name: ppower4 Version : 0.9.4 Upstream Author : Klaus Guntermann, <[EMAIL PROTECTED]> * URL : http://www-sp.iti.informatik.tu-darmstadt.de/software/ppower4/index.html PPower4 is a post-processor for making PDF presentations with pdflatex. This is usually a good idea when one's presentations actually happen to have many formulae, since the TeX engine is at the disposal of the person making the presentation. Could you please compare ppower4 with latex-beamer? Since about one year I'm a very big fan of LaTeX Beamer. Obtaining from the example presentations on the web page Beamer is more powerful and feature complete than ppower4. The latest news entry on the ppower4 web site is more than three years old which leaves the impression that upstream is dead. Last but not least I do not really understand at which point I need some Java based tool. LaTeX beamer (and others like prosper) do only need pdflatex. So nothing against your plan to package ppower but I think we should make sure that we do not put in just another upstream dead software into Debian that is less powerful than things we just have. Kind regards Andreas. -- http://fam-tille.de
Re: Intel notebooks for needy developers in developing countries
On Sat, 10 Dec 2005, Daniel Baumann wrote: Why then being so complicated? If there is a candidate in a country doomed by US export laws, 'export' the notebook first to someone other and ship if afterwards to Cuba. Well, this was my first idea as well. Even if I absolutely not like the kind of restrictions the company Intel is pressed under in a non-free country I think we should not try to circumvent the rules under that a generous offer was given. So lets assemble a list first. Wait what happens then. If some of the top 20 persons would be removed because of the rules of a non-free country prevent this lets try to find an alternative in the free world and try to find a solution to serve people who need a box to work for Debian will finally get a box to work for Debian. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: i'm still seeing archived bugs
On Mon, 12 Dec 2005, Domenico Andreoli wrote: why i'm still seeing lots of archived bugs in my packages? hmm.. also the http://www.debian.org/Bugs/ form does not work correctly. I guess it is because bug #339141 is just open. It seems that nobody really cares since 27 days. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Help: Experts of dict format wanted (Was: wordnet_2.1-1_i386.changes ACCEPTED)
Hi,
I finally managed to upload the new WordNet version. I had to build a
new upstream source ball because upstream does not provide the real
database source in the same tarball as the binary program. Thus I
mixed the two upstream tarballs WNgrind-2.1.tar.gz (containing database
source and the grind program that processes the database) and
WordNet-2.1.tar.gz (that contains the wordnet code) to one single tarball
and rewrote the autofoo stuff to build database and code from one source.
Once I had to change the source I just added the wnfilter program
that was written by Rik Faith and used by the former dict-wn package
maintainer Bob Hilliard to obtain the dict-wn dictionary from the
wordnet database. It was originally written for WordNet version 1.6
and worked perfectly for WordNet 2.0. Unfortunately it does not
work for version 2.1 any more. This can be verified by
## dict can not find term "test"
~$ dict -d wn test
No definitions found for "test", perhaps you mean:
wn: testy jest nest pest zest teat text
## but it finds "text"
~$ dict -d wn text
1 definition found
From WordNet (r) 2.1 (July 2005) [wn]:
text
n 1: the words of something written; "there were more than a
thousand words of text"; "they handed out the printed
text of the mayor's speech"; "he wants to reconstruct
the original text" [syn: {textual matter}]
2: a passage from the Bible that is used as the subject of a
sermon; "the preacher chose a text from Psalms to
introduce his sermon"
3: a book prepared for use in schools or colleges; "his
economics textbook is in its tenth edition"; "the
professor wrote the text that he assigned students to buy"
[syn: {textbook}, {text edition}, {schoolbook}, {school
text}] [ant: {trade book}]
4: the main body of a written work (as distinct from
illustrations or footnotes etc.); "pictures made the text
easier to understand"
## But the Wordnet dictionary definitely contains "test"
~$ wordnet test -over
Overview of noun test
The noun test has 6 senses (first 5 from tagged texts)
1. (103) test, mental test, mental testing, psychometric test -- (any standardized
procedure for measuring sensitivity or memory or intelligence or aptitude or personality
etc; "the test was standardized on a large sample of students")
2. (103) test, trial, run -- (the act of testing something; "in the experimental trials the
amount of carbon was measured separately"; "he called each flip of the coin a new
trial")
3. (90) test, trial -- (the act of undergoing testing; "he survived the great test of
battle"; "candidates must compete in a trial of skill")
4. (76) trial, trial run, test, tryout -- (trying something to find out about it; "a sample
for ten days free trial"; "a trial of progesterone failed to relieve the pain")
5. (45) examination, exam, test -- (a set of questions or exercises evaluating skill or
knowledge; "when the test was stolen the professor had to make a new set of
questions")
6. test -- (a hard outer covering as of some amoebas and sea urchins)
Overview of verb test
The verb test has 7 senses (first 3 from tagged texts)
1. (37) test, prove, try, try out, examine, essay -- (put to the test, as for its quality, or give
experimental use to; "This approach has been tried with good results"; "Test this
recipe")
2. (9) screen, test -- (test or examine for the presence of disease or infection;
"screen the blood for the HIV virus")
3. (4) quiz, test -- (examine someone's knowledge of something; "The teacher tests us every
week"; "We got quizzed on French irregular verbs")
4. test -- (show a certain characteristic when tested; "He tested positive for
HIV")
5. test -- (achieve a certain score or rating on a test; "She tested high on the
LSAT and was admitted to all the good law schools")
6. test -- (determine the presence or properties of (a substance))
7. test -- (undergo a test; "She doesn't test well")
I'm absolutely uneducated about the dict format and have no idea why some
words were found but some others are not found. For the moment I decided
to upload the new WordNet packages to experimental until this issue is
solved. I hope for some help (also group maintainance is welcome) to
sort this out.
Kind regards
Andreas.
Date: Sun, 08 Jan 2006 08:32:43 -0800
From: Debian Installer <[EMAIL PROTECTED]>
To: Andreas Tille <[EMAIL PROTECTED]>
Subject: wordnet_2.1-1_i386.changes ACCEPTED
Accepted:
dict-wn_2.1-1_all.deb
to pool/main/w/wordnet/dict-wn_2.1-1_all.deb
wordnet-base_2.1-1_all.deb
to pool/main/w/wordnet/wordnet-base_2.1-1_all.deb
Re: Getting rid of circular dependencies, stage 3
On Mon, 9 Jan 2006, Bill Allombert wrote: Andreas Tille <[EMAIL PROTECTED]> wordnet wordnet-base A new version of WordNet was uploaded just yesterday to experimental. It also solves this issue but there is something wrong with the dict-wn: http://lists.debian.org/debian-devel/2006/01/msg00417.html Once this is solved the circular dependency issue will be solved in Etch. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
On Thu, 12 Jan 2006, Petter Reinholdtsen wrote: [Florian Weimer] What about: stop threatening your fellow developers? Why is specifying the consequences of doing a bad job with maintaining ones debian packages threatening? IMHO it isn't at all. Personally I believe it is time we made clear and written down explanations on what will happen to badly maintained packages, and then implement it, to make sure the quality of the packages still in Debian when this policy is implement is higher than the current level. In addition to the list of Anthony I might add: Require kind of a monthly status report of the maintainer. There must be a reason if an RC bug is open longer than a month. The maintainer should give reasons like "Need help", "Discussing with upstream", ... If the RC bug is two month old: "Sorry, got no help", "Upstream is ignorant", ... If a maintainer would not manage to respond to an RC bug for three months the package is obviousely not maintained and should be taken over by somebody else, IMHO. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
On Thu, 12 Jan 2006, Steve Langasek wrote: If RC bugs go unanswered for 3 months, I agree that something should be done; I just don't think that saying someone else should take it over is necessarily enough. I believe we need clearer methods for handling packages in the case that *no one* is handling them, nor will do so. Well "no one" is kind of a meta-"someone else" and is equal to droping the package. (I know that this is not always reasonable.) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
On Thu, 12 Jan 2006, Thijs Kinkhorst wrote: While the package might not be of the quality we strive to achieve within Debian; if a bug is not release critical we consider the bug not to be serious enough to impact the packages' releaseworthyness. This is by definition. Even if there are many of those bugs, they appearently do not prevent the core functionality from working. Well the definition is given in policy and a policy change (to be discussed) might change the definition of release critical. So if we define that numbers N_n normal bugs and N_i important bugs and time spans T_n and T_i where a bug is completely unattended by the maintainer (e.i. no comments, no reason why not fixed, etc.) we can define a measure X = Sum(N_n * T_n) + 2 * Sum(N_i * T_i) and if this measure excedes a certain limit we define this as RC critical. This is kind of formal and I have no idea whether this is reasonable, but by this measure we (well, I know, somebody != me would really have to do it) could write some automatic test that could result in an RC bug filed against the package in question that can be closed by closing (or commenting / give reasons) a number of the bugs named above which brings the measure below the threshold we defined. Just my 2 Euro cents Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
On Thu, 12 Jan 2006, Andrew Suffield wrote:
Well it's nice in theory. The problem is that you have to set the
threshold high enough to exempt glibc and dpkg, and when you do that,
I have not yet found a metric that complains about any other packages
(I've tried two or three times to invent one).
Sure, you could just manually exclude those few big offenders, but if
you're going to do that then what's the point?
I tried to mention briefly that this will not work in any case and
you just nitpicked these ones. On the other hand I can not really
believe that it is impossible to touch glibc and dpkg bugs with some
kind of status ("I'm working on it", "Help would be welcome in this
particular task", ...).
The problem is that every honor (to be a DD) is also commitment
(to care for the things that make you a DD). If you are not able
to fix things you have the responsibility to tell your users why -
at least this is my point of view in maintainership.
So for simplicity lets test the measure I suggested above for
packages with priority extra, right?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
On Fri, 13 Jan 2006, Miriam Ruiz wrote: We've been recently talking about creating a group to maintain games in Debian in a collaborative way. Are you aware of the Debian-Junior project. While quite inactive in the last time a certain effort was done in classifying games by building some interesting meta packages. You might also consider to join the Custom Debian Distribution effort which might help to make your target better visible for the users. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anthony Towns: What I did today
On Fri, 13 Jan 2006, Andreas Schuldei wrote: * Martin Zobel-Helas <[EMAIL PROTECTED]> [2006-01-13 20:34:20]: ...and no one can complain afterwards. you underestimate your fellow nagg^Wdevelopers. Well, there are always people who complain. But posting development related mails to debian-devel is the intended purpose of this list and there is less reason to complain then it is if people do not at least mark their postings [OT] when they are chatting about other distributions on debian-devel. So, if you ask me it would be better if messages like the one Anthony blogged would be here in the first place and the blog would say: "I just posted this or that to debian-devel ..." :) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
For those who care about Andrew Suffield
On Sat, 14 Jan 2006, Andrew Suffield wrote: Since this sort of thing is apparently okay nowadays, and I know that ... is it not OK as you definitely know and my intention is not to feed you troll but that I hope the "Debian lesbian" ration will just be kept low because I changed the subject and people will not start just another flame war which makes just another duelling banjos case. Thanks Andrew for your continuos very helpful contribution Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, 18 Jan 2006, Otavio Salvador wrote: But linked against other libraries. The binary is downloaded from another location(or installed from a different cd set). The program used to do the download may be different. Using this as rule, then all Debian CDD distributions would need to recompile all sources to change the maintainer field. I'm sorry if we agree that a CDD is what we defined under http://people.debian.org/~tille/cdd/ch-about.en.html#s-CDD then no change is necessary. "To clarify a common misunderstanding: Custom Debian Distributions are not forks from Debian. They are completely included, and if you obtain the complete Debian GNU/Linux distribution, you have all available Custom Debian Distributions included." (I know that the name CDD is very confusing and many people think that it is something else.) In case of CDDs, the only exception is it isn't build against other libraries but it is installed by different cd set and downloaded from another location in many cases. If it is a CDD than it is installed from a Debian mirror and nothing else. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, 18 Jan 2006, Otavio Salvador wrote: Debian-EDU is available in Debian but also outside of it since they Well, that's a "temporary" hack until we have implemented solutions which makes this superfluous. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, 18 Jan 2006, Otavio Salvador wrote: Well, that's a "temporary" hack until we have implemented solutions which makes this superfluous. But exist! Sure they exist, but the statement you made about the maintainer field was simply wrong, because it makes no sense to change the maintainer field of Debian internal packages. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#349534: ITP: pyntor -- flexible and componized presentation program
On Mon, 23 Jan 2006, Florian Ragwitz wrote: Due to the minimal size and maximum configurability, Pyntor is a nice alternative to conventional presentation programs. What do you mean by "conventional" presentation programs. IMHO we could differentiate into three groups of presentation programs: 1. Text based with on syntax and own viewer - MagicPoint - probably others 2. LaTeX based (mostly using PDF export or special DVI viewers) - LaTeX - PDF - latex-beamer - prosper - many more - LaTeX - DVI - advi - Perhaps also pspresent falls into this large group 3. GUI-based - ooimpress - kpresenter - (what was the name of the thingy many people call a standard? ;-) ) I guess pyntor falls in group 1 and a comparison with members of this group might be nice. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Box does not switch of on halt
Hi, since about three weeks I observe problems when issuing halt on three different testing-boxes (two older desktops without ACPI and one laptop with ACPI). The computer just does not switch off. If I try to reboot it is also impossible, because the shutdown process stops at the same point where halt stops. The last messages on the console are: Shutdown: hda System halted. At one single time I managed to observe at the console Saving random seed ... done Usage: grep [OPTION] ... PATTERN [FILE] ... Try `grep --help` for more information Shutdown: hda System halted. Unmounting remote and non-toplevel virtual filesystems ... done The log of one of this machine does not uncover something interesting: Mar 6 22:43:35 energija kernel: nfsd: last server has exited Mar 6 22:43:35 energija kernel: nfsd: unexporting all filesystems Mar 6 22:43:35 energija kernel: RPC: failed to contact portmap (errno -5). Mar 6 22:43:35 energija mountd[1175]: Caught signal 15, un-registering and exiting. Mar 6 22:43:35 energija kernel: Kernel logging (proc) stopped. Mar 6 22:43:35 energija kernel: Kernel log daemon terminating. Mar 6 22:43:35 energija exiting on signal 15 At Linux-Tage Chemnitz I discussed this problem with other developers: 1. One of them has observed the same (no solution) 2. One visitor had the same problem. Installing Debians own linux kernel image package helped 3. One hint was to load APM module Remarks: I tried different kernels (I had originally installed self-made 2.6.9 / 2.6.11, upgraded to self-made 2.6.15 and even tried official 2.6.15 kernel image - see item 2.) but the situation did not changed. I suspected a change in the apmd package and tried to downgrade the apmd package on the apmd machines which also did not helped. So the question is: what package might be responsible that entered testing for about three weeks and how can I get my boxes working as expected again. I would love to write a reasonable bug report but I have no idea against which package so I could only issue this against general which is a little bit naive. Any help is very welcome Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
On Wed, 8 Mar 2006, Christian Fromme wrote: A friend of mine had the same problem once and IIRC he solved it by simply loading the apm module through /etc/modules. Well, the laptop is ACPI and if I'm not completely wrong ACPI replaces APM and I've read that I should not use APM and ACPI in parallel. Moreover the probelm occured after an upgrade of some random packages from testing without touching the kernel at all. In these old APM days (several years and several kernels ago) the hint was right, but I'll try with my older APM boxes at home to make sure I did not miss anything. Thanks for the hint Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
On Wed, 8 Mar 2006, Henning Makholm wrote: Sysvinit migrated to testing on February 21, and was responsible for a similar error (#252547) for me a couple of years ago. However, the current sysvinit has no trouble shutting down my sid box. ~$ apt-cache policy sysvinit sysvinit: Installed: 2.86.ds1-12 Candidate: 2.86.ds1-12 Version table: *** 2.86.ds1-12 0 501 http://ftp.de.debian.org testing/main Packages 50 http://ftp.de.debian.org unstable/main Packages 100 /var/lib/dpkg/status While this package might be responsible in fact because I have an older sysvinit (2.86.ds1-4) on a further testing machine that I do not upgrade that requently, this version has the problem I described. So I keep the maintainer of the package in CC in case he is not reading this thread. (Henrique, feel free to contact me for further details or a fully qualified bug report in case your feel responsible for this problem.) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
On Wed, 8 Mar 2006, Henrique de Moraes Holschuh wrote: Forwarding to the mailing list for the SysvInit maintainers (contacting me directly isn't nearly as effective, I am not even the most active of the sysvinit maintainers... ;-) ). Thanks fo the foreward but I'm afraid we might be on the wrong track. I downgraded sysvinit on one of the machines (by chance the apm based) to apt-cache policy sysvinit sysvinit: Installed: 2.86.ds1-4 Candidate: 2.86.ds1-12 Version table: 2.86.ds1-12 0 499 http://ftp.de.debian.org testing/main Packages 50 http://ftp.de.debian.org unstable/main Packages *** 2.86.ds1-4 0 100 /var/lib/dpkg/status The behaviour is the same as for 2.86.ds1-12. :-( Any other hints? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
On Thu, 9 Mar 2006, Gustavo Franco wrote: What's wrong with us ? It is wrong that somebody who would like to work is stopped to do his work by others. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
On Thu, 9 Mar 2006, Amaya wrote: Hey! It's DPL election time! Lobby around. I really am biting my tongue, but you don't have to. Ups, why are you biting your tongue? I say it loudly: I will vote highest for the candidate who seems to me most probable to solve this very problem. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
On Wed, 8 Mar 2006, Andreas Tille wrote: Thanks fo the foreward but I'm afraid we might be on the wrong track. I downgraded sysvinit on one of the machines (by chance the apm based) to apt-cache policy sysvinit sysvinit: Installed: 2.86.ds1-4 Candidate: 2.86.ds1-12 Version table: 2.86.ds1-12 0 499 http://ftp.de.debian.org testing/main Packages 50 http://ftp.de.debian.org unstable/main Packages *** 2.86.ds1-4 0 100 /var/lib/dpkg/status The behaviour is the same as for 2.86.ds1-12. :-( Are there any more hints what might stop the computer from doing cleeen halt / reboot than apm/acpi or sysvinit. I just tried linux-image-2.6.15-1-686 version 2.6.15-7 this morning - no change. I' can't imagine that every of my boxes with the current testing shows the same behaviour but nobody els has this problem and there is no way to fix this. If I would have at least a hint what package might be guilty for the problem. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
On Fri, 10 Mar 2006, Henrique de Moraes Holschuh wrote: Yes, check for changes in /sbin/halt. As I said the problem also occures with the old /sbin/halt. Why should I check for changes between two non working versions? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
On Mon, 13 Mar 2006, Andreas Barth wrote: Well, that person is currently on the CeBIT and manning the Debian booth there. The problem in the sentence above is the singular in "that". I know that Jörg Jaspers does a great job as ftp master assistant but didn't we talked about the "hit by a bus factor" ... oh, no we discussed it often enough. I'll save my time for today. Kind regards Andreas. -- http://fam-tille.de
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
On Mon, 13 Mar 2006, Martin Michlmayr wrote: and of course such a useless information has been kept silent. Maybe because it's simply not true? Sow what? If this is not true, what is true and why is it kept silent (well, IRC logs are not really but effectively silent). I know, Martin, it is not really you who has to answer this question. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
On Fri, 17 Mar 2006, Dominique Dumont wrote: I humbly admit that I did not provide much information, I just hope to give you some more hint about this problem... Thanks for the hint even if I think we have a deeper problem here. I just hoped somebody would be able to give a hint about the package that would be a reasonable target for a bug report. I guess I'll give up and file the report against general. I'm really depressed about the general silince. My only reasonable idea about it is, that most DDs just do not switch of their boxes and just do not notice the problem. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Questions for maintaining several packages
Hello
I want to start maintaining the following packages:
1) xteddy
Xteddy is a cuddly teddy bear for your X Windows desktop.
It is more or less an excersise for package bundling and
maintaining.
In fact xteddy is a must have for any Linux distribution :-))
2) wordnet
* Wordnet 1.5 disapeared from hamm.
Because the old maintainer (see below) didn't give me any
answer about the reason I decided to tako over this package.
* I started from scratch with version 1.6.
* added automake stuff to the original source
* Patched wnconsts.h to define DEFAULTPATH and DEFAULTBIN via
compile option rather than #define in this file
* I decided to put it in text like spell programs an dictionaries
(*** may be there should be a new dictionary section in Debian ***)
* I can't verify if dict/index.sense isn't used by the programs
and so I included it in my package (see remark of Ioannis Tambouras
in his first release)
I have certain problems with wordnet:
- I can't manage the multipackage building process.
Is there any hint on splitting packages over three different
*.deb files?
- There is a problem with automake.
my configure.in contains the lines
...
AC_DEFINE_UNQUOTED(DEFAULTPATH, "${prefix}/lib/wordnet")
AC_DEFINE_UNQUOTED(DEFAULTBIN, "${prefix}/bin")
...
This should produce in the resulting Makefile
-D${prefix}/lib/wordnet -D${prefix}/bin
but if configure is invoked without any arguments
-DNONE/lib/wordnet -DNONE/bin
and if a prefix was given (configure --prefix=/usr)
-D/usr/lib/wordnet -D/usr/bin .
So I inserted a quick hack into configure which enforces
--prefix argument. How to do this sane? Unfortunately the
use of AC_DEFINE didn't help because than '$', '{' and '}'
are quoted.
- A last but not so importand problem is, what to do if a file
should be stored as a symbolic link in the source distribution
when doing "make dist". The reason is that the Name of the
file for copying conditions was LICENSE and automake requires to
have a file named COPYING. I consider it to be annoying to have
two files of the same contents and made a symbolic link, but this
resulted in two files after "make dist".
3) A free English dictionary (www.dict.org).
I found a hint on
http://www.debian.org/doc/prospective-packages.html
that such a dictionary exists and is desired to be included
into Debian. Is there any effort on this? I would think
about maintaining this package.
4) Some time ago I found a English-German dictionary at
ftp://ftp.th-darmstadt.de/pub/dicts/german/german-english.tar.Z
assembled by
Tobias Oetiker <[EMAIL PROTECTED]> and
Joachim Schrod <[EMAIL PROTECTED]>
In my oppinion this could give a good starting point for creating
a bilingual interface but needs some further investigation.
Is there an interest to put such stuff into Debian distribution?
I have some ideas what could be done but no time to implement this.
5) I would like to support the CIRC package, which serves TeX-macros
for drawing elektrical circuits. (CTAN: macros/generic/diagrams/circ)
In general I think it would be a good idea to make the control files
of a debian package available in the source tree to give new maintainers
a huge set of examples.
Regards
Andreas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions for maintaining several packages
On Tue, 7 Apr 1998, Alex Romosan wrote: > you can get an xteddy debian package by anonymous ftp from > caliban.lbl.gov in /pub/debian. i am happy to see this finally become > part of the distribution. OK, I've finished building an xteddy Debian Package and I'll take over maintainance when finished the procedure to become an official Debian maintainer. Did you plan to maintain XTeddy too or was your package only for private uses. I'm not intended to catch your job ;-). Regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
