Showing 71 - 80 of 692 Postings (
summary)
Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 01 May 2020, at 11:20 AM
Package Specification Summary for Package: calendar
Bug Tracker Summary for Package: calendar
Code Metrics Summary for Package: calendar
| # Tcl Procs |
55 |
| # Tcl Lines |
1604 |
| # Tcl Blank Lines |
270 |
| # Tcl Comment Lines |
170 |
| # Automated Tests |
6 |
| # Stored Procedures |
PG: 10 ORA: 12 |
| # SQL Lines |
PG: 849 (blank 127 comments 139)
ORA: 914 (blank 144 comments 160) |
| # ADP pages |
18 |
| # ADP lines |
655 |
| # Include pages (calendar/lib/) |
0 |
| # Documentation pages |
3
(Package Documentation)
|
| # Documentation lines |
664 |
| Browse Source |
API-browser |
| Github Repository: |
https://github.com/openacs/calendar/tree/oacs-5-10
|
Suggestions for improvement (from /forums/message-view?message_id=432244 ):
- different colors for different calendar sources
- easy and nice printout of week and monthly calendar
- Possibility to link one calendar item to many classes or community on creation or editing
- Attach files
- Change of repeating events after creation (if you have a different repeating sequence there is no way of changing the sequence)
- Site-wide calendar for holidays
- Department-wide calendars.
Sync contacts with contact managers, palm pda's etc.
Note I see a small potential issue. Within one calendar it makes sense to color code by calendar types. When using dotLRN or otherwise aggregating calendars it makes sense to color code by calendar_id (source). It probably never makes sense to do it both ways on the same site. We may need to think this through.
Text taken from Dirk document (2004)
Maintained by Dirk Gomez - last change on 22-Jan-2004.
I am tracking my work on calendar here. Please get in touch with me if you have comments.
Features Completed
- Separated code and presentation
- Notifications
- Removed unused or duplicated code and database queries.
- Proper use of OpenACS permissioning.
Features I am working on currently
- Code clean up
- Documentation of the data model
- CSS/XHTML
Features I will be working on
- The calendar view templates take a lot of parameters some of which require knowledge of the inner workings of the respective template: e. g. currently the calling templates passes in a url_template which determines whether an action on a particular item can be executed. I'll move this to being proper and understandable parameters like create_p or edit_p.
- New parameter Collaborative Calendar: a parameter that allows every user of a community to add, edit, and delete events if set to true.
- New parameter in DotLrn: parametrize whether to show calendar lists for a whole term.
- Allow users to store calendar preferences for example the user default view. The calendar_preferences table already exists, yet isn't used at all.
- Add a toggle: "Show all my events/Only this package's or community's events"
- Use a site-wide categories package to do away with the calendar types and the multiple calendars per package.
- Reminder - make it possible that a user sets a particular time on a calendar item to receive a reminder email
- Multi-day events
- iCal format compatible. Ideally, import/export to Outlook/iCalendar/etc.. via iCal format (by Jade)
- Ability to map any sort of date information in a database to the calendar, this means tickets, bugs, etc. perhaps via a service contract (by Jade)
- There should be any easy UI for specifying what is shown. Both the user and the admin should be able to select these things (the admin sets the range of what is possible, the user can select from those choices) (by Jade)
- Events should be able to span more than a day. Ideally, the UI for this should look good. (by Jade)
- An ability to be able to add data via the calendar as well. Anything that implements the service contract should allow you +to add information on that date as well. For example, add a ticket due that day, or add an event for that day, etc.. (by Jade)
- The calendar needs to be printable (at least for where I work - Jade)
- Desktop and Handheld support - cross-browser and cross-platform compatible (ryan-g2)
- Filters by calendar, keyword, object (e.g. Show all bug deadlines)
- Public event submission (unauthenticated) approved by an admin (ryan-g2)
- Invite people to events (ryan-g2)
- auto-book invitees if preference enabled, otherwise, require confirmation
- if there is a conflict among registered users' schedules, the systems suggests possible times to the inviter.
- people external to the system can be invited.
- Resource Scheduling - Booking (ryan-g2)
- Schedule one resource (room, car, laptop) per calendar
- Non-simultaneous booking (no overlapping times)
- Book an item: suggest alternate times across multiple calendars if asset is unavailable. Example: 5 Smart Cars for rent each have their own calendar; if all are booked from 10 - 11 AM, suggest 9-10 or 11-12 across all calendars.
- Optional bill for booked time (connect with ecommerce module)
Data Model Suggestions
Don:
Calendar items should map arbitrary objects (perhaps only content items) to a given calendar and given acs-events. We shouldn't have to derive special types from cal item type in order to attach it to a calendar (nor should we have to duplicate content to attach it to two calendars as we do now) If we restricted the mapping to content items (i.e. calendar info some sort of content type) we could use the CR's ability to map a template to a given content type or item to make it possible for the calendar package to display calendar item details using that facility, giving the package adding something to the calendar control over how it is displayed. Much more general.
ryan-g2:
Is it possible to optionally link any acs_object to an acs_event object (event)? Examples:
- People attached to a meeting event
- Bug item attached to a deadline
- Location attached to a meeting event [google maps integration]
- Project item attached to a deadline
- Simple time and description (for booking an asset) -- unattached to an object
- Multiple objects: Rent a car C from Time A to Time B and pick it up at Location L (Event linked to two objects C and L). See zipcar.com
From above: "Use a site-wide categories package to do away with the calendar types and the multiple calendars per package."
Features I started work on
I'm listing stuff here on which I am already working, but whose completion is nowhere near finished and there is not even an estimation when it may be finished.
- Integrate libical into AOLserver
- Lift as much as possible from Brandeis' Calendar, see this forum thread
Interesting Links
Notes
June 12, 2006 - Solution Grove worked on an AJAX calendar month view that has colors by calendar_types, has mouse overs for item details for each date, and changes months without refreshing the pages. They hope to contribute it at some point. Contact Caroline or Hamilton from Solution Grove if you need an advanced copy.
Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 18 Jan 2020, at 10:54 AM
- Avoid putting in Tcl code on ADP pages if possible
Although AOLserver/NaviServer ADP supports placing Tcl codes directing into ADP pages, one should used the ADP system wherever possible (see e.g. Using Templates in OpenACS or OpenACS Templating System).
- Quote in the master, pass "properties" literally from slave adp files
when variables are used in templates without modifiers (marked with a ";") then the values of the variables are internationalized and html-quoted. The substitutions should be done at the place, where the variables are actually used, which is for "properties" in the master templates. That the places, where the variable values are just passed on, the modifier ";literal" should be used to prevent quoting and internationalization.
Master:
<head>
<title>@doc.title@</title>
</head>
<body bgcolor="#ffffff">
<h1>@heading@</h1>
<slave>
</body>
Slave:
<master>
<property name="doc(title)">@title;literal@</property>
<property name="heading">@title;literal@</property>
...
Passing arguments to ADP includes:
<include src="name-of-included-adp" ... var="@value;literal@" ...>
or one can pass variables via reference to the include
<include src="name-of-included-adp" ... &="varName" ...>
- Pass always the "context" and "doc(title)" properties to the site master template
Example:
<property name="doc(title)">@title;literal@</property>
<property name="context">@context;literal@</property>
- Quote HTML attributes
Quoting HTML attribute values improves the safety against XSS attacks, especially when the attribute values are variables. Double quotes are preferred over single quotes, both are fine.
-
Common doc properties
The following doc properties are used in the blank-master template:
- doc(title): Title of the document
- doc(lang): Language of the document
- doc(type): HTML doc type declaration
- doc(base_href): The base URL to be used throughout the document for relative URLs (see base element)
- doc(base_target): A keyword or author-defined name of the default browsing context to display the result when links or forms cause navigation, for <a> or <form> elements without an explicit target attribute. (see base element)
Created by OpenACS community, last modified by Gustaf Neumann 06 Oct 2019, at 12:54 PM
Current topic: What approach should we use to upgrade the documentation?
Here are some recent approaches expressed in one form or another for managing the documentation in the context of "the plan":
Approach 0. Why not use docbook, which was the previous way documentation was being handled?
- docbook is open-source.
- A growing community surrounds DocBook (has mailing lists)
- A number of free and commercial tools are available for editing and publishing DocBook documents.
- docbook enables us to publish in a variety of formats.
- XML separates content from presentation: It relieves each contributor of the burden of presentation, freeing each writer to focus on content and sharing knowledge.
- docbook is well tested technology. It has been in development since the early 1990's).
problems: In 2002, Docbook still was not fully capable of representing online books as practiced by book publishers and expected from readers with regards to usability on the web. That meant DocBook did not entirely meet OpenACS publishing requirements at that time.
In 2004, Docbook released version 4.2, which complies with all the OpenACS publishing requirements. Producing a web friendly book hierarchy arguably remains DocBooks' weakest point. For example, a dynamically built document should be able to extract details of a specific reference from a bibliographic (table) and present a footnote at the point where referenced. DocBook 4.2 allows for this with bibliocoverage, bibliorelation, and bibliosource. Yet, OpenACS documentation does not follow a standard book hierarchy since most of the documentation was written before version 4.2, and re-organizing it in docbook source would be challenging.
Other problems with using docbook:
- Only developers can make changes, which makes it difficult for the rest of the community to coordinate changes and updates, especially when they are seemingly small (such as typos).
- OpenACS docbook has long documents, which puts extra stress on using consistent style to separate topics on the same page. For example, readers get confused when trying to follow the installation documents. Some instructions get missed, other instructions are done when they shouldn't have been.
- OpenACS docbook uses multiple tags for the same function and requires only certain tags to be used in certain contexts. The documentation in HTML is convoluted and displays inconsistent.
Based on the other recent suggestions, there seems to be a general consensus to move away from docbook, but perhaps keep the docbook organization.
Robert writes:
- First: ..attempt to take the rest of Documentation over to XoWiki..
- Secondly: ..try to setup an automated versioning system. We should end up with categories such as 5.2 Documentation, 5.3 Documentation, HEAD Documentation, etc. My current thinking is that we can work on HEAD category of documentation, once 5.3 is release it becomes categorized as such and a copy of the docs gets created and re-categorized as HEAD once again. This should allow versioning and easy upgrades/editing of docs (well easy may not be the right word, docs are a lot of work)
Robert, "Secondly" is how versioning has been accomplished using docbook. This method seems to work fine, and we can do it with xowiki docs by creating a set of static pages from the xowiki ones. --Torben
Approach 2
Robert writes:
Documentation: [move] ..the rest of the documents to XoWiki. The idea would be to have categorized documents. We would start by moving the 5.2 docs over and expanding on them. When 5.3 is release we would do an automated copy/paste of the 5.2 docs, re-categorize as 5.3 and start the editing process. This is just preliminary thinking at this point..
Robert, everyone seems to have their own way of slicing and dicing docs into categories. We ought to use the existing documentation requirements to guide how the documents are organized, and then they can be categorized any number of ways since multiple categories can be applied to each page. --Torben
Approach 3 (and previously 5). Refactoring original docbook docs en:New_Documentation_Process
STAGE A: CONVERT DOCUMENTATION TO XOWIKI (note: all api docs remain the same) Step #1. Catalog the current documentation.
(Malte writes) ..modify the script Gustaf provided to import the whole documentation in one go into a new XoWiki instance with the structure (page_order) that has been added in XoWiki 0.42 taken from the chapters of the documentation so that we do have an exact mirror of the documentation as it stands now. [Done, see https://openacs.org/test-doc].
Malte, why would we want an exact mirror of something that is not organized well.. too many topics per page and pages inconsistently presented.. requires a new reader to jump around to get familiarized with material. etc etc? Why not copy the docbook contents into a cleaner outline and work from there (as in approach 3 above)? --Torben
Torben, the /doc section is organized. That you do not like it is obvious and we could rework it later, but until we have the resource to rewrite the whole documentation, it makes much more sense to improve the documentation we have instead of putting it into the graveyard. And we need to come to terms. This discussion does not yield any results at the moment but keep us from doing the actual work: Improving the documentation -- Malte
[Then] ..assign categories to the documentation, allowing for an alternative view on the documents (so you could say "instead of showing the whole documentation only show the documents for a specific category"). Probably this needs some more detailed discussion with Gustaf finding out how this could be achieved in XoWIKI and what would make most sense. Ideally we could provide a different structure based on the target group (e.g. category) but this is probably shooting too far. Getting categorization and page ordering in a decent shape should provide us a lot of possibilities..
Malte, have you seen docs-admin-toc , docs-end-user-toc and docs-eng? These are outlines of existing pages in XoWiki that represent a revised version of the Table of Contents (TOC) in the docbook version. Feel free to propose new pages there for us to fill in content. --Torben
Yes I have seen them. Do they resemble a book in any way to you? They are alternative structures, indeed, but you can impose them on a book view as well, any time. A book is what we need, something people can go to and start reading. If the book starts with four different pages, each outlining a different reading path, even the better. But a book it should be nevertheless, because this is how people still learn. If you do not like the book approach, that is fine, then we should open this question up for a TIP. My main goal at the moment is to finally get this done and start working. And I want to get rid of the myriads of confusing advise given at openacs.org. I have someone to work with me on that in the next two months and I want to have a clear way to go forward. So I will just TIP this. -- Malte
See also: en:wikidoc-notice
This approach was originally posted at en:Documentation_Project. It was moved here as the topic expanded.
..port docbook pages to xowiki manually.. look at each part in detail.. separate to subsystems and how they are used (context). Why?
"..the human mind can only deal with a relatively small number of independent pieces of data at one time, but if data are chunked together in appropriate ways, the mind can perform higher order abstractions, and these in turn can be chunked together, with successive abstractions, until an entire complex situation is encompassed. The systems approach addresses this property of the human mind by providing strategies for the data gathering, chunking, and abstracting process." George G. Lendaris, On Systemness and the Problem Solver: Tutorial comments 1983.
A short video on how the mind deal best with large amounts of information by "chunking": The Science of Thinking
This work is in progress, with root documentation page here: en:openacs-handbook
A systems strategy of multiple perspectives has these rules:
- Each xowiki page discusses a single topic.
- Topics are linked together by any number of other xowiki pages to present an ordered presentation of the topics with a common thread/topic connecting them. For example, en:openacs-system-install is a page that links together the topics of installing the component software of OpenACS. Similarly, each component software, such as en:aolserver, has its own view of some overlapping topics.
Multiple perspectives meets these significant documentation requirements:
- helps identify subsystems and how OpenACS works --becomes a natural tutorial without more words.
- reduces the burden of keeping documentation up to date since there is only one place to put relevant information for a particular topic --no redundancy
- pages are not organized by a dominant category morphology that tends to address the perspectives of just a few people. Most any perspective can be represented.
- Readers do not have to filter out a bunch of information that is irrelevant to them or their task at hand.
Move all but maybe the first and last 2 items from https://openacs.org/doc/dev-guide.html to https://openacs.org/doc/acs-kernel/ (and what ever else is relevant to kernel only); and move the first item to https://openacs.org/doc/acs-admin etc. That way the core docs are presented in a consistent context with the other packages. Also, do not migrate these docs around as a package is designated part of the core (or subsequently removed from it). This would help developers see appropriate context (and meets one of the documentation requirements).
Allow documentation to link directly to the api-docs, to reduce redundancy and links go to current, local API docs. In other words, https://openacs.org/api-doc/package-view?version_id=358136 becomes: /api-doc/index?about_package_key=acs-datetime The feature has been added to OpenACS 5.3 so will be released soon.[DONE]
Move Administrator's Guide to the xowiki [in progress, see en:docs-admin and en:docs-admin-toc ], because this section:
- has the most duplicated work (topics overlap on various pages). For example, more than one page explains how to add a package, how to restart the server, how to start the server etc.
- needs to be updated most frequently because of changing installation requirements. For example, PostgreSQL requires different instructions for different revisions, external links change sporadically etc.
Incorporate the work already done in the first wiki ( https://openacs.org/wiki ), where volunteers have already added a wealth of new documentation. Note that some of this will already exist in xowiki from previous importing of docs etc. [TO DO]
We need to get rid of the myriads of different installation instructions. First of all they are not kept up to date (all of them). -- Malte
Created by Carl Robert Blesius, last modified by Gustaf Neumann 26 Sep 2019, at 08:36 PM
- Accessible and semantic layout/design (first priority)
- Layout for screen reader readability
- Consistent CSS for all packages with inheritance where possible
- Package specific CSS only where absolutely necessary
- Remove as many images as possible
- Totally simplified CSS scheme
- Consistent deprecation
- Support for 4 font sizes without UI breakup
- File path re-factoring so designers can easily skin a local installation and upload zip file with local styles for sharing accross installations
- A theme page that includes as many existing adp chunks and form templates as possible.
- Theme manager that allows a designer to upload a css file and immediately test it against the theme page.
- One style for screen, one for print, and one for mobile
Discussion
0. Why not OpenACS Zen? I think this needs to apply across the toolkit for any package, not just .LRN ones, or there will forever be problems as new applications come out for OpenACS, and are later adopted for .LRN. DaveB, we are going to start with .LRN b/c it contains a limited number of packages and also because there is an accessibility push in the project. A big portion of this will also be defining best practices. CarlB
1. I agree with Carl. I have been working through some of this on our own generic OpenACS installs here but would love to co-ordinate with others. Robert.
2. I also will help out. I have several tools available and will look at what is redundant and post soon. Jon Griffin
3. Please consider expanding the scope of the guidelines to include OpenACS and similar efforts underway at Interface / CSS Coding Guidelines. Accessibility etc. is important for the entire toolkit and long overdue. -Torben
Created by Ryan Gallimore, last modified by Gustaf Neumann 26 Sep 2019, at 08:34 PM
not to be confused with messages
Preliminary Specs for private-messaging package
Send a message or invite any online user from a textbox located at the top of every screen.
- User/Subsite Group selection widget.
- AJAX filter-as-you-type search "Smart Search"
- Confirmation for sending to entire subsite group.
- Message textbox
- Audio alert upon incoming message
"User is now online" messages.
- Incoming messages field with history (dropdown window)
- Send message to new online user via a link in history window
Users can block unwanted users or ignore all messages.
- "Block User" button
- "Unblock User" button
- "Ignore all messages"
- "Accept all messages" (except those from blocked users)
Created by Ryan Gallimore, last modified by Gustaf Neumann 26 Sep 2019, at 08:27 PM
As root:
OPENACS_SERVICE_NAME=service1 # Name your service
export $OPENACS_SERVICE_NAME
groupadd web
useradd -g web $OPENACS_SERVICE_NAME mkdir /var/lib/aolserver
cd /var/lib/aolserver
# Download latest tarball:
>> wget [URL to latest tarball]
>> tar xzvf [tarball.tar.gz]
>> mv [tarball_dir] $OPENACS_SERVICE_NAME
# OR, checkout from CVS. Replace oacs-5-4 with the branch of your choice.
>> cvs -d:pserver:anonymous@cvs.openacs.org/cvsroot checkout -r oacs-5-4 acs-core
>> mv openacs-4 $OPENACS_SERVICE_NAME
chown -R $OPENACS_SERVICE_NAME.web /var/lib/aolserver/$OPENACS_SERVICE_NAME chmod -R 770 /var/lib/aolserver/$OPENACS_SERVICE_NAME
# PostgreSQL 8.x
service postgresql stop yum -y remove postgresql # Download the PG rpm
# Initialize the Cluster
service postgresql initdb
# Start the service
service postgresql start
# Start pg on boot
chkconfig postgresql on
# Change postgresql.conf
# AOLServer
Try the AOLServer 4.5 page. The archive download works well
(but uses sources from 2006).
# Daemontools should now be installed, so let's set it up to start, stop and restart AOLServer
cd /service
ln -s /var/lib/aolserver/$OPENACS_SERVICE_NAME/etc/daemontools $OPENACS_SERVICE_NAME
# Daemontools will no scan the etc/daemontools directory and find the run script.
Read this for more information on Daemontools commands
# Modify the etc/daemontools/run script for your ip, user and group. Note the -b IP:PORT flag that # must be added for privileged ports.
# Modify etc/config.tcl to match your hostname and IP. aolserver director should be /usr/local/aolserver
# avoid pid not found errors in the log
chown -R $OPENACS_SERVICE_NAME.web /usr/local/aolserver/log
chmod -R 775 /usr/local/aolserver/log
# Start the server!
svc -u /service/$OPENACS_SERVICE_NAME
# Watch the log for errors:
tail -f /var/lib/aolserver/$OPENACS_SERVICE_NAME/log/error.log
If successful, call up the site URL and install the data model.
# Done!
Created by Adrian Catalan, last modified by Gustaf Neumann 26 Sep 2019, at 08:20 PM
Tools required for the development
The following packages come with the standard Debian installation, so you probably have them already. Still, you should check with `dpkg -s <package>`.
-
make
usually creation of a program takes several steps, so rather than having to type out the same commands over and over again, you can use this program to automate the process, creating `Makefile's.
You'll probably want to install the following packages, too:
Initial debianization
Please note that you should run dh_make only once, and that it won't behave correctly if you run it again in the same, already "debianized", directory.
Make sure you're in the program source directory, and issue this:
dh_make -e your.maintainer@address -f ../openacs-5.1.5.tar.gz
Of course, replace the string "your.maintainer@address" with your e-mail address for inclusion in the changelog entry and other files.
Some information will come up. It will ask you what sort of package you want to create. Gentoo is a single binary package - it creates only one binary, and thus one .deb file - so we will select the first option, with the `s' key, check the information on the screen and confirm by pressing <enter>.
After this execution of dh_make, a copy of the upstream tarball is created as openacs-5.1.5.orig.tar.gz in the parent directory to accommodate the creation of the non-native Debian source package with the diff.gz
Debian release
Let's say that a bug report was filed against your package and it describes a problem that you can solve. To create a new Debian revision of the package, you need to:
- Correct the problem in the package source, of course.
- Add a new revision at the top of the Debian changelog file, for example with `dch -i`, or explicitly with `dch -v <version>-<revision>' and then insert the comments using your preferred editor.
Tip: how to easily get the date in required format? Use `822-date', or `date -R'.
Include a short description of the bug and the solution in the changelog entry.
- Repeat a complete rebuild of the package.
New upstream release
Let's consider a different, slightly more complicated situation - a new upstream version was released, and of course you want it packaged. You need to do the following:
- Download the new sources and put the tarball (e.g. named `openacs.5.2.1.tar.gz') in the directory above the old source tree (e.g. ~/openacs/).
- Enter the old source directory, and run:
uupdate -u openacs.5.2.1.tar.gz
uupdate will properly rename that tarball, try to apply all the changes from your previous .diff.gz file, and update the new debian/changelog file.
- Change directory to `../openacs.5.2.1', the new package source tree, and repeat a complete rebuild of the package
Complete rebuild
Enter the program's main directory and then issue this command:
dpkg-buildpackage -rfakeroot
This will do everything for you. It will:
- clean the source tree (debian/rules clean), using fakeroot
- build the source package (dpkg-source -b)
- build the program (debian/rules build)
- build the binary package (debian/rules binary), using fakeroot
- sign the source .dsc file, using gnupg
- create and sign the upload .changes file, using dpkg-genchanges and gnupg
The only input that will be required of you is your GPG key secret pass phrase, twice.
After all this is done, you will see the following files in the directory above (~/openacs/):
- openacs_5.1.5.orig.tar.gz
This is the original source code tarball, merely renamed to the above so that it adheres to the Debian standard. Note that this was created using the `-f' option to dh_make when we initially ran it.
This is a summary of the contents of the source code. The file is generated from your `control' file, and is used when unpacking the source with dpkg-source. This file is GPG signed, so that people can be sure that it's really yours.
This compressed file contains each and every addition you made to the original source code, in the form known as "unified diff". It is made and used by dpkg-source. Warning: if you don't name the original tarball packagename_version.orig.tar.gz, dpkg-source will fail to generate the .diff.gz file properly!
If someone else wants to re-create your package from scratch, they can easily do so using the above three files. The extraction procedure is trivial: just copy the three files somewhere else and run dpkg-source -x openacs_5.1.5.dsc.
This is your completed binary package. You can use dpkg to install and remove this just like any other package.
- openacs_5.1.5_i386.changes
This file describes all the changes made in the current package revision, and it is used by the Debian FTP archive maintenance programs to install the binary and source packages in it. It is partly generated from the `changelog' file and the .dsc file. This file is GPG signed, so that people can be sure that it's really yours.
Trivial repository construction
Trivial repositories consist of one root directory and of as many subdirectories as you wish. As the users have to specify the path to the root of the repository and the relative path between the root and the directory with the index files in it, you are free to do whatever you want (even to put everything into the root of the repository; then, the relative path will be simply “/”)
We'll create a trivial repository with two subdirectories
(your repository root)
|
|-binary
+-source
Creating Index Files
dpkg-scanpackages generates the Packages file and dpkg-scansources the Sources file.
They both send their output to stdout; thus, to generate compressed files, you can use a command chain like this one: dpkg-scanpackages arguments | gzip -9c > Packages.gz.
The two tools work the same way; they both take two arguments (in reality there are more, but I won't go into that here; you can read the manpages if you want to know more); the first the directory under which the packages are, and the second is the override file. We don't need override files for simple repositories, but as it is a required argument, we simply pass /dev/null.
dpkg-scanpackages scans the .deb packages; dpkg-scansources scans the .dsc files. It is thus necessary to put the .orig.gz, .diff.gz and .dsc files together. The .changes files are not needed.
$ cd my-repository
$ dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
$ dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz
From Debian Maintainers' Guide, installer developed by Otto Solares updated by Adrián Catalán at Galileo University as a part of the E-LANE project
Related instructions for installing at:
Created by Caroline Meeks, last modified by Gustaf Neumann 25 Sep 2019, at 10:20 PM
url stub: /assessment/asm-admin/
url: http://mgh.zill.net/assessment/asm-admin/
Current: 
This is the "top level" it should have links to things that are potentially used in all Assessments.
I suggest the following links in class = button style along the top.
[[New Assessment]] | [[Display Types]] | Categories | Actions | Requests | Permissions | Documentation
- We don't need to repeat the word "Administer" we are on the administration page.
- Remove the QTI upload, it is another way to create a New Assessment so it should be an option after you click New Assessment.
- Remove Export and Permissions from the list of Assessments. Those are options that have to do with one assessment and should be on that assessment's admin page Assessment_one-a.
Assessment Listing
Display the list of assessments as a sortable table. We have moved some actions to the Assessment_one-a page so lets use that real estate to give people information that might help them find the Assessment they are interested in.
Title Last Modified By Last Modified Date Request Permission
