Re: How to push back against repeated login attempts?

On Wednesday, March 3, 2021, wrote: > So honeypot or tarpit seems like something to try. Endlessh sounds good, but labrea and iisemulator have debian packages. Any suggestions or warnings to consider? if you run exim4 and live spamassassin mta-time the teergrube config is a lot of fun

Re: How to push back against repeated login attempts?

On Tue, Mar 2, 2021 at 9:51 AM wrote: > Considering running a freedom box or similar, I have a RPi running Buster > outside my home router's DMZ. It was discovered within a short time (minutes > or hours) of first being setup. ahh yes. welcome to the discovery that there are people running

Re: Debian Bullseye on Raspberry Pi 4 4GB?

On Friday, February 19, 2021, Pete Batard wrote: > Why, when it is absolutely possible to achieve it, as was demonstrated on a cheap platform like the Pi (that actually comes with horrible quirks to be able to accomplish so, especially in terms of xHCI support), should end users have to juggle

Re: Reducing apt's memory footprint (on small boxes)

i remembered sonething: the apt packages are read into memory in order to sort them alphabetically, aren't they? (i.e. there's no database per se) that being the case, then, well, doing a hierarchical office paperwork sort would do the trick. first not-sort by appending all packages beginning

Re: Reducing apt's memory footprint (on small boxes)

On Monday, February 15, 2021, Paul Wise wrote: > On Sun, Feb 14, 2021 at 2:53 PM Paul Wise wrote: > >> I think that this could be useful to a subset of Debian users, >> possibly including embedded hardware and low-RAM cloud/VPS users. > > This could also be useful to bandwidth-constrained

Re: Debian on reMarkable paper tablet?

On Wed, Jan 6, 2021 at 11:59 AM Martin Lucina wrote: > It probably wouldn't be too hard to get Debian to boot on it, i saw in the notes of the developer that the PCB is pretty much a standard vanilla iMX6 Reference Design. consequently it should be much easier to reverse-engineer than it first

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

On Mon, Aug 19, 2019 at 7:29 PM Sam Hartman wrote: > Your entire argument is built on the premise that it is actually > desirable for these applications (compilers, linkers, etc) to work in > 32-bit address spaces. that's right [and in another message in the thread it was mentioned that builds

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

On Wed, Aug 14, 2019 at 5:13 PM Aurelien Jarno wrote: > > a proper fix would also have the advantage of keeping linkers for > > *other* platforms (even 64 bit ones) out of swap-thrashing, saving > > power consumption for build hardware and costing a lot less on SSD and > > HDD regular

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Aug 9, 2019 at 1:49 PM Ivo De Decker wrote: > > Hi Aurelien, > > On 8/8/19 10:38 PM, Aurelien Jarno wrote: > > > 32-bit processes are able to address at maximum 4GB of memory (2^32), > > and often less (2 or 3GB)

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 8, 2019 at 9:39 PM Aurelien Jarno wrote: > We are at a point were we should probably look for a real solution > instead of relying on tricks. *sigh* i _have_ been pointing out for several years now that

Re: loss of synaptic due to wayland

On Wed, Jul 10, 2019 at 2:34 PM Gene Heskett wrote: > > On Wednesday 10 July 2019 03:19:04 Luke Kenneth Casson Leighton wrote: > > > On Wed, Jul 10, 2019 at 2:11 AM Gene Heskett > wrote: > > > On Tuesday 09 July 2019 10:01:44 Luke Kenneth Casson Leighton wrot

Re: loss of synaptic due to wayland

On Wed, Jul 10, 2019 at 2:11 AM Gene Heskett wrote: > > On Tuesday 09 July 2019 10:01:44 Luke Kenneth Casson Leighton wrote: > > for source stuff: > > * apt-get source {package} - gets the *source code* of a package > > doesn't exist, this stuff is tar.gz's straight f

Re: loss of synaptic due to wayland

(hi gene, hope you don't mind, i'm cc'ing the list back again, i assume you accidentally didn't hit "reply-to-all?" or that i did, if so, whoops...) On Mon, Jul 8, 2019 at 7:20 PM Gene Heskett wrote: > > On Monday 08 July 2019 08:37:14 Luke Kenneth Casson Leighton wrote: >

