Re: visual c
On Sat, 29 Dec 2001, Erik Steffl wrote: [...] > there is also a number of other libraries (for GUI), I don't think you > have to use ms libs, you can use e.g. wxwindows, qt etc..., also, if the > application doesn't have complicated gui the porting might be fairly > easy... (it also depends on how well the app is designed, if the gui is > farily independent of back-end it's much easier to port it). Without knowing anything about his application it's hard to say, but it is easy to end up using MS specific things when coding on Windows. And it's not just about the GUI: it's also about ReadFileEx, CreateMutex, CreateProcess, registry APIs, ACL management, asynchronous file operations, COM/DCOM, ... -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ In a world without fences who needs Gates?
Re: Preparing a Proposal: 3 DD needed for every NEW package
On Mon, Dec 31, 2001 at 05:09:06PM +0900, Junichi Uekawa wrote: > Unmaintained, unused, and untested packages are in Debian. > If no one uses these packages, bugs won't be filed. If no one uses the package, the bugs are not a problem! :-) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: quake I for woody
On Mon, Dec 31, 2001 at 11:51:44AM -0500, Jeff Teunissen wrote: > > The stuff outside I have done. Back in March or so I designed a nice, > > complex, and complete system for handling gamedata. It would work as > > long as an engine using it had fs_* Cvars and config files. Unless of > > course you did something unexpected in your config file, in which case > > it puked. Too fancy, and it broke. > > Solution without a problem. Game data must keep its name, and both registered > and unregistered Quake game data always has to be in id1. Since the shareware data does not traditionally work in QW at all and NQ does not keep track of the game directory, I've continued putting it into idsw. I suppose this discussion could move to debian-devel-games at this point though, which I might actually still be subscribed to. Seems that the only traffic that list gets anymore is spam. I'm not actually on debian-devel anymore. > > I can actually do the necessary work to get the shareware thing done > > next weekend (I'm going on holiday for a few days and won't have much > > time for code..) As for the registered game installer, I've got > > something written in perl for that already, but it's not much and it > > comes with a big warning that perl is not a language I actually grok. > > I have had a quake-shareware package ready for upload since I needed one to > finish the QF packages, about 3 months ago as I remember it. It's at my apt > repo, alongside the (~1 month old) QF packages that depend on it. I'll look at these. Thanks to the flu - er, I mean ANTHRAX(!) - the only holiday I'm taking is a trip to the store for Theraflu and chicken soup, so I'll probably look tonight. -- Joseph Carter <[EMAIL PROTECTED]>No conceit in my family * wichert_ imagines master without a MTA wichert: ehm? that might hinder peformance of the BTS :p pgp80enk38v0B.pgp Description: PGP signature
Re: Debian installer
At 2:08 pm, Tuesday, January 1 2002, Tollef Fog Heen mumbled: > | It then un'tar's the base tarball into /target, makes Linux bootable if you > | said it could, and then reboots. > > There is no base tarball for woody; it then runs debootstraps which > unpacks the .debs. > Okay, I should add that it was also potato-centric. ;-) -- Steve If you can read this, I've lost my .signature. pgpLPfzPDKiTe.pgp Description: PGP signature
Some Crazy and Happier Ideas for 2002
Hi, I hereby restart my long-forgotten, yet ancient, tradition of posting ridiculous mails to this newsgroup. Why ? I believe in the allmighty power of self-organisation :P And have to work till 11pm 31/12/01 until 07am today 01/01/2002. I'm not looking to cause flame-wars, rants or what so ever. I apologise for sharing such grief in such an inappropriate way :P This is my only way out of seemingly eternal boredom. A Marvelous New Year to all of you people and all your friends friends who care about Free !!! // Dear Santa, Don't take me to serious on this // [ The madness starts here ] [] Distributed Webserver Project Provides a way to distribute webpages across available cable/adsl/other hosts and estimates the fastest server to serve you a particular page depending on the load of one of the distributed server(s) [.] // let's call this crazy // [] Distributed Render Internet Rendering Daemon I've posted this on NAN (www.blender.nl) as well. This 'thing' should provide a way of distributing those cpu-cycle hungry render scenes across a select (or grid-like) number of hosts resulting in massive rendering power for non-professionals [.] // some work is allready done but i have great PLANS, as does every raving madman // [] Porting of Debian/GNU to the QNX Microkernel System Pretty much sums it up [] // Why not, Debian is cool, QNX is cool // [] Porting of the QNX proprietary Gui to GNU/Linux-BSD ... This GUI is beautifull, practical, fast, low fat. Swt. Someone please do so ... please. http://get.qnx.com/ Don't you agree X is just too sluggish on slower systems [?] // To good to be true i guess ;( [] Take a look at www.transgaming.com Someone tell me this is not the one thing you need to start moving to Linux Completely !!! If it weren't only to ease those eventual transitional ordeals [:)] // // [] An Open Source Software Fund is raised This is like a deposit where you can invest into shares for Open Source projects. The developper/team posts release wich must be approved for by the depositors in order to receive their future funding. Quality Approved sort of to speak. [] // That's a happy idea ain't it ? // [] A spanking new hardware platform without any compromise to aged standards is released and produced. Linux is the OS of choice together with BSD and other Open OS's. Plain boxes with just a couple connectors, stylish, vector, plain [] // Oh well, sick of that x86 like alley, gimme something cool // [ Madness might end just about here ] Thanks for sticking around. Feel free to express frustration, ethousiasm at my adress at all times. Do stay somewhat polite however, frustration can be quite boring Regards, J.L.
Re: Preparing a Proposal: 3 DD needed for every NEW package
Hi, Le Sun, Dec 30, 2001 at 06:50:16PM +0100, Bas Zoetekouw écrivait: > It's quite easy to say that you can find dozens of such packages. Please > be specific, and post the name of those packages/maintainers (take it to > -private, if you want) but I honestly don't believe that there are many > badly maintained recent packages. I didn't say "recent". The time between the ITP and when they are suffering from lack of maintenance can be more than a year ... > > backup maintainers, they could have noticed that the package is no more well > > maintained and they could take it over or help the main maintainer > > if he didn't totally disappear. > > They can do that now, too. They can do, as you can continually scan the BTS ... but the fact is that scanning the BTS is not meant to be done daily just to be sure that a package is maintainer. Beeing a backup maintainer, you'd get the BTS mails directly and you can follow the package in real time and detect problems without loosing much time by scanning regularly the BTS. > And if they don't notice that the package is > badly mainatined, then what is the problem? There are many packages that > haven't been updated in ages, but work perfectly. And what do you want to prove with that ? Of course, it's fine if a package works well, but having an active maintainer is always useful just to package new versions, just to be sure there's someone when something happens. > OK, but giving all packages multiple maintainers I find a bit far > fetched a solution. It's not a requirement, it's something we should encourage because it's a good thing for us. You may find the solution far fetched but it's the only viable solution in the long term ... any other methods that concentrate on detecting problems after they come up is bad, we should try to avoid the problems in the first place... Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: Preparing a Proposal: 3 DD needed for every NEW package
Le Sun, Dec 30, 2001 at 08:51:20PM -0600, Colin Watson écrivait: > On Sun, Dec 30, 2001 at 06:43:57PM +0100, Bas Zoetekouw wrote: > > I don't agree. In a perfect world, yes, we would have all available > > software packaged for debian and all packages maintained. But that's > > just not reality. It's not even necessary. There is no need for > > ``backup maintainers'': if a package is orphaned[1], then either > > somebody else adopts the package (in which case there is no problem), or > > the package should be dropped [2] (because apparently, it is > > ``unneeded''). > > This happens eventually, but it introduces a delay of weeks or months in > which the package sits untended because no-one is sure what's going on. > We can do without this delay, and having someone who feels "allowed" to > fix up the package as necessary with minimal delay would be very useful. Exactly, it's funny how people can miss that. A package is not always officially orphaned, having a backup maintainer that keeps an eye on the package from time to time is definitely useful to detect the disparition of the main maintainer and to take over the package as soon as possible once he detected that the main maintainer can't continue itw work (or doesn't want or whatever). And it can be very useful in many other cases (vacation, busy period for the maintainer, ...). Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > It can't be larger than 255 (precisely because it is limited to a single > byte). > > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. This works only as long as you own all of your code. The problem is you can assign signed char to unsigned char or vice versa without any ill effects; you won't even get a compiler warning. However, the same can't be said for signed char * vs unsigned char *. If you are interfacing to external code (even functions like strcpy etc), you are asking for a major type casting headache. Worse, the problem won't even show up if you are developing on the "right" platform. I've gone down that route once and then gave up :-(. Another thing that puzzles me since this whole debate started. If you look at the declaration of ctype.h functions (isalpha family), they take a int as an argument. The man page explicitly mentions the argument should be an unsigned char - obvious because a signed char would sign extend to an int. For platforms that default to signed char, and it appears majority of them do, you need to cast a "default" char type before calling ctype functions. Still, I have not seen any code that does it. Ganesan
EVMS: shared libraries with unversioned sonames
On Sat, Dec 29, 2001 at 01:33:26PM -0600, Kevin Corry wrote:
> On Friday 28 December 2001 23:48, Matt Zimmerman wrote:
> > I have already grabbed the latest release and started work on evms
> > packages for Debian, though I haven't touched them for over a week since
> > I have been away. I should have experimental packages ready within the
> > next week or so.
>
> Great!
I have a set of packages which work for me, but a few things will need to be
resolved before they can go into Debian proper.
- Shared library versioning
libevms and libdlist have sonames with no version number (libevms.so and
libdlist.so). I assume that this is because the APIs aren't yet stable
and you aren't worrying about binary compatibility yet, but this setup
will cause problems for upgrades, and as such does not meet Debian
requirements. There are at least couple other ways to approach the
situation:
- Use a soname like libevms-0.2.4.so, where there is implicitly no binary
compatibility between versons, and multiple versions of the library can
be installed at once. This is my preferred method.
- Only provide static libraries until normal soname versioning makes sense
What are your feelings on this?
- Manual pages
Debian requires that every program have a manual page. This is not a big
deal; I will write the man pages if you don't have any.
- Makefile stuff
I modified the makefiles to support DESTDIR, and to remove the autoconf
clutter in 'clean' instead of 'distclean'. I can't run 'distclean' from
the package build scripts because it removes 'configure'; I'm not sure why
this is, since configure is part of the distribution. My diff is
attached.
> > I have not as yet built a kernel with the EVMS patch. I hope it is
> > possible to include both LVM and EVMS for migration purposes; is this
> > true?
>
> Yep. I run kernels with both EVMS and LVM enabled. Just make sure you
> don't mount the same LV with both systems at the same time. Also, if you
> make any volume modifications with one system (add/delete LVs, add/delete
> PVs from a VG, etc), you may need to reboot in order for the other to pick
> up the changes.
I have a device which used to be LVM PV, but is no longer in any VG, and I
want to give the device to EVMS to use as a new segment to play with. It
was still claimed by the LVM region manager, though (in
LVM_Unassigned_Group). The only way I could release it was to zero out the
first sector and run evms_vgscan. Was there a better way?
--
- mdz
--- evms-0.2.4.orig/engine/Engine/Makefile
+++ evms-0.2.4/engine/Engine/Makefile
@@ -19,10 +19,10 @@
all: .depend $(TARGET)
install: all
- ../mkinstalldirs.sh $(EVMSLIB_DIR)
- $(INSTALL) $(TARGET) $(EVMSLIB_DIR)
- rm -f $(EVMSLIB_DIR)/$(SONAME)
- ln -s $(EVMSLIB_DIR)/$(TARGET) $(EVMSLIB_DIR)/$(SONAME)
+ ../mkinstalldirs.sh $(DESTDIR)$(EVMSLIB_DIR)
+ $(INSTALL) $(TARGET) $(DESTDIR)$(EVMSLIB_DIR)
+ rm -f $(DESTDIR)$(EVMSLIB_DIR)/$(SONAME)
+ ln -s $(TARGET) $(DESTDIR)$(EVMSLIB_DIR)/$(SONAME)
uninstall:
rm -f $(EVMSLIB_DIR)/$(TARGET)
--- evms-0.2.4.orig/engine/Makefile
+++ evms-0.2.4/engine/Makefile
@@ -12,15 +12,15 @@
done && test -z "$$fail"
install:
- rm -f $(PLUGINS_DIR)/lib*
- rm -f $(EVMSHEADERS_DIR)/*.h
+ rm -f $(DESTDIR)$(PLUGINS_DIR)/lib*
+ rm -f $(DESTDIR)$(EVMSHEADERS_DIR)/*.h
@for dir in ${subdirs}; do \
(cd $$dir && $(MAKE) install) \
|| case "$(MFLAGS)" in *k*) fail=yes;; *) exit 1;; esac; \
done && test -z "$$fail"
- ./mkinstalldirs.sh $(EVMSHEADERS_DIR)
- $(INSTALL) include/*.h $(EVMSHEADERS_DIR)
+ ./mkinstalldirs.sh $(DESTDIR)$(EVMSHEADERS_DIR)
+ $(INSTALL) -m 644 include/*.h $(DESTDIR)$(EVMSHEADERS_DIR)
uninstall:
@for dir in ${subdirs}; do \
@@ -29,7 +29,7 @@
done && test -z "$$fail"
clean:
- /bin/rm -f *~
+ /bin/rm -f *~ config.cache config.log config.status
@for dir in ${subdirs}; do \
(cd $$dir && $(MAKE) clean) \
|| case "$(MFLAGS)" in *k*) fail=yes;; *) exit 1;; esac; \
--- evms-0.2.4.orig/engine/Plugins/aixregmgr/Makefile
+++ evms-0.2.4/engine/Plugins/aixregmgr/Makefile
@@ -20,8 +20,8 @@
all: .depend $(TARGET)
install: all
- ../../mkinstalldirs.sh $(PLUGINS_DIR)
- $(INSTALL) $(TARGET) $(PLUGINS_DIR)
+ ../../mkinstalldirs.sh $(DESTDIR)$(PLUGINS_DIR)
+ $(INSTALL) $(TARGET) $(DESTDIR)$(PLUGINS_DIR)
uninstall:
rm -f $(PLUGINS_DIR)/$(TARGET)
--- evms-0.2.4.orig/engine/Plugins/bbr/Makefile
+++ evms-0.2.4/engine/Plugins/bbr/Makefile
@@ -20,8 +20,8 @@
all: .depend $(TARGET)
install: all
- ../../mkinstalldirs.sh $(PLUGINS_DIR)
- $(INSTALL) $(TARGET) $(PLUGINS_DIR)
+ ../../mkinstalldirs.sh $(DESTDIR)$(PLUGINS_DIR)
+ $(INSTALL) $(TARGET) $(DESTDIR)$(PLUGINS_DIR)
uninstall:
rm -f $(PLUGINS_DIR)/$(TARGET)
--- evms-0.2
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 31-Dec-01, 16:30 (CST), Peter Finderup Lund <[EMAIL PROTECTED]> wrote: > On 31 Dec 2001, Colin Walters wrote: > > No, the C standard guarantees that a char is exactly a single byte; i.e. > > sizeof(char) == 1. > > I think he meant "wider than one would think"-character. A char didn't > originally have to be 8 bits wide -- the first edition of K & R "The C > Programming Language" explicitly mentions an implementation with 9-bit > chars. > > I think the newer standards say you have to use 8-bit chars but with some > sort of "cat flap" clause that allows exceptions if the platform is a > weird DSP or something like that. Nope, the standard says that 1. sizeof(char) == 1 2. the range of signed char is *at least* -127 -> +127 3. the range of unsigned char is *at least* 0 -> 255 4. "plain" char shall act like one of (2) or (3) The net effect is that chars are *at least* 8 bits wide, but may be wider. The macro "CHAR_BIT" in limits.h will tell if if you really need to know. There is no requirement that char be exactly 8 bits; no cat flap required. Steve
Re: /var/lib/dpkg/status file woes
On Mon, 31 Dec 2001, Hereward Cooper wrote: > I'm in a strange situation, something (the last program I installed was fligh > gear) caused my /var/lib/dpkg/status file to be deleted. Meaning > apt/dpkg/dselect is unable to determin what packages are installed. I managed > to > manually write in the details of debconf and dpkg so that packages would > actaully install, but now the problem is that the system can't tell that I > have > an up to date version of a package already present i.e. when I apt-get install > an X based app it thinks it also needs xf86, so downloads it, but when > installing it finds my already existing conf files, so promts me if I want to > overwrite. > > Is there a easy solution to this -- or will I have to go round > downloading/installing packages I already have installed just to update the > /var/lib/dpkg/status file? Look in /var/backups. Also, look at /var/lib/dpkg/status.old, and status.yesterday, etc.
/var/lib/dpkg/status file woes
I'm in a strange situation, something (the last program I installed was fligh gear) caused my /var/lib/dpkg/status file to be deleted. Meaning apt/dpkg/dselect is unable to determin what packages are installed. I managed to manually write in the details of debconf and dpkg so that packages would actaully install, but now the problem is that the system can't tell that I have an up to date version of a package already present i.e. when I apt-get install an X based app it thinks it also needs xf86, so downloads it, but when installing it finds my already existing conf files, so promts me if I want to overwrite. Is there a easy solution to this -- or will I have to go round downloading/installing packages I already have installed just to update the /var/lib/dpkg/status file? I'm running sid. -- Thanks, -- -0) Hereward Cooper Somerset, UK /\\ [EMAIL PROTECTED] GPG: 1E1D0C80 zadok.ddts.net _\_v -- pgp1cSWT8Cz9v.pgp Description: PGP signature
Re: [Evms-devel] Re: RFP: EVMS
On Sat, Dec 29, 2001 at 01:33:26PM -0600, Kevin Corry wrote: > On Friday 28 December 2001 23:48, Matt Zimmerman wrote: > > I have been using LVM for some time, and I am eager to start working > > with EVMS. Once I have working packages, I will be migrating some of my > > LVM volumes to EVMS using them, which should be a good initial test. > > Let me know how your tests go. > > > I have not as yet built a kernel with the EVMS patch. I hope it is > > possible to include both LVM and EVMS for migration purposes; is this > > true? > > Yep. I run kernels with both EVMS and LVM enabled. Just make sure you > don't mount the same LV with both systems at the same time. Also, if you > make any volume modifications with one system (add/delete LVs, add/delete > PVs from a VG, etc), you may need to reboot in order for the other to pick > up the changes. OK, I now have a functional 2.4.17 with LVM and EVMS. My setup has a few quirks so far: - I build most things as loadable modules, including one of my SCSI drivers, LVM, and the bits of EVMS that support it (I have the MD module disabled for now). Consequently, EVMS doesn't find any devices when it starts up. I tried evms_vgscan, and got badness: Dec 30 20:22:58 mizar Unable to handle kernel paging request at virtual address d89142c0 Dec 30 20:22:58 mizar printing eip: Dec 30 20:22:58 mizar c01650e8 Dec 30 20:22:58 mizar *pde = 01636067 Dec 30 20:22:58 mizar *pte = Dec 30 20:22:58 mizar Oops: Dec 30 20:22:58 mizar CPU:0 Dec 30 20:22:58 mizar EIP:0010:[]Tainted: P Dec 30 20:22:58 mizar EFLAGS: 00010286 Dec 30 20:22:58 mizar eax: 0004 ebx: d2427900 ecx: edx: d89142c0 Dec 30 20:22:58 mizar esi: c682ff38 edi: c682ff68 ebp: esp: c682ff1c Dec 30 20:22:58 mizar ds: 0018 es: 0018 ss: 0018 Dec 30 20:22:58 mizar Process evms_vgscan (pid: 7153, stackpage=c682f000) Dec 30 20:22:58 mizar Stack: c682ff38 b92c c01667f8 c682ff38 c682ff5c b92c c682ff68 Dec 30 20:22:58 mizar c016380e c682ff5c c00c3f82 b920 b920 Dec 30 20:22:58 mizar 40015a38 c0164d06 b920 d1254ac0 b920 c00c3f82 Dec 30 20:22:58 mizar Call Trace: [] [] [] [] [] Dec 30 20:22:58 mizar [] I got things to work by using the little evms_rediscover program from the uml tarball on sourceforge, after which evms_vgscan seems happy. - It only seems to find one of my LVM volume groups (see attached evms-rediscover.text and vg_concat.text). - Within that group, apparently because it doesn't recognize one of my PEs (#4, scsi/host1/bus0/target5/lun0/part1), causing lots of messages about incomplete LE maps, though LVM is happy with everything. I think it's being referred to as sdf, but I've been using devfs names on this system through several hardware reconfigurations, so I'm not sure where it falls in the order now. - After running evms_rediscover, when I run evms_vgscan, it sees both of them: mizar# evms_vgscan evms_vgscan -- reading all physical volumes (this may take a while...) evms_vgscan -- Found active volume group "lvm/vg_concat" evms_vgscan -- Found active volume group "lvm/vg_raid1" but there is still only one under /dev/evms/lvm (I'm using DevFS): mizar:[~] ls -R /dev/evms /dev/evms: block_device lvm sda1 sda2 sda3 sdd2 /dev/evms/lvm: vg_concat /dev/evms/lvm/vg_concat: backup debian-cvs hercules music netcache tmp mizar:[~] Both volume groups are visible from the GUI, though, oddly enough. -- - mdz Dec 31 16:27:56 mizar --ldev_mgr: unrecognized device major : 58 Dec 31 16:27:56 mizar --ldev_mgr: unrecognized device major : 9 Dec 31 16:27:56 mizar --ldev_mgr: found SCSI major : 66 - searching for disks Dec 31 16:27:56 mizar --ldev_mgr: scsi: major name = sd Dec 31 16:27:56 mizar --ldev_mgr: scsi: number of real devices = 0 Dec 31 16:27:56 mizar --ldev_mgr: found SCSI major : 65 - searching for disks Dec 31 16:27:56 mizar --ldev_mgr: scsi: major name = sd Dec 31 16:27:56 mizar --ldev_mgr: scsi: number of real devices = 0 Dec 31 16:27:56 mizar --ldev_mgr: found SCSI major : 8 - searching for disks Dec 31 16:27:56 mizar --ldev_mgr: scsi: major name = sd Dec 31 16:27:56 mizar --ldev_mgr: scsi: number of real devices = 6 Dec 31 16:27:56 mizar --ldev_mgr: scsi: Channel = 0, Id = 0, Lun = 0, Capacity = 8910423 Dec 31 16:27:56 mizar --ldev_mgr: added logical disk(sda) for physical disk(8,0,sda), blocksize(1024) Dec 31 16:27:56 mizar --ldev_mgr: scsi: Channel = 0, Id = 0, Lun = 0, Capacity = 17689267 Dec 31 16:27:56 mizar --ldev_mgr: added logical disk(sdb) for physical disk(8,16,sdb), blocksize(1024) Dec 31 16:27:56 mizar --ldev_mgr: scsi: Channel = 0, Id = 1, Lun = 0, Capacity = 17689267 Dec 31 16:27:56 mizar --ldev_mgr: added logical disk(sdc) for physical disk(8,32,sdc), blocksize(1024) Dec 31 16:27:56 mizar --ldev_mgr: scsi: Channel = 0, Id = 3, Lun = 0, Capacity = 8385121 Dec 31 16:27:56 mizar --ldev_m
Question about cdrecord and -audio
Hi all, I'm hopping that someone has some experience with audio CD recording and can help me a bit. I can record data CDs without any problems but if I try the audio option I get the following output mira:/tmp# cdrecord -dev=0,0 -dummy -audio -pad t.iso Cdrecord 1.10 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling scsidev: '0,0' scsibus: 0 target: 0 lun: 0 Linux sg driver version: 3.1.22 Using libscg version 'schily-0.5' Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'LG ' Identifikation : 'CD-RW CED-8120B ' Revision : '1.02' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Starting to write CD/DVD at speed 4 in dummy mode for single session. Last chance to quit, starting dummy write in 0 seconds. Operation starts. cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 00 00 00 00 00 1B 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 64 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x64 Qual 0x00 (illegal mode for this track) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.002s timeout 40s write track data: error after 0 bytes Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 I am not familiar enough with the CDR protocols to know what these things mean... Is this the problem with cdrecord or my drive? Thanks for any help in advance, Adam Majer pgpbU7PIFqIVI.pgp Description: PGP signature
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 31 Dec 2001, Colin Walters wrote: > > and there's a small possibility that char could be some weird wide > > character thing, > > No, the C standard guarantees that a char is exactly a single byte; i.e. > sizeof(char) == 1. I think he meant "wider than one would think"-character. A char didn't originally have to be 8 bits wide -- the first edition of K & R "The C Programming Language" explicitly mentions an implementation with 9-bit chars. I think the newer standards say you have to use 8-bit chars but with some sort of "cat flap" clause that allows exceptions if the platform is a weird DSP or something like that. > It can't be larger than 255 (precisely because it is limited to a single > byte). Careful - a byte is not always the same as an octet. > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. Not when you are using them for characters -- only if you are using them as small integers. Just be very careful when you perform arithmetics and relations on chars. It is often a better idea to use a macro or function from the standard library. -Peter Anxiety, n.: The first time you can't do it a second time. Panic, n.: The second time you can't do it the first time.
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > On Mon, 2001-12-31 at 05:40, Julian Gilbey wrote: > > I believe that the author (Knuth) presumably thought "c should only be > > between 0 and 127, probably not even that far, and we're using c as an > > array index, where we've only allocated 256 chars for this array. > > Right. Then it should be explicitly declared as an "unsigned char". > > > As char might be a signed char, c could feasibly be less than 0, > > Not if you declare it as unsigned explicitly. > > > and there's a small possibility that char could be some weird wide > > character thing, > > No, the C standard guarantees that a char is exactly a single byte; i.e. > sizeof(char) == 1. > > > so c could feasibly be greater than 255, we'll > > perform the checks just check to be on the safe side." Defensive > > programming. > > It can't be larger than 255 (precisely because it is limited to a single > byte). > > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. As someone pointed out, a byte is required to contain at least the unsigned 0 - 255 range. It can be larger. A lot of DSP chips support 32-bit access as the basic element. sizeof(char) == sizeof(long) == 1. Or he could have char redefined in a really stupid and non-C-conforming header somewhere someday. Not his fault. Characters intended to contain character data should in fact be 'char' rather tahn explicitly signed. The C library expects them that way; and the default is chosen for increased performance on the architecture in question, generally, or compatibility. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
I demand that Colin Walters may or may not have written... [snip] > No, the C standard guarantees that a char is exactly a single byte; i.e. > sizeof(char) == 1. Yes, but who's to say that a byte is 8 bits wide? :-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | Linux PC, Risc PC | youmustbejoking | Northumberland | No Wodniws here | demon co uk | Toon Army | http://www.youmustbejoking.demon.co.uk/progs.linux.html#debian> Houdini escaping from New Jersey!
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > On Mon, 2001-12-31 at 05:40, Julian Gilbey wrote: > > I believe that the author (Knuth) presumably thought "c should only be > > between 0 and 127, probably not even that far, and we're using c as an > > array index, where we've only allocated 256 chars for this array. > > Right. Then it should be explicitly declared as an "unsigned char". > > > As char might be a signed char, c could feasibly be less than 0, > > Not if you declare it as unsigned explicitly. > > > and there's a small possibility that char could be some weird wide > > character thing, > > No, the C standard guarantees that a char is exactly a single byte; i.e. > sizeof(char) == 1. OK. So then this check is either unnecessary or guards against the possibility that char is signed and that the chars we've hit are <0. But either way, it's a small piece of defensive programming for an essentially impossible situation. I'm not about to rewrite this code to remove a warning when I will potentially introduce real bugs. > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. That is a wise suggestion, indeed. Although there may be exceptions when it is unnecessary. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: Bug 99208
Santiago Vila <[EMAIL PROTECTED]> writes: > If only the location but not the contents of the files changed from > potato to woody, you can use the prerm to copy/move the files to the > new location before dpkg realizes they didn't previously exist. > > If both the location and the contents changed you can keep a small > database of md5sums to decide whether or not to put the new files > in place in the prerm before dpkg prompts. Neither changed. All that changed was whether the files were marked as conffiles.
Re: Bug 99208
On 30 Dec 2001, Thomas Bushnell, BSG wrote: > Please take a look at #99208 in the BTS, and give me some advice. > > The complaint is that there are a bunch of files in xpuzzles that > needed to be marked conffiles, but were not. Then, when that was > fixed, the result was that a whole bunch of files now got marked as > conffiles, and the result was that a bunch of user verifications > becomes necessary the first time someone upgrades. > > It seems to me that this is inherent in the task (as mentioned in > the BTS log by the previous maintainer). Accordingly, I think I > should just close the bug. > > But: is there a way to prevent the annoyance now? > > And: was there a way to prevent it in the first place (even if it's > too late now)? If only the location but not the contents of the files changed from potato to woody, you can use the prerm to copy/move the files to the new location before dpkg realizes they didn't previously exist. If both the location and the contents changed you can keep a small database of md5sums to decide whether or not to put the new files in place in the prerm before dpkg prompts.
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. IMHO, this is a peculiar statement. The type 'char' is best suited to things that are characters or bytes. For array indices, int tends to be a better choice: most CPUs cannot read single bytes any faster than machine words; compilers allocate registers at their full width; some architectures (68K for proper sign extension) sometimes require extra instructions in order to perform sub-word width math; careless alignment can be a problem with sub-word values packed into structures. Obviously, a compelling reason for 'char' as an index is when storing many of them, but in such a care must be taken to write what you mean and declare unsigned-ed-ness when that is what you want. Cheers.
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, 2001-12-31 at 05:40, Julian Gilbey wrote: > I believe that the author (Knuth) presumably thought "c should only be > between 0 and 127, probably not even that far, and we're using c as an > array index, where we've only allocated 256 chars for this array. Right. Then it should be explicitly declared as an "unsigned char". > As char might be a signed char, c could feasibly be less than 0, Not if you declare it as unsigned explicitly. > and there's a small possibility that char could be some weird wide > character thing, No, the C standard guarantees that a char is exactly a single byte; i.e. sizeof(char) == 1. > so c could feasibly be greater than 255, we'll > perform the checks just check to be on the safe side." Defensive > programming. It can't be larger than 255 (precisely because it is limited to a single byte). The more I think about it, the more it makes sense to always explicitly declare all char variables as signed or unsigned; otherwise, you're just asking for latent bugs.
Re: Source-only uploads
On Mon, Dec 31, 2001 at 02:34:56PM +, Mark Brown wrote: > On Mon, Dec 31, 2001 at 08:19:24PM +0900, Junichi Uekawa wrote: > > Are we trying to force users to use binary packages that even the > > maintainer of the package has not tried to install/run ? > > We do all the time. I expect the majority of the packages on the > machine I'm typing this on have not been installed or run by the > maintainer - but I guess that's what I get for using PowerPC. At least the architecture-independent parts, like the postinst scripts, should have been run by somebody, which is a useful check. -- Colin Watson [EMAIL PROTECTED]
Re: quake I for woody
Joseph Carter wrote: > > On Mon, Dec 31, 2001 at 07:02:43AM -0500, Jeff Teunissen wrote: > > > Jeff, unless I'm mistaken you've taken over maintainence of the > > > debian packaging of quakeforge and you have fairly current packaging > > > in the quakeforge-current tree in their cvs. I remember that when > > > knghtbrd decided to remove quakeforge packages from debian, it was > > > because of technical problems with the state of the quakeforge > > > codebase, and, it seemed to me, because of political type problems > > > as well. > > > > Yeah, I'm doing the Debian stuff, at least within QuakeForge. > > The stuff outside I have done. Back in March or so I designed a nice, > complex, and complete system for handling gamedata. It would work as > long as an engine using it had fs_* Cvars and config files. Unless of > course you did something unexpected in your config file, in which case > it puked. Too fancy, and it broke. Solution without a problem. Game data must keep its name, and both registered and unregistered Quake game data always has to be in id1. [snip] > I can actually do the necessary work to get the shareware thing done > next weekend (I'm going on holiday for a few days and won't have much > time for code..) As for the registered game installer, I've got > something written in perl for that already, but it's not much and it > comes with a big warning that perl is not a language I actually grok. I have had a quake-shareware package ready for upload since I needed one to finish the QF packages, about 3 months ago as I remember it. It's at my apt repo, alongside the (~1 month old) QF packages that depend on it. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: How to put files at a location determined at install-time.
David Z Maze wrote: Marc L de Bruin <[EMAIL PROTECTED]> writes: MLdB> What I am trying to build are a couple of packages (let's call one of MLdB> these mydata.deb) containing just ordinary files, related to a MLdB> specific application. All these packages Depend on a generic MLdB> configuration package. This configuration package determines the final MLdB> location of these ordinary files by asking the user via MLdB> debconf. Why do these files not have a specified location? Because their location depends on the lay-out of the filesystem of a specific system. It is getting more complicated now, but one of the requirements is that the root-user should at least have the choice to put these files on the same filesystem as the 'home' filesystem, because in that case, users can make hardlinks to these files from their own home directories. This is an important feature for the usage of the files. On my system, I have hde1 (mounted as /), and md0 (hde2+hdg1, mounted as /raid1). The home-dirs are on /raid1/home and I have a symlink /home -> /raid1/home (this probably is a bad thing, I know). So, the root-user might want the files to be physically installed on /raid1, e.g. /raid1/mydata, so that a user "blah" (/raid1/home/blah) can make a hardlink from /raid1/home/blah/afile to /raid1/mydata/afile. Therefore it is up to the root-user (and his filesystem) where the files should end up after installation. Is this possible? Thanks again, Marc.
Re: Debian installer
On Mon, Dec 31, 2001 at 10:20:14PM +1100, Penguin wrote: | How does it work? Broad overview: does it install a root filesystem and | simply do a huge cp /mnt/cdrom/package /wherever then configure, or what? It depends on what you tell it to do. It does all the basic setup of a system (partition tables, keyboard type, etc) and puts a base system on the partition you specify. The base system is enough to boot up, file management, and install additional packages. -D -- If your company is not involved in something called "ISO 9000" you probably have no idea what it is. If your company _is_ involved in ISO 9000 then you definitely have no idea what it is. (Scott Adams - The Dilbert principle)
Re: Debian installer
* Steve Kowalik | It then un'tar's the base tarball into /target, makes Linux bootable if you | said it could, and then reboots. There is no base tarball for woody; it then runs debootstraps which unpacks the .debs. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Debian installer
At 1:53 am, Tuesday, January 1 2002, Penguin mumbled: > How does it work? Broad overview: does it install a root filesystem and > simply do a huge cp /mnt/cdrom/package /wherever then configure, or what? > As I understand it, when you partition a drive, it mounts the too-be root partition as /target, and the other partitions you delegate under /target. It then un'tar's the base tarball into /target, makes Linux bootable if you said it could, and then reboots. And then you configure the network, apt, and a few other things, and it drops you to tasksel, or dselect. And then it uses them to install the rest of the system. There, a brief overview. And horribly i386-centric, to boot. -- Steve echo "WORK DAMNIT" > /dev/driverfs/eth0/status pgpbYKkOQiLOM.pgp Description: PGP signature
Re: quake I for woody
On Mon, Dec 31, 2001 at 07:02:43AM -0500, Jeff Teunissen wrote: > > Jeff, unless I'm mistaken you've taken over maintainence of the debian > > packaging of quakeforge and you have fairly current packaging in the > > quakeforge-current tree in their cvs. I remember that when knghtbrd > > decided to remove quakeforge packages from debian, it was because of > > technical problems with the state of the quakeforge codebase, and, it > > seemed to me, because of political type problems as well. > > Yeah, I'm doing the Debian stuff, at least within QuakeForge. The stuff outside I have done. Back in March or so I designed a nice, complex, and complete system for handling gamedata. It would work as long as an engine using it had fs_* Cvars and config files. Unless of course you did something unexpected in your config file, in which case it puked. Too fancy, and it broke. Since most engines don't have all that, I've just written /etc/quake.conf which gets sourced into a shell script. Contains GAMENAME and SHAREDIR. My wrapper script also assumes BASEDIR exists, though for obvious reasons it's kinda a bad idea for either file to contain that. Twilight and QF would just +set the appropriate fs_thing. Another engine such as DarkPlaces or something similar would use -sharedir, -basedir, and -gamename. As I said before, this requires a five-minute patch job. As for putting the mess in main, someone commented recently that OpenQuartz was almost usable now and has gone through the effort to make sure they've actually got license to use everything they're using. I still wonder about that, so I'll take a look for myself before trying to package it, but if it actually is worth packaging it'd put the engines in main. I can actually do the necessary work to get the shareware thing done next weekend (I'm going on holiday for a few days and won't have much time for code..) As for the registered game installer, I've got something written in perl for that already, but it's not much and it comes with a big warning that perl is not a language I actually grok. -- Joseph Carter <[EMAIL PROTECTED]>Certified free software nut "Hey, I'm from this project called Debian... have you heard of it? Your name seems to be on a bunch of our stuff." pgpijUjiDLlIO.pgp Description: PGP signature
Re: Source-only uploads
On Mon, Dec 31, 2001 at 08:19:24PM +0900, Junichi Uekawa wrote: > Are we trying to force users to use binary packages that even the > maintainer of the package has not tried to install/run ? We do all the time. I expect the majority of the packages on the machine I'm typing this on have not been installed or run by the maintainer - but I guess that's what I get for using PowerPC. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpzoSaGc3TUL.pgp Description: PGP signature
Re: Preparing a Proposal: 3 DD needed for every NEW package
Hi Junichi! You wrote: > Unmaintained, unused, and untested packages are in Debian. > If no one uses these packages, bugs won't be filed. > No bugs filed is not a status of well-being. But OTOH no bugs is neither an indication that the package is not being used. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+
Re: Source-only uploads
In Mon, 31 Dec 2001 09:59:04 + Mark cum veritate scripsit : > Conversely, I would sometimes like to be able to get my arch-specific > and arch-independant packages built by the build daemons in order to > detect build time errors that don't show up on my own system (missing > build deps, for example). Try pbuilder sometime. It's too much of a hack, but it kinda works. As to source-only uploads, I think it's dangerous. Are we trying to force users to use binary packages that even the maintainer of the package has not tried to install/run ? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Re: What config file for a .pm perl module ?
On Fri, Dec 28, 2001 at 11:16:03AM -0600, Colin Watson wrote:
> On Fri, Dec 28, 2001 at 03:02:29PM +0100, Eric Van Buggenhaut wrote:
> > my %virtual1 = {};
> [...]
> > $virtual1->{$user[0]}->{$fields[$_]} = $user[$_];
> [...]
> > When running the script using this module, I get this error:
> >
> > mrmime_SLASH:/# install-slashsite
> > Global symbol "$virtual1" requires explicit package name at
> > /usr/lib/perl5/DBIx/Password.pm line 47.
> >
> > What does it mean ??
>
> You've created the lexical variable %virtual1. Once you've done that,
> $virtual1{foo} is OK - that accesses elements of the hash.
> $virtual1->{foo} is something different, though. That takes $virtual1,
> treats it as a reference to a hash, and tries to access elements within
> that hash. You haven't declared $virtual1 as a lexical, so, since you
> have strict vars in force, perl correctly complains that you're using an
> undeclared package variable.
Oh, OK. I always get confused between the orthographic of hashes and
references to hashes : %virtual={}; $virtual=""; $virtual={};
>
> The important things to understand are:
>
> * $virtual1 is *not* the same as %virtual1. In particular, it occupies
> a different slot in the symbol table, and declaring one as a lexical
> doesn't affect the other. Don't get confused by the syntax for
> accessing elements of hashes [1].
>
> * {} returns a reference to a hash, not the hash itself.
Well, that really depends on the context.
>
> * Always, always, always use -w (or 'use warnings' in Perl >= 5.6). If
> you'd done this, you'd get the warning "Reference found where
> even-sized list expected", which points to the real problem.
>
I used it before and got this message too but since i didn't
understand it either, i quit the switch.
> In summary: your bug is that you need to change 'my %virtual1 = {};' to
> 'my $virtual1 = {};'.
>
Thanks for your good explanation.
--
Eric VAN BUGGENHAUT "Hay tampones y tampones..." (Eva Serrano)
Andago
\_|_/ Av. Santa Engracia, 54
\/ \/ E-28010 Madrid - tfno:+34(91)2041100
a n d a g o |--http://www.andago.com
/\___/\ "Innovando en Internet"
/ | \ [EMAIL PROTECTED]
Re: Source-only uploads
At (time_t)1009793105 "John H. Robinson, IV" wrote: > On Mon, Dec 31, 2001 at 09:59:04AM +, Mark Brown wrote: > > > > Conversely, I would sometimes like to be able to get my arch-specific > > and arch-independant packages built by the build daemons in order to > > detect build time errors that don't show up on my own system (missing > > build deps, for example). > > a clean chroot will solve that one for you. besides, the buildd's may > still have an un-listed build dependency, from a previous build. > Missing build-deps that do not cause the build process to break are a common problem on non-i386 architectures. The packages may be crippled in some way by the missing build dependency, and the maintainer and other users from the same architecture never notice, because the original binary upload was created with all necessary build dependencies installed. Source-only uploads would not automatically catch this problem, but if a package is missing certain key components on i386, the problem tends to be detected more quickly. Consistent use of chroots would also help address this. -- John Daily [EMAIL PROTECTED]
Re: What config file for a .pm perl module ?
On Sat, Dec 29, 2001 at 03:53:19PM +1100, Craig Sanders wrote:
> On Fri, Dec 28, 2001 at 01:11:15PM +0100, Eric Van Buggenhaut wrote:
> > print Dumper($virtula1);
> >
[...]
> which is pretty much the structure you wanted.
>
>
>
> other comments:
>
> i still think you should use a field separator which isn't in the field
> contents - much simpler, and far less prone to error.
>
I don't know about this, for example the user might supply a password
that indeed contains "|" and we don't know about this. My opinion was
that chances are reduced to have a clash between fields and fields
separators if we actually use a '2-characters' separator (':) in the
case of fields containing aleatory characters.
I don't know much about fields and fields separators though. I guess
there exist theories about how it should be built depending on the
contents of the fields and probably people have written about that. If
you have any pointer to documentation ... ;-)
[...]
> also, why have the connect string at all when it can be built up from
> the details provided in the other fields? it seems to me that the
> fields you need are:
>
> username
> dbi_driver
> attributes
> db_name
> db_host
> db_port
> db_user
> db_password
>
> the connect string can be built up like so:
>
> $connect = "DBI:$driver:database=$db_name:host=$db_host" ;
>
> (using db_port, db_user, and db_password as well if required)
Oh yes, that might be a good idea
Cheers,
--
Eric VAN BUGGENHAUT "Hay tampones y tampones..." (Eva Serrano)
Andago
\_|_/ Av. Santa Engracia, 54
\/ \/ E-28010 Madrid - tfno:+34(91)2041100
a n d a g o |--http://www.andago.com
/\___/\ "Innovando en Internet"
/ | \ [EMAIL PROTECTED]
Re: quake I for woody
Joey Hess wrote: > > Jeff, unless I'm mistaken you've taken over maintainence of the debian > packaging of quakeforge and you have fairly current packaging in the > quakeforge-current tree in their cvs. I remember that when knghtbrd > decided to remove quakeforge packages from debian, it was because of > technical problems with the state of the quakeforge codebase, and, it > seemed to me, because of political type problems as well. Yeah, I'm doing the Debian stuff, at least within QuakeForge. There are two problems with the packages; the lack of menus, and the problems with handling default sound output. I could make the default null, but then most people will think that QuakeForge doesn't have sound. Last thing I did was use alternatives to provide a "default" sound plugin, which worked nicely, but then we did some nasty things to plugin symbols which allowed people to statically link all of them into the main executables. Runs faster, but you can't load a plugin with a different name any more. Looks like it's time for debconf, I suppose. > Years ago, I used to maintain those non-free, binary-only packages, and > I didn't pass on maintainence with the expectation that quake would be > removed from the archive entirely later down the line. I would rather > see those nasty old packages copied from hamm (or was it rexx) woody bo, I think. [snip] > [1] Which don't seem fully resolved to me; they're still merging > code and have not produced an easily usable game with nicities > like menus). But maybe it's usable and just hard to use, which > documentation can solve well enough. Not unusable, but arcane to someone who is new to Quake or isn't used to dealing without menus. e.g. new game: map start invert mouse: m_pitch "-0.022" normal mouse: m_pitch "0.022" > [2] Or main, if Ben insists. And yeah, if necessary, I'm volenteering, > though I'd not be able to give it the time it probably requires. I don't really think it could be in main at this point. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Sun, Dec 30, 2001 at 11:09:50PM -0500, Colin Walters wrote: > On Sun, 2001-12-30 at 17:02, Julian Gilbey wrote: > > This package is correct as is, and the warning is harmless; the line > > of code involved is: > > > > return (c<0||c>255)? unexpected_char: icode[c]; > > > > where c is a char expected to be in the normal range (0<=c<=127). All > > the chars used in this code (AFAICT) are in this range. > > This still says to me there is likely a logic error in the code; if the > authors thought it was possible for c to take on a negative value at > some point, then it should be declared signed. Otherwise, why not just > declare it unsigned and remove the test for c < 0? I believe that the author (Knuth) presumably thought "c should only be between 0 and 127, probably not even that far, and we're using c as an array index, where we've only allocated 256 chars for this array. As char might be a signed char, c could feasibly be less than 0, and there's a small possibility that char could be some weird wide character thing, so c could feasibly be greater than 255, we'll perform the checks just check to be on the safe side." Defensive programming. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: my.debian.org
On Mon, Dec 31, 2001 at 12:08:30PM +0100, Martin Michlmayr wrote: > * Michael Bramer <[EMAIL PROTECTED]> [20011231 10:35]: > > yesterday I add a new status pages on request of a maintainer: > > http://ddtp.debian.org/pdesc/maintainer/<[EMAIL PROTECTED]> > > Your packages file is outdated. This page lists me as the maintainer > for a package of which I'm no longer the maintainer. not the Packages file was outdated. The update_db process had not updated the Maintainer db from the maintainer file. This is fixed and the build process should fix this. and now I see the next bug: the build process already run, but it don't remove the old files... See: ! $ cat /home/grisu/public_html/ddtp/maintainer/[EMAIL PROTECTED] ! dejapt_BR fritdaplhunlsk sv_SE ukrucs ! [EMAIL PROTECTED] !dadadodo !cplayde pt_BR ! dejapt_BR fritdaplhunlsk sv_SE ukrucs ! [EMAIL PROTECTED] !cplayde pt_BR I fix this also and start a new build process of this files. sorry. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Auf Windows 95 laufen so ziemlich alle Spiele. F?r ernsthaftes Arbeiten sollte man aber zus?tzlich ein Betriebssystem installieren. -- unknown pgp1hASfZJgGn.pgp Description: PGP signature
Re: Preparing a Proposal: 3 DD needed for every NEW package
In Sat, 29 Dec 2001 14:14:15 +0100 Josselin cum veritate scripsit : > I don't think all these packages should be swept out. Unmaintained > packages that don't have bunches of bugs shouldn't be a problem, for > example. No, it's a serious problem. Unmaintained, unused, and untested packages are in Debian. If no one uses these packages, bugs won't be filed. No bugs filed is not a status of well-being. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Debian installer
How does it work? Broad overview: does it install a root filesystem and simply do a huge cp /mnt/cdrom/package /wherever then configure, or what? Thx :) -- Penguin [EMAIL PROTECTED] "Girls are for pleasure; boys are for ecstasy."
Re: my.debian.org
* Michael Bramer <[EMAIL PROTECTED]> [20011231 10:35]: > yesterday I add a new status pages on request of a maintainer: > http://ddtp.debian.org/pdesc/maintainer/<[EMAIL PROTECTED]> Your packages file is outdated. This page lists me as the maintainer for a package of which I'm no longer the maintainer. -- Martin Michlmayr [EMAIL PROTECTED]
Re: How to put files at a location determined at install-time.
> On Mon, 31 Dec 2001 02:23:55 +0100 > "Marc" == Marc L de Bruin <[EMAIL PROTECTED]> wrote: Marc> Marc> So, to be more precise: debconf asks the user for that location, and Marc> puts it in the debconf-database at myapp/thelocation. Now, when Marc> installing mydata.deb, it should read the myapp/thelocation variable Marc> and install the files from within mydata.deb at that specific location. Marc> Marc> The main question is: is it possible and if so, how to do it? May be you should use symbolic links? I.e. install yourdata to fixed directory, /usr/share/yourdata/, probably, and then create symlinks from there using debconf. -- Alexander Kotelnikov Saint-Petersburg, Russia
Harden
Hi, I would like to have some information about harden ? Where can i find how to use and configure it ? Thnx +==+ | Why Reboot ?? | | Use Debian GNu/Linux | | www.debianworld.org| +==+
Re: Source-only uploads
On Mon, Dec 31, 2001 at 02:05:05AM -0800, John H. Robinson, IV wrote: > a clean chroot will solve that one for you. besides, the buildd's may > still have an un-listed build dependency, from a previous build. It would still be nice to have the external check. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgp47dC0ozcqT.pgp Description: PGP signature
Re: my.debian.org
On Mon, Dec 31, 2001 at 11:23:19AM +0100, Noel Koethe wrote: > On Mon, 31 Dez 2001, Michael Bramer wrote: > > > The point is to collect all informations about reports in a place that > > > is well known, easy to know for new developers (i.e. readable in the > > > developers reference) and kept up to date. > > > > yesterday I add a new status pages on request of a maintainer: > > http://ddtp.debian.org/pdesc/maintainer/<[EMAIL PROTECTED]> > > > > for your list... > > You have to add .txt to the end. > example: > > http://ddtp.debian.org/pdesc/maintainer/[EMAIL PROTECTED] yes, sorry And If we have a working packages.debian.org, I will make real HTML pages with links to the packages.debian.org. After this, you must add .html at the end... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Windows kann kein Virus sein. Ein Virus ist in der Regel klein, effizient und verrichtet seine Arbeit ohne dabei abzuschmieren. pgpVjPN7tdIHQ.pgp Description: PGP signature
Re: my.debian.org
On Mon, 31 Dez 2001, Michael Bramer wrote: Hello, > > The point is to collect all informations about reports in a place that > > is well known, easy to know for new developers (i.e. readable in the > > developers reference) and kept up to date. > > yesterday I add a new status pages on request of a maintainer: > http://ddtp.debian.org/pdesc/maintainer/<[EMAIL PROTECTED]> > > for your list... You have to add .txt to the end. example: http://ddtp.debian.org/pdesc/maintainer/[EMAIL PROTECTED] -- Noèl Köthe
Re: Source-only uploads
On Mon, Dec 31, 2001 at 09:59:04AM +, Mark Brown wrote: > > Conversely, I would sometimes like to be able to get my arch-specific > and arch-independant packages built by the build daemons in order to > detect build time errors that don't show up on my own system (missing > build deps, for example). a clean chroot will solve that one for you. besides, the buildd's may still have an un-listed build dependency, from a previous build. -john
Re: L10n of Debconf templates
On Mon, Dec 31, 2001 at 01:59:33AM +0100, Denis Barbier wrote: > there are 2 ways for a package maintainer to deal with l10n-ed Debconf > templates: either put all translations in a single file, or separate each > language in its own template file. > The former has a severe drawback, because when English text is modified, > there is no flag to tell that translated text is outdated, and translators > won't notice. > So it would be really nice if package maintainers do follow the latter, > and learn to play with Debconf goodies (debconf-getlang, > debconf-mergetemplate, > dh_installdebconf). > > If my figure are right, 258 source packages have translated Debconf templates, > but only 71 in separate files. and if my figure are right, we have a lot of open bug reports with translated Debconf templates (see http://auric.debian.org/~grisu/debian_translation/> In reality we need a framework for this translations... like the DDTP/DDTS. IMHO this all is not the task of a package maintainer. He don't know all the languages, he must ask for a update all the times after a change, he must search proofreaders for all the languages, He must track bugs and improvments in the translation, ... This can make all a good framework. We can add other parts to DDTS (like debconf templates), but - Now I have no time (btw: maybe someone will take over my package cupsomatic-ppd?) - debconf templates are more difficult (sometimes you need more knowledge for a translation) - We have some translated templates in the packages, some in the Debian-BTS, ... - Somebody must write a mail-parser and a 'update' client - Maybe we must rewrite more parts of the DDTS, the DDTS is now very package description centric I have this all on my todo list. But I will make this all, after the pdesc is 'finished'. (not really finished, but I have some open TODO-Points on my list...) If someone will help, write a mail... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux als typisch für linux benutzer gilt aber wohl immernoch eher was ala: "man blafurz | grep RTFM | cut -c /d 10-2837 | uahha" (Adam Kopacz) pgpap14qFzLCU.pgp Description: PGP signature
Re: Source-only uploads
On Mon, Dec 31, 2001 at 03:26:10AM -0600, Adam Heath wrote: > On Mon, 31 Dec 2001, Jonathan Hseu wrote: > > - Wouldn't the binaries be more trusted if they came from auto-builders > > anyways? > > So that way a maintainer can't just stick something in there that's not in > > the > > source code. > I would rather have the original upload be a binary one. I trust this more, > as the maintainer has more likely installed what he has just built, and tested > it out. No such assurance happens with a source only upload. Conversely, I would sometimes like to be able to get my arch-specific and arch-independant packages built by the build daemons in order to detect build time errors that don't show up on my own system (missing build deps, for example). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpmctHxZzvLz.pgp Description: PGP signature
Re: my.debian.org
On Sat, Dec 29, 2001 at 03:25:57PM +0100, Stefano Zacchiroli wrote: > On Sat, Dec 29, 2001 at 01:52:25PM +0100, Noel Koethe wrote: > > > As a debian developer, I like an easier way to find and keep up with > > > all the nice reports out there keeeping track of me. I think it would > > > help myslef and others do a better job if they were more accessable. > > > One suggestion is a "portal" page in the vein of MyYahoo -- i.e. a web > > > page generated specifically for me, linking to all those Debian > > > statistics and reports directly relevant to me. > > > > Just build your own personal page (replace login with your > > debian login) > > This is not the point: you are able to write that page because you know > what link put in it. > > The point is to collect all informations about reports in a place that > is well known, easy to know for new developers (i.e. readable in the > developers reference) and kept up to date. yesterday I add a new status pages on request of a maintainer: http://ddtp.debian.org/pdesc/maintainer/<[EMAIL PROTECTED]> for your list... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux als typisch für linux benutzer gilt aber wohl immernoch eher was ala: "man blafurz | grep RTFM | cut -c /d 10-2837 | uahha" (Adam Kopacz) pgpn9CWORKt2K.pgp Description: PGP signature
Re: Source-only uploads
On Mon, 31 Dec 2001, Jonathan Hseu wrote: > Last I asked on #debian-devel, source-only uploads aren't allowed (as in, you > can't just upload the orig.tar and the diff. With auto-builders in place, is > there any reason why? They are allowed. See pine. > There are reasons why source-only uploads should be preferred, some being: I consisder these reasons they should not be allowed. > - The package can be compiled on boxes that are up-to-date with bugfixes in > gcc > and other Build-Depends. I personally don't upgrade my sid box that often > (I currently have to upgrade 843 new packages, install 33 new ones, remove 17 > for a dist-upgrade, understand why? :) So, the maintainer doesn't know if his package works with the current set of software in debian? This seems like a loss. > - Wouldn't the binaries be more trusted if they came from auto-builders > anyways? > So that way a maintainer can't just stick something in there that's not in the > source code. I would rather have the original upload be a binary one. I trust this more, as the maintainer has more likely installed what he has just built, and tested it out. No such assurance happens with a source only upload. > Binary uploads should be allowed for packages that don't have source code at > all or ones that depend on themselves for bootstrapping. For packages that don't have source this is the only way, so your argument means absolutely nothing.
Source-only uploads
Last I asked on #debian-devel, source-only uploads aren't allowed (as in, you can't just upload the orig.tar and the diff. With auto-builders in place, is there any reason why? There are reasons why source-only uploads should be preferred, some being: - The package can be compiled on boxes that are up-to-date with bugfixes in gcc and other Build-Depends. I personally don't upgrade my sid box that often (I currently have to upgrade 843 new packages, install 33 new ones, remove 17 for a dist-upgrade, understand why? :) - Wouldn't the binaries be more trusted if they came from auto-builders anyways? So that way a maintainer can't just stick something in there that's not in the source code. Binary uploads should be allowed for packages that don't have source code at all or ones that depend on themselves for bootstrapping. For every other package, why aren't we using a source-only upload system right now? -- Jonathan Hseu <[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]> GPG ID: 5228D713 GPG fingerprint: 220B A4EF 70FE B884 CB38 F93F EA8A 1024 5228 D713 pgp0Ni2aFV4I2.pgp Description: PGP signature
Re: quake I for woody
On Mon, Dec 31, 2001 at 01:12:25AM -0500, Joey Hess wrote: > Jeff, unless I'm mistaken you've taken over maintainence of the debian > packaging of quakeforge and you have fairly current packaging in the > quakeforge-current tree in their cvs. I remember that when knghtbrd > decided to remove quakeforge packages from debian, it was because of > technical problems with the state of the quakeforge codebase, and, it > seemed to me, because of political type problems as well. Somewhat. The old QuakeForge packages were genuinely broken and segfaulted on start for a number of people. I could have tried to track down the problem, but was not willing to do that given the work involved to patch up a dead codebase. If QuakeForge still has no menus nor dependencies/fallbacks for the dozens of libraries it uses, I maintain my opinion that it's not ready to package yet. Still, whether and what to package is not my call and I'll defer to Jeff's judgement of the state of readiness of the project. The library problem could be mitigated somewhat by using debconf to write out a global default config. The menus were removed ages ago under the pretense that they would be replaced soon - that mistake was mine, but the code should still contain comments containing "MENU" or similar. Putting that back the way it was should be a simple task. The existing packages were an odd mishmash of two seperate yet equally broken and incompatible ways to mate the engine with its data. Since then, both have become obsolete. All new versions of QuakeForge support a set of Cvars for defining the locations of gamedata and which game to use by default (which allows for shareware and full gamedata to be installed at the same time without hacks, along with any other full TC you like..) It's also worthwhile to point out that this system can be applied to any and every Quake engine in a matter of ten minutes. I've written a sort of annotated diff which passes for a "tutorial" in the Quake community on how to implement similar features in all engines. > I don't care about the politics, I just think that it is crazy that > several old releases of debian shipped with non-free quake, potato > released with a working set of quakeforge packages, and woody looks like > it's going to release without quake at all. Unless you have plans to > slip quakeforge debs into it RSN, that is. There are a few other engines for Linux in various stages of stability including the one Zephaniah Hull and I have been working on, but none of them have the combination of Linux, NetQuake and QuakeWorld, and software rendering in the same project. For that reason if for none other, I would like to see working QuakeForge packages in Debian. That's the point though, working packages. I've been asked about Project Twilight packages a few times, but I don't even want to consider that until 0.2 is released. We're close to that, but there's a couple of bug reports still and rushing to get packages in before freeze is why the old Debian QuakeForge packages were so bad in the first places. If it's not done in time for freeze, it's not. We are very close though, I can count the number of things to do before release on one hand. > Years ago, I used to maintain those non-free, binary-only packages, and > I didn't pass on maintainence with the expectation that quake would be > removed from the archive entirely later down the line. I would rather > see those nasty old packages copied from hamm (or was it rexx) woody > than see a woody release with no quake at all. I'd much rather see > quakeforge or some other quake code base in contrib[2]. > > Can we do something about this? Those nasty old packages (libc5) are not necessary as I had permission to distribute the glibc2 binaries which were made for Quake: The Offering for Linux. I could also fix up SDLQuake for SDL 1.2, OpenGL, and QW support if need be. That at least I can apply -sharedir and -gamename switches to so that nasty symlink trees are not needed. -- Joseph Carter <[EMAIL PROTECTED]> <-- That boy needs therapy "What is striking, however, is the general layout and integration of the system. Debian is a truly elegant Linux distribution; great care has been taken in the preparation of packages and their placement within the system. The sheer number of packages available is also impressive" pgpe4hdeWQP4x.pgp Description: PGP signature
Processed: reassign
Processing commands for [EMAIL PROTECTED]: > reassign 127167 python2.1 Bug#127167: Python2.1 ceval.c error. Bug reassigned from package `general ' to `python2.1'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
quake I for woody
Jeff, unless I'm mistaken you've taken over maintainence of the debian packaging of quakeforge and you have fairly current packaging in the quakeforge-current tree in their cvs. I remember that when knghtbrd decided to remove quakeforge packages from debian, it was because of technical problems with the state of the quakeforge codebase, and, it seemed to me, because of political type problems as well. I don't care about the politics, I just think that it is crazy that several old releases of debian shipped with non-free quake, potato released with a working set of quakeforge packages, and woody looks like it's going to release without quake at all. Unless you have plans to slip quakeforge debs into it RSN, that is. Years ago, I used to maintain those non-free, binary-only packages, and I didn't pass on maintainence with the expectation that quake would be removed from the archive entirely later down the line. I would rather see those nasty old packages copied from hamm (or was it rexx) woody than see a woody release with no quake at all. I'd much rather see quakeforge or some other quake code base in contrib[2]. Can we do something about this? -- see shy jo, who hasn't played quake or doom in years [1] Which don't seem fully resolved to me; they're still merging code and have not produced an easily usable game with nicities like menus). But maybe it's usable and just hard to use, which documentation can solve well enough. [2] Or main, if Ben insists. And yeah, if necessary, I'm volenteering, though I'd not be able to give it the time it probably requires.
