> Am 15.06.2016 um 14:42 schrieb Josua Mayer <josua.maye...@gmail.com>: > > > > Am 15.06.2016 um 14:10 schrieb H. Nikolaus Schaller: >> 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. > I see. Well that is a relieve! >>> >>> 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_). > What I mean is simple: If: > a) the change is tested > b) you dont feel like there is a need to discuss potential alternatives > feel free to commit. > I did consider a pull-request approach, but that is really pointless as > long as there are so few people working on this tree. >>> >>> >>>>>>> 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, > Really? I think I have been using both 301 and 302 for this purpose in > the past.
Maybe we should try this first. >> >> 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. > that seems the cleanest approach to me. >> >> 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 >> >> >> >> _______________________________________________ >> Community mailing list >> Community@openphoenux.org >> http://lists.goldelico.com/mailman/listinfo.cgi/community >> http://www.openphoenux.org >> > _______________________________________________ > Community mailing list > Community@openphoenux.org > http://lists.goldelico.com/mailman/listinfo.cgi/community > http://www.openphoenux.org _______________________________________________ Community mailing list Community@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.openphoenux.org
