Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Debian Traffic #3 For 21 Sep 2000

Editor: Zack Brown

By Eusebio C Rufian-ZilbermannSeth Cohn  and  Zack Brown

Debian Home Page | Weekly News | Social Contract | Constitution | Policy Manual
Developer's Reference | Documentation Project | debian-devel Archives

Table Of Contents

Introduction

KC Debian needs more authors! If you'd like to get involved, check out the KC Debian homepage.

We made it into the Debian Weekly News last week. Thanks, Joey, for the warm welcome!

Mailing List Stats For This Week

We looked at 421 posts in 1569K.

There were 183 different contributors. 86 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Keeping Calendar Files Up To Date

7 Sep 2000 - 11 Sep 2000 (12 posts) Archive Link: "please help updating calendar"

Summary By Seth Cohn

People: Marco d'ItriShaul KarlDavid StarnerJulian Gilbey

Marco d'Itri pointed out that "A calendar.hindu file is needed for 2000/2001 and the yearly calendar.christian needs to be updated to the new syntax. Duplicated events needs to be removed from the yearly calendar.judaic files." He also offered to add events of other religions.

Jaldhar H. Vyas offered to take care of 'calendar.hindu' for 2000/2001, but there was no reply.

Julian Gilbey didn't understand at first why Marco needed help, and Marco explained that he didn't really know the details about particular dates. Specifically, some events were only valid for a specific year, while others were always valid.

Julian and Marco went back and forth about the Jewish calendar, and at one point Shaul Karl mentioned, "the Jewish calendar is based on the motion of the moon, so that a regular Jewish year is 354 days long (Yet there are years with an extra month and maybe other mechanisms to compensate for that). But as far as I know every Jewish event could be calculated in advance." . One problem with this was that no event in the Jewish calendar always aligned with a Gregorian calendar date. The other issue was the assumption in '/usr/share/calendar/calendar.judaic' that the user is Orthodox and living outside of Israel, neither of which were necessarily true. At one point, Julian volunteered to look into merging and clarifying things.

Ferret asked about a Wiccan calendar, noting that northern and southern hemispheres had inverse events because of the agricultural differences, and that events were also based on a lunar cycle. This prompted David Starner to wonder, since each year the Jewish and Wiccan calendars had to be aligned with the Gregorian one, "Instead of doing this every year, why not write small programs to generate a new Wiccan calendar and a new Jewish calendar (and parts of the Christian calendar) each year?" There was no reply.

2. debian-devel And debian-user List Digests Broken

12 Sep 2000 - 13 Sep 2000 (2 posts) Archive Link: "digest version broken?"

Summary By Zack Brown

People: Remco van de MeentSeth Cohn

Seth Cohn had been reading debian-user and debian-devel as email digests, when they both suddenly went quiet. He subscribed to the digests again, in case he'd been bumped off the subscriber list for some reason, with no luck. Then he subscribed to the non-digested versions, and started receiving the list traffic. He asked about this, and Remco van de Meent, the Debian Listmaster, replied:

Digests are broken at the moment. I sent out a bunch of digests this morning, catching up with the email from the last couple of days.

I hope it will be business as usual quite soon.

There was no reply.

3. Building A Package That References Other Source Packages

13 Sep 2000 - 14 Sep 2000 (5 posts) Archive Link: "How do I build a package that requires the _source_ of another?"

Summary By Seth Cohn

People: Marcus BrinkmannMarco d'ItriEray OzkuralDaniel Jacobowitz

Eray Ozkural asked how to configure a package build that required sources from another existing package, without duplicating those sources, which might waste a lot of space.

Marcus Brinkmann replied, "Avoid it like hell. This is really unpleasant. Please, please consider all alternatives. For example, fixing the program so that it doesn't require the other source." Even duplicating the sources would be better, in his opinion. Marco d'Itri mentioned that his 'c-nocem' package tried to properly handle that. As an aside, he asked about the whereabouts of a file he had once seen that was used by build daemons listing all hacks of that kind. Daniel Jacobowitz pointed him to the Database of Manually Added Source Dependencies.

4. Support For Files Larger Than 2 GB In The X86 Architecture

13 Sep 2000 (2 posts) Subject: "Large file support again"

Summary By Eusebio C Rufian-Zilbermann

People: Nils RennebarthChristopher C. Chimelis

There are several components that need to be updated in order to support files larger than 2 GB. Nils Rennebarth explained how to update the current glibc, and gave a link to LFS In Linux. He said, "for glibc 2.1.3 in order to support large files it needs to be compiled against headers from a 2.4 kernel"

Christopher C. Chimelis replied that "Woody is shortly going to be moving to a pre-release of glibc 2.2, so this will become a non-issue." He also warned that it could the 'glibc' upgrade could potentially introduce many problems, and recommended users wait on getting LFS working under Debian.

He also mentioned that this is not an issue in other architectures like Alpha, which could handle files larger than 2G without a problem.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.