Re: loss of synaptic due to wayland

On Mon, Jul 8, 2019 at 2:01 PM Andrei POPESCU wrote: > > On Lu, 08 iul 19, 07:42:46, Gene Heskett wrote: > > > > yes it was, and no solution was offered that I read about. And no, > > aptitude is not a replacement. I've hit q for quit and had it tear a > > working system down to doing a reinstall

Re: loss of synaptic due to wayland

On Mon, Jul 8, 2019 at 12:55 PM Gene Heskett wrote: > yes it was, and no solution was offered that I read about. And no, > aptitude is not a replacement. used it once or twice, wasn't impressed, returned to apt-get and apt-cache search, which work extremely well, and have done since debian

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

On Mon, Jan 7, 2019 at 11:30 PM Mike Hommey wrote: > > it would be extremely useful to confirm that 32-bit builds can in fact > > be completed, simply by adding "-Wl no-keep-memory" to any 32-bit > > builds that are failing at the linker phase due to lack of memory. > > Note that Firefox is

Re: armel *and* armhf qualification for Wheezy

https://sourceware.org/bugzilla/show_bug.cgi?id=22831#c25 steve, mike, any news on the use of the options recommended in comment #25 ? this for native 32-bit builds. Ian Lance Taylor 2019-01-09 23:48:45 UTC When using gold the key options are --no-mmap-output-file --no-map-whole-files

Re: armel *and* armhf qualification for Wheezy

On Thursday, May 17, 2012, Steve McIntyre wrote: > On Wed, May 16, 2012 at 09:18:38PM +0200, Mike Hommey wrote: > > >> >Would it be worth trying to link with gold for these? > >> > >> It might be, yes. I can try that with iceweasel on an imx53 or Panda > >> with 1GB if you like. Are there any

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

https://sourceware.org/bugzilla/show_bug.cgi?id=22831 sorry using phone to type, mike, comment 25 shows some important options to ld gold would it be possible to retry with those? 32 bit. Disabling mmap looks really important as clearly a 4gb+ binary is guaranteed going to fail to fit into 32bit

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

On Tue, Jan 8, 2019 at 7:26 AM Luke Kenneth Casson Leighton wrote: > > On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton > wrote: > trying this: > > $ python evil_linker_torture.py 3000 400 200 50 > > running with "make -j4" is going to take a few

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton wrote: > i'm going to see if i can get above the 4GB mark by modifying the > Makefile to do 3,000 shared libraries instead of 3,000 static object > files. fail. shared libraries link extremely quickly. reverted to stati

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

$ python evil_linker_torture.py 3000 100 100 50 ok so that managed to get up to 1.8GB resident memory, paused for a bit, then doubled it to 3.6GB, and a few seconds later successfully outputted a binary. i'm going to see if i can get above the 4GB mark by modifying the Makefile to do 3,000

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

On Tue, Jan 8, 2019 at 6:27 AM Luke Kenneth Casson Leighton wrote: > i'm just running the above, will hit "send" now in case i can't hit > ctrl-c in time on the linker phase... goodbye world... :) $ python evil_linker_torture.py 2000 50 100 200 $ make -j8 oh,

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

$ python evil_linker_torture.py 2000 50 100 200 ok so it's pretty basic, and arguments of "2000 50 10 100" resulted in around a 10-15 second linker phase, which top showed to be getting up to around the 2-3GB resident memory range. "2000 50 100 200" should start to make even a system

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

On Tuesday, January 8, 2019, Mike Hommey wrote: > On Mon, Jan 07, 2019 at 11:46:41PM +0000, Luke Kenneth Casson Leighton > wrote: > > > At some point apps are going to become so insanely large that not even > > disabling debug info will help. > > That's less

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

On Tuesday, January 8, 2019, Mike Hommey wrote: > . > > Note that Firefox is built with --no-keep-memory > --reduce-memory-overheads, and that was still not enough for 32-bts > builds. GNU gold instead of BFD ld was also given a shot. That didn't > work either. Presently, to make things link at

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

