Hi, > Am 15.06.2016 um 13:48 schrieb Jonas Smedegaard <d...@jones.dk>: > > Quoting Josua Mayer (2016-06-15 13:07:56) >> Am 15.06.2016 um 06:45 schrieb H. Nikolaus Schaller: >>> Am 15.06.2016 um 00:33 schrieb Jonas Smedegaard <d...@jones.dk>: >>>> Quoting Josua Mayer (2016-06-14 16:41:23) >>>>> I intended to make actual debs available, but I have yet to find >>>>> time uploading these huge things. For the moment packages will have >>>>> to be built from source, as to the instructions in the new >>>>> repositories linkd below. >>>>> >>>>> 1) Kernel: http://projects.goldelico.com/p/qtmoko2-kernel/page/README/ >>>> >>>> Seems to me a more appropriate name would be gta04-kernel. >>> >>> Well, "gta04-kernel" already exists and is the project for the kernel >>> source. But it should be renamed to Letux kernel (which is the >>> official project name). >>> >>> And we have to keep in mind that kernel is not only for the gta04 >>> device but also for others like openpandora and pyra (just by picking >>> a different device tree file). I don't know if you want to have 10 >>> slightly different kernel packages for 10 devices or a single one >>> that runs on all (just having different u-boot setup). The latter is >>> what we use for some time for LXDE/XFCE and Replicant and I do not >>> see a need to go back. >>> >>> On the other hand I agree that qtmoko2-kernel is also not exactly >>> right. >>> >>> A better name could be debian-kernel but that is also wrong. >>> >>> The best description would be some abbreviation of: >>> >>> kernel-for-letux-project-for-many-devices-but-not-all-packaged-for-debian > > Ok, so scope is the whole _family_ of Letux devices, not (the GTA04 > board of) Letux 2604 as I thought. > > Then the in my opinion most appropriate name is letux-kernel. > > >>>>> There is now an easy way to build a kernel deb from whatever >>>>> release our kernel hackers deem stable. It is meant to be unpacked >>>>> on top of a fresh rootfs. >>>> >>>> Great! >>>> >>>> I have improvements - at first to the README, to use only pure >>>> Debian, not need the (derivative of Debian) emdebian, but I may >>>> stumble upon other details I can polish. >> If you have good instructions for that, sure. I thought emdebian was >> still required to get the prebuilt cross-compiler. > > Emdebian is needed only with Jessie, not Stretch onwards. > > Assuming your end goal is inclusion in _Debian_ I would change the > documentation to talk about pure Debian by default now that is possible, > and mention workaround for Jessie and older only as a comments, to > clearly discourage use of that moving forward, and ease later cleanup. > > >>>> Can I please get write access to that repo, or should I rather post my >>>> proposed changes here for screening/discussion/whatever? >>> >>> You already should have... >> I believe this depends on how ripe your improvements are. At some >> point they are bound to hit me on the head, and this is when you >> should just commit them imo. > > Not sure what you mean by that. To be on the safe side I will *not* > touch that git until clarified that you consider it a help that I do so. > (but since mailinglist discussion is more tedious than git edits, I will > likely contribute _less_). > > >>>>> Thats it for now, as mentioned above you can expect an apt >>>>> repository to be made available soon(TM). >>>> >>>> As I mentioned also at our meeting, I would be happy to either host >>>> that APT repo or help set it up, if that is of interest. >> I have no objections here, whichever is easiest to upload either >> source- or binary packages to I guess. >>> >>> Since I am not sure how easy it is to set up write access for an apt >>> repo on the goldelico server (this is outside of the project >>> management tool), it would be a good idea to host it where the >>> infrastructure exists. >>> >>> Some things to think about: >>> * a different server needs to manage developer login twice >>> * ideally users would add some www.qtmoko.net path to /etc/apt/source.list >>> * so we need to add a forwarding link > > APT does not support http 301/302 redirection,
Hm. That is bad luck ... > so if branding is important, yes I think it is important. Small plants need a well defined home to keep all parts together. if we have a qtmoko.net home page downloads should come from the same domain (until they are some day part of ftp.debian.org). > then either services need to be established at your own hosts > or "forwarding" means entries in domain name system. Well, I can create a subdomain debian.qtmoko.net and direct it to whatever IP address the server is sitting on. At least in theory. In practice the qtmoko domains are hosted in a package that does not allow subdomains - but it can (an IMHO should) be changed (by paying some one-time transfer fee...). > > Most elegant setup involves root access (involves juggling low-port > services, cron jobs, and installation of tools). Can I be granted root > on your server No. There are other confidential projects running on the same server. This is why I thought to run it on a different server and just redirect the domain. > to set it up, or do I need to proxy all changes through > someone else (read: more bothersome)? Well, that might still be easier than all other setups. BR, Nikolaus
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Community mailing list Community@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.openphoenux.org