(hi edmund, i'm reinstating debian-devel on the cc list as this is not a debian-arm problem, it's *everyone's* problem) On Mon, Jan 7, 2019 at 12:40 PM Edmund Grimley Evans wrote: > > i spoke with dr stallman a couple of weeks ago and confirmed that in > > the original version of ld that he

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

On Sun, Jan 6, 2019 at 11:46 PM Steve McIntyre wrote: > > [ Please note the cross-post and respect the Reply-To... ] > > Hi folks, > > This has taken a while in coming, for which I apologise. There's a lot > of work involved in rebuilding the whole Debian archive, and many many > hours spent

Re: Upcoming Qt switch to OpenGL ES on arm64

t it anymore in this > thread. I might still complain even, but thats how it is. And its not > your fault so please don't take it personal, its certainly not intended > to be. > > Take care and stay well, Luke Kenneth Casson Leighton. you too, gene. l. [1] https://www.titanians.org/the-bill-of-ethics/

Re: Upcoming Qt switch to OpenGL ES on arm64

On Tue, Nov 27, 2018 at 6:47 AM Gene Heskett wrote: > > On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton wrote: > > > On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer > > > > wrote: > > > So: what's the best outcome

Re: Upcoming Qt switch to OpenGL ES on arm64

On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer wrote: > So: what's the best outcome for our *current* users? Again, pick only one. here's a perspective that may not have been considered: how much influence and effect on purchasing decisions would the choice made have? we

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

spoke again to TL and asked if pine64 would be willing to look at sponsorship witn rockpro64 boards (the ones that take 4x PCIe): if someone from debian were to contact him direct he would happily consider it. i then asked him if i could cc him into this discussion and he said he was way *way*

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

On Fri, Jun 29, 2018 at 8:13 PM, Luke Kenneth Casson Leighton wrote: > On Fri, Jun 29, 2018 at 6:59 PM, Jonathan Wiltshire wrote: > >>> also worth noting, they're working on a 2U rackmount server which >>> will have i think something insane like 48 Rock64Pro boards in

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jun 29, 2018 at 8:31 PM, Florian Weimer wrote: > * Luke Kenneth Casson Leighton: > >> that is not a surprise to hear: the massive thrashing caused by the >> linker phase not being possible

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

On Fri, Jun 29, 2018 at 6:59 PM, Jonathan Wiltshire wrote: >> also worth noting, they're working on a 2U rackmount server which >> will have i think something insane like 48 Rock64Pro boards in one >> full-length case. > None of this addresses the basic DSA requirement of remote management. >

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

On Fri, Jun 29, 2018 at 5:21 PM, Steve McIntyre wrote: >>2G is also way too little memory these days for a new buildd. > > Nod - lots of packages are just too big for that now. apologies for repeating it again: this is why i'm recommending people try "-Wl,--no-keep-memory" on the linker phase

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

On Fri, Jun 29, 2018 at 3:28 PM, Samuel Thibault wrote: > Roger Shimizu, le ven. 29 juin 2018 23:04:26 +0900, a ecrit: >> On Fri, Jun 29, 2018 at 10:04 PM, Uwe Kleine-König >> wrote: >> > On 06/29/2018 11:23 AM, Julien Cristau wrote: >> >> 2G is also way too little memory these days for a new

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

On Fri, Jun 29, 2018 at 1:12 PM, John Paul Adrian Glaubitz wrote: > On 06/29/2018 01:42 PM, Luke Kenneth Casson Leighton wrote: >>> I think that building on arm64 after fixing the bug in question is the >>> way to move forward. I'm surprised the bug itself hasn't been fixed y

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

On Fri, Jun 29, 2018 at 12:50 PM, Julien Cristau wrote: > Everyone, please avoid followups to debian-po...@lists.debian.org. > Unless something is relevant to *all* architectures (hint: discussion of > riscv or arm issues don't qualify), keep replies to the appropriate > port-specific mailing

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

On Fri, Jun 29, 2018 at 12:06 PM, John Paul Adrian Glaubitz wrote: > On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote: >> On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König >> wrote: >> >>>> In short, the hardware (development boards) we're currently us

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

On Fri, Jun 29, 2018 at 12:23 PM, Adam D. Barratt wrote: >> i don't know: i'm an outsider who doesn't have the information in >> short-term memory, which is why i cc'd the debian-riscv team as they >> have current facts and knowledge foremost in their minds. which is >> why i included them. >

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt wrote: >> what is the reason why that package is not moving forward? > > I assume you're referring to the dpkg upload that's in proposed-updates > waiting for the

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

On Wed, Jun 27, 2018 at 9:03 PM, Niels Thykier wrote: > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] [other affected 32-bit architectures removed but still relevant] ... i'm

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König wrote: > Hello, > > On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote: >> armel/armhf: >> >> >> * Undesirable to keep the hardware running beyond 2020. armhf VM >>support uncertain. (DSA) >>- Source: [DSA

Re: causes for this?

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jun 24, 2018 at 3:57 PM, Gene Heskett wrote: > I will try to remember that s35xx intel. > > Unforch, that search at newegg comes back empty today. currently up to version "S3520"

Re: causes for this?

On Sat, Jun 23, 2018 at 4:15 PM, Gene Heskett wrote: >> So when you first plug in a flash device, only a few megabytes are >> actually available for writing, and the controller is busy running >> self test routines on the rest. Any writes to the untested parts of >> the flash get queued behind

Re: Mirabox kernel help needed

On Friday, February 2, 2018, amon wrote: > Thanks for getting back to me. I hope you are right. What little > I have found via searches with Google were not comforting, to > say the least. > > most people are not sufficiently competent on the general internet to know what they are

Re: Rock64

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Aug 11, 2017 at 3:56 PM, Luna Jernberg wrote: > Hello! > > Just saw the BoF on the Debconf stream and has a small question: > > Anyone know hows the support for the Rock64 is? >

Re: missed keystrokes problem, back with a vengeance.

On Sun, Jan 29, 2017 at 6:48 PM, Gene Heskett wrote: > On Sunday 29 January 2017 12:40:21 Alan Corey wrote: > Alan, ALL of the motor drivers are switchmode, with the current > regulation running at or above 20 KHz. And these noise spikes are > ringing at nominally 100 MHz.

Re: d-i on Firefly-rk3288

On 12/12/16, Diego Roversi <die...@tiscali.it> wrote: > On Mon, 12 Dec 2016 05:35:01 +0000 > Luke Kenneth Casson Leighton <l...@lkcl.net> wrote: > >> add console=ttyS2 to the kernel parameters, also earlyprintk is really >> helpful (but you have to have the rig

Re: d-i on Firefly-rk3288

... you're doing ok, btw - progressing really quickly. took me several days to get this right and i had to bother a lot of people, including valgrind, stdint, mmind0 and nvm on #linux-rockchip :) l.

Re: d-i on Firefly-rk3288

add console=ttyS2 to the kernel parameters, also earlyprintk is really helpful (but you have to have the right options compiled in the kernel to use it). you could really do with adding the options to boot.cmd then running the (well-known?) mkimage command that turns them into boot.scr... ok

Re: d-i on Firefly-rk3288

On 12/10/16, Diego Roversi wrote: > On Fri, 09 Dec 2016 23:08:13 +0200 > Vagrant Cascadian wrote: > >> > U-Boot 2014.10-RK3288-02 (Nov 26 2014 - 09:28:44) >> >> This u-boot version is not coming from the SD card; probably from the >> on-board eMMC. You may

Re: d-i on Firefly-rk3288

On 12/10/16, Diego Roversi <die...@tiscali.it> wrote: > On Sat, 10 Dec 2016 04:42:19 +0000 > Luke Kenneth Casson Leighton <l...@lkcl.net> wrote: > > >> yep - this is the recommended method [for now] because the default >> hardware boot order is something l

Re: d-i on Firefly-rk3288

On 12/9/16, Vagrant Cascadian wrote: > On 2016-12-09, Diego Roversi wrote: >> I'm trying to install debian stretch on a firefly-rk3288, using debian >> installer. I downloaded the firmware from: >> >> >>

Re: Broadcom BCM2709, ARMv8, and missing CPU features

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Aug 6, 2016 at 8:15 PM, Stefan Monnier wrote: >> the only big advantage of dtb files (binary compiled) is *IF* the >> decision is made to respect dtb files and treat them as inviolate

Re: Broadcom BCM2709, ARMv8, and missing CPU features

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Aug 6, 2016 at 2:57 PM, Stefan Monnier wrote: > Note also that you will sometimes *lose* performance by going to 64bit > because the pointers use up twice as much space, so if your

Re: Broadcom BCM2709, ARMv8, and missing CPU features

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jul 28, 2016 at 5:35 PM, Gunnar Wolf wrote: > Keep in mind it's not different Debian images we are talking about — > "real" Debian cannot be booted on Raspberry hardware. I run a Debian >

EOMA68-A20 Crowd-funded Laptop and Micro-Desktop

https://www.crowdsupply.com/eoma68/micro-desktop i've been working on a strategy to make it possible for people to have more control over the hardware that they own, and for it to cost less money for them to do so, long-term. i've had to become an open hardware developer in order to do that. i

Re: Bug#399608: fixed in sysvinit 2.88dsf-59.1

On Sun, May 17, 2015 at 3:48 PM, Andreas Henriksson andr...@fatal.se wrote: Hello Adrian! Thanks for raising awareness about this issue. If there's anything I can do to help please tell me. That the new util-linux version hasn't been built yet sounds like it can't be avoided as it was just

Re: DebCamp15

On Tue, Apr 28, 2015 at 12:39 PM, Neil Williams codeh...@debian.org wrote: On Tue, 28 Apr 2015 11:30:33 +0100 Luke Kenneth Casson Leighton l...@lkcl.net wrote: On Tue, Apr 28, 2015 at 9:07 AM, Neil Williams codeh...@debian.org wrote: Chroot tests suffer from limitations with daemons

Re: DebCamp15

On Tue, Apr 28, 2015 at 9:07 AM, Neil Williams codeh...@debian.org wrote: Chroot tests suffer from limitations with daemons (changed port numbers if the same daemon is running outside etc.) and are subject to whatever the running kernel can offer. has anyone considered modifying any

Re: Cubietech Cubieboard3 / Cubietruck support under Debian Jessie?

On Tue, Oct 28, 2014 at 5:51 PM, Andrew M.A. Cater amaca...@galactic.demon.co.uk wrote: Before I go crazy: There are at least three issues with full support: 1. Mainline kernel versus Allwinner/Sun-xi kernel. Debian support on mainline kernel does not support all Cubietruck features. 2.

Allwinner A33 Quad Core 2GB board in development

i'm doing an EOMA68-A33 CPU Card which will cost $5600 to complete the layout and 5 samples. i can cover that cost over a couple of months, so it is going ahead, and first (working) 5 samples should be done and received by Dec 2014. if there is anyone who would like to buy either one of the 5

Re: A10-OLinuXino-LIME board

On Mon, Aug 25, 2014 at 1:22 PM, Karsten Merker mer...@debian.org wrote: On Mon, Aug 25, 2014 at 01:46:50AM -0700, Joey Hess wrote: Ian Campbell wrote: Why hd-media? The standard netboot images work fine on sunxi AFAIK (testing on cubie{truck,board}). Board doesn't netboot by default

Re: Support for sunxi-based ARM systems in d-i

On Tue, Jun 10, 2014 at 12:20 PM, Jerry Stuckle jstuc...@attglobal.net wrote: On 6/10/2014 3:42 AM, Ian Campbell wrote: On Tue, 2014-06-10 at 08:27 +0100, Luke Kenneth Casson Leighton wrote: On Mon, May 19, 2014 at 7:53 AM, Ian Campbell i...@hellion.org.uk wrote: On Sun, 2014-05-18 at 14:54

Re: Support for sunxi-based ARM systems in d-i

On Mon, May 19, 2014 at 7:53 AM, Ian Campbell i...@hellion.org.uk wrote: On Sun, 2014-05-18 at 14:54 -0700, Vagrant Cascadian wrote: On Sun, May 18, 2014 at 07:41:58PM +0200, Karsten Merker wrote: attached is a small patch against flash-kernel to add machine db entries for the Cubieboard 1/2

Re: Support for sunxi-based ARM systems in d-i

On Thu, May 8, 2014 at 10:09 PM, Ian Campbell i...@hellion.org.uk wrote: On Thu, 2014-05-08 at 22:05 +0100, Luke Kenneth Casson Leighton wrote: but for the BENEFIT OF THE DEBIAN PROJECT. debian-installer is incredibly hard to get properly compiled up: instructions and context entirely missing

Re: Support for sunxi-based ARM systems in d-i

On Fri, May 9, 2014 at 1:16 AM, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2014-05-08 at 22:05 +0100, Luke Kenneth Casson Leighton wrote: once again, respectfully may i ask, without prejudice and without obligation, that someone please consider documenting the steps taken so that others

Re: arm64 update - help wanted

On Thu, May 15, 2014 at 2:10 AM, Wookey woo...@wookware.org wrote: The debian-port arm64 rebootstrap is progressing nicely, and we just passed 4200 source packages built, with another few hundred pending. There are now 2 buildds running. awesome Thus I'd love it if anyone else could help go

Re: arm64 update - help wanted

suggestion, wookey: i'd love to help... but obviously with no hardware that's kinda hard: is there a clear set of instructions somewhere - a wiki page for example - on how to debootstrap an arm64 qemu so that even if it's dead slow it's still possible to help out?

Re: Support for sunxi-based ARM systems in d-i

once again, respectfully may i ask, without prejudice and without obligation, that someone please consider documenting the steps taken so that others may easily replicate them, and i am going to continue this paragraph without a break so that i may point out that i am in no way requesting this FOR

Re: Support for sunxi-based ARM systems in d-i

On Sat, Apr 26, 2014 at 11:25 PM, Karsten Merker mer...@debian.org wrote: Hello, I am currently working on better support for sunxi-based ARM systems in d-i and flash-kernel. Thanks to Ian's backport of the sunxi AHCI support from kernel 3.15rc1 into the Debian 3.14 kernel package (as of

Re: Support for sunxi-based ARM systems in d-i

On Sun, Apr 27, 2014 at 8:14 PM, Karsten Merker mer...@debian.org wrote: On Sun, Apr 27, 2014 at 07:35:35AM +0100, Ian Campbell wrote: On Sat, 2014-04-26 at 23:25 +0200, Karsten Merker wrote: No uImage is required for sunxi, no uImage is required for sunxi but a uImage is required for

Re: Support for sunxi-based ARM systems in d-i

On Sun, Apr 27, 2014 at 8:41 PM, Karsten Merker mer...@debian.org wrote: On Sun, Apr 27, 2014 at 03:52:36PM +0200, Luke Kenneth Casson Leighton wrote: On Sat, Apr 26, 2014 at 11:25 PM, Karsten Merker mer...@debian.org wrote: Hello, I am currently working on better support for sunxi-based

Re: Support for sunxi-based ARM systems in d-i

On Sun, Apr 27, 2014 at 9:10 PM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2014-04-27 at 21:04 +0200, Luke Kenneth Casson Leighton wrote: On Sun, Apr 27, 2014 at 8:41 PM, Karsten Merker mer...@debian.org wrote: On Sun, Apr 27, 2014 at 03:52:36PM +0200, Luke Kenneth Casson Leighton

Re: Boot time speed up

On Mon, Apr 21, 2014 at 1:02 PM, Divya Subramanian divyaenginee...@gmail.com wrote: I am unable to find a site through which I can download depinit https://web.archive.org/web/20050206182736/http://www.nezumi.plus.com/depinit/index.html

Re: Boot time speed up

... if you're feeling really adventurous look at depinit rather than systemd :) i recall a few years back there was some company claiming they'd managed a 1 second boot time (was it redhat or was it IBM?), and there were also some embedded companies that managed under 350ms including starting up

Re: Official support Odroid hardware and other ARM development boards.

On Sat, Mar 1, 2014 at 7:01 AM, Paul Wise p...@debian.org wrote: On Sat, Mar 1, 2014 at 2:29 PM, Martin Guy wrote: earlier the same day, Broadcom announced[1] full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack under a 3-clause BSD

Re: Official support Odroid hardware and other ARM development boards.

On Fri, Feb 28, 2014 at 12:57 AM, Eric Nelson eric.nel...@boundarydevices.com wrote: Hi Luke, On 02/27/2014 03:02 PM, Luke Kenneth Casson Leighton wrote: On Thu, Feb 27, 2014 at 6:18 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Thanks for the feedback Luke. no problem sah

Re: Official support Odroid hardware and other ARM development boards.

On Thu, Feb 27, 2014 at 1:26 AM, Eric Nelson eric.nel...@boundarydevices.com wrote: Hi Luke, On 02/26/2014 05:44 PM, Luke Kenneth Casson Leighton wrote: On Wed, Feb 26, 2014 at 11:46 PM, Reg Lnx regier.kun...@gmail.com wrote: Thank you Karsten. It answers a lot of questions and it makes

Re: Official support Odroid hardware and other ARM development boards.

On Thu, Feb 27, 2014 at 3:32 AM, Paul Wise p...@debian.org wrote: Interestingly there was an ARM based tablet that planned to use an OpenRISC chip for the embedded controller. http://www.indiegogo.com/projects/pengpod-1040-quad-core-linux-android-dual-booting-tablets ah that's a

Re: Official support Odroid hardware and other ARM development boards.

On Thu, Feb 27, 2014 at 7:27 AM, Tobias Frost t...@coldtobi.de wrote: Am Mittwoch, den 26.02.2014, 18:26 -0700 schrieb Eric Nelson: There are also some open-source bits with licenses other than GPL/LGPL provided by Freescale (notably, some of the VPU code), but the restrictions are pretty

Re: Official support Odroid hardware and other ARM development boards.

On Thu, Feb 27, 2014 at 12:52 PM, Paul Wise p...@debian.org wrote: On Thu, Feb 27, 2014 at 8:00 PM, Luke Kenneth Casson Leighton wrote: ah that's a misunderstanding, paul. what neal (bless 'im) is referring to there is the fact that the A31 has *inside the Silicon design* an early version

Re: Official support Odroid hardware and other ARM development boards.

On Thu, Feb 27, 2014 at 6:18 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Thanks for the feedback Luke. no problem sah. btw, the sabre lite pcb cad/cam files i received from one of your associates were really useful. i was able to create - with a lot of effort(!) an EOMA68-iMX6

Re: Official support Odroid hardware and other ARM development boards.

On Wed, Feb 26, 2014 at 8:54 PM, Reg Lnx regier.kun...@gmail.com wrote: I'd like to know if Debian community have plans to officially support any of those development boards, providing ready to boot images, containing the Debian Installer for example. hi reg, this question comes up on a

Re: Official support Odroid hardware and other ARM development boards.

On Wed, Feb 26, 2014 at 11:46 PM, Reg Lnx regier.kun...@gmail.com wrote: Thank you Karsten. It answers a lot of questions and it makes sense. I think we can say the very same about the odroid, it has some non free things too. indeed it does. i've been working at every opportunity possible to

Re: On a Samsung ARM Chromebook, could nv-uboot easily boot to stock linux kernels, by way of ARM-GRUB?

On Thu, Jan 2, 2014 at 2:57 PM, Subharo Bhikkhu subh...@forestsangha.net wrote: Indeed. It seems that the Utopian technological future that I was hoping for, where solid state hardware would last *even longer* than non-solid state hardware, has been replaced with a distopian present, where

Re: On a Samsung ARM Chromebook, could nv-uboot easily boot to stock linux kernels, by way of ARM-GRUB?

subharo, hi, basically you've been caught out by the use of treacherous computing, and have purchased a product that you cannot and will not ever own. the samsung processors have bootloader-signing actually built-in to the ROM: once the e-fuses are fired and the private key installed in EEPROM

Fwd: [Arm-netbook] Another new ARM plateform

just something for people's attention, this is a pretty damn good find by erix: quad-core 1ghz iMX6, it has 2gb of RAM, SATA, GbE and a full MiniPCIe slot (not just USB-only but *full* PCIe because the iMX6 has 1x PCIe). and plenty more. on the face of it it looks like the $150 price tag is high

Re: Good ARM board for Debian?

jerry: i apologise - there are too many judgements and assumptions for me to be able to continue this conversation, especially without consultancy fees being paid. i've given you a lot of advice: you're not listening to it. you may also wish to bear in mind that the client is going to be able to

Re: Good ARM board for Debian?

On Tue, Dec 24, 2013 at 1:07 PM, Dale Amon a...@vnl.com wrote: On Tue, Dec 24, 2013 at 11:37:07AM +, Luke Kenneth Casson Leighton wrote: jerry: i apologise - there are too many judgements and assumptions for me to be able to continue this conversation, especially without consultancy fees

Re: Good ARM board for Debian?

On Tue, Dec 24, 2013 at 2:27 PM, Jerry Stuckle jstuc...@attglobal.net wrote: On 12/24/2013 6:37 AM, Luke Kenneth Casson Leighton wrote: jerry: i apologise - there are too many judgements and assumptions for me to be able to continue this conversation, especially without consultancy fees being

Re: Good ARM board for Debian?

On Tue, Dec 24, 2013 at 1:07 PM, Dale Amon a...@vnl.com wrote: However many of us who are silent have found this to be one of the more interesting discussions on the business and industry of SoC that have come along in a very long time. Definitely a high S/N. I say this as someone in early

Re: Good ARM board for Debian?

On Mon, Dec 23, 2013 at 4:43 PM, Jerry Stuckle jstuc...@attglobal.net wrote: On 12/23/2013 2:24 AM, Luc Verhaegen wrote: On Sun, Dec 22, 2013 at 11:09:39PM -0500, Jerry Stuckle wrote: Let's try this again. I'm still looking for a good ARM board for Debian. I thought the Olinuxino A10s

Re: Good ARM board for Debian?

jerry this is an example of a freescale SoC that could potentially fit the requirements you've set. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF5xx# like many of these cortex A5 SoCs it's relatively new, and quite... specialist. the other one is that SAMA5:

Re: Good ARM board for Debian?

[jerry please read very last paragraph first, thanks]. On Mon, Dec 23, 2013 at 8:11 PM, Jerry Stuckle jstuc...@attglobal.net wrote: On 12/23/2013 2:27 PM, Luke Kenneth Casson Leighton wrote: On Mon, Dec 23, 2013 at 4:09 AM, Jerry Stuckle jstuc...@attglobal.net wrote: On 9/26/2013 5:13 PM

Re: Good ARM board for Debian?

On Mon, Dec 23, 2013 at 8:20 PM, Jerry Stuckle jstuc...@attglobal.net wrote: but even rockchip are not immune to the supernova SoC effect. that amazing 28nm $12 quad-core SoC - which is only sold to clients with good engineering resources (of whom there are extremely few - tom cubie's team

Re: qemu status on ARM

tim i'm sure i saw some patches which add one of the other CPU types, not just A15, a couple months back. the work was, if i vaguely remember, done by someone with an @redhat.com email address. the clue that you're operating in emulated (non-VM) mode is this: kvm [1]: HYP mode not available

Re: qemu status on ARM

On Sat, Dec 14, 2013 at 4:51 PM, Tim Fletcher t...@night-shade.org.uk wrote: The boot log was from the VM booting, so that would be expected? http://www.spinics.net/lists/kvm-arm/msg02582.html right. ok. thought it was the host. don't know why! -- Tim Fletcher t...@night-shade.org.uk

  1   2   3   4   